[{"content":"Most businesses hand AI adoption to whoever\u0026rsquo;s technical - an in-house engineer, or an outside provider - with a brief that amounts to \u0026ldquo;go adopt AI.\u0026rdquo; Those people reach for agentic tools like langchain or n8n and use them to automate the manual steps that already exist.\nThe businesses that actually see returns don\u0026rsquo;t treat AI as a tech project. They redesign how the work gets done around what AI can do, instead of bolting bots onto the process they already had.\nThat difference explains most of the gap between the enterprises struggling to show ROI on their AI spend and the handful who aren\u0026rsquo;t.\nWhat this looks like in finance # Company A adds AI that reads invoices and enters the data into the finance system.\nIt saves some typing and cuts manual errors, and the business gets to feel like it\u0026rsquo;s \u0026ldquo;using AI.\u0026rdquo; But employees still do what they\u0026rsquo;ve always done - review every invoice and approve payments by hand.\nCompany B rebuilds how invoices get handled so AI does the repetitive work, not just the data entry.\nAn agent extracts and validates invoice data, then matches it against purchase orders. The system flags only genuine exceptions and routes approvals by value and risk. That frees staff to focus on the complex cases instead of grinding through every single one.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/why-ai-tools-alone-dont-guarantee-roi/","section":"Our Experience","summary":"Most businesses hand AI adoption to whoever’s technical - an in-house engineer, or an outside provider - with a brief that amounts to “go adopt AI.” Those people reach for agentic tools like langchain or n8n and use them to automate the manual steps that already exist.\n","title":"Why AI tools alone won't guarantee ROI","type":"our-experience"},{"content":"Just reviewing how AI could help a business often surfaces problems that were already there:\nRepeated manual handovers Duplicate data entry Unclear ownership Excessive approvals Knowledge trapped in individuals Inconsistent decisions Work organised around old technology constraints Automating a process often cleans up ways of working that were already outdated or decaying - before AI adds any value of its own.\nWhat this looks like in customer service # A mid-sized company brings in an AI assistant to help its customer service team answer policy questions faster.\nThe expectation is faster email drafting. But once it\u0026rsquo;s wired into the service workflow, the AI exposes a much bigger problem.\nTo answer something as simple as \u0026ldquo;Am I covered for a replacement windscreen?\u0026rdquo;, an employee has to check the customer\u0026rsquo;s policy in one system, review product rules in a shared drive, search old emails for exceptions, and sometimes ask underwriting to confirm. Different teams often read the same policy wording differently.\nThe AI quickly shows that agents spend more time finding and verifying information than actually talking to customers. The same questions get escalated over and over. Response times vary wildly between teams. And a lot of approvals get requested for one reason: employees don\u0026rsquo;t trust the information in front of them.\nSo the company redesigns the process around the AI. It standardises the policy rules and moves them into a single, trusted knowledge base. Now the AI can pull the customer\u0026rsquo;s policy details, find the relevant rules and give an answer backed by evidence. Straightforward enquiries get handled automatically. Unusual cases, conflicting information and high-value claims go to a specialist.\nInstead of just helping employees work a little faster inside a broken process, the AI shows why the process is slow - and helps strip out the unnecessary searching, interpreting and escalating.\nThe original tool might have saved two minutes writing each email. The redesigned process removes fifteen minutes of investigation and several days of unnecessary handoffs.\nAI first exposes the friction, then helps redesign the workflow so less work is needed in the first place.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/ai-exposes-inefficient-processes/","section":"Our Experience","summary":"Just reviewing how AI could help a business often surfaces problems that were already there:\nRepeated manual handovers Duplicate data entry Unclear ownership Excessive approvals Knowledge trapped in individuals Inconsistent decisions Work organised around old technology constraints Automating a process often cleans up ways of working that were already outdated or decaying - before AI adds any value of its own.\n","title":"AI exposes inefficient processes","type":"our-experience"},{"content":"Sometimes the most valuable improvements are not always large transformation programmes. They may be as simple as:\nCapturing information in a more structured format Moving validation earlier in a workflow Giving AI access to the right reference material Combining several review stages Automatically drafting work before human review Routing exceptions instead of people reviewing everything Changing when and where a decision is made AI agents typically add most value by handling the repetitive work so a small redesign at the right point can remove hours of downstream work.\nExamples # 1. Change the point of data entry # A sales team uses AI to summarise customer calls, but staff still enter key details manually into the CRM afterwards. A small process change—having the AI update the CRM directly from the call transcript—removes duplicate work, improves data quality and gives managers a more accurate pipeline.\nSmall change: automate where information enters the process. Disproportionate gain: hours of admin removed across the whole sales team.\n2. Route exceptions, not every transaction # A finance team uses AI to read supplier invoices, but employees still review every one before payment. By changing the process so AI automatically approves invoices that match a purchase order and only sends exceptions for review, staff stop checking routine transactions.\nSmall change: humans review only unusual cases. Disproportionate gain: thousands of manual checks disappear without reducing control.\n3. Give AI authority within clear limits # A customer service AI drafts responses, but every reply still requires manager approval. The company creates a set of approved actions the AI can take automatically, such as issuing refunds below £25 or changing delivery dates.\nSmall change: allow AI to act within defined boundaries. Disproportionate gain: faster resolutions, fewer escalations and much lower management workload.\nThe common pattern is that the biggest gains rarely come from a more powerful AI model. They come from removing one unnecessary handoff, approval or duplication around it.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/small-changes-can-create-disproportionate-gains/","section":"Our Experience","summary":"Sometimes the most valuable improvements are not always large transformation programmes. They may be as simple as:\nCapturing information in a more structured format Moving validation earlier in a workflow Giving AI access to the right reference material Combining several review stages Automatically drafting work before human review Routing exceptions instead of people reviewing everything Changing when and where a decision is made AI agents typically add most value by handling the repetitive work so a small redesign at the right point can remove hours of downstream work.\n","title":"The right small changes create disproportionate gains","type":"our-experience"},{"content":"Before choosing a tool, understand:\nWhat outcome the process is meant to produce Which steps genuinely add value Where delays and errors occur What information each person needs Which decisions are predictable Which cases require human judgement Only then should you decide where AI belongs.\nExample # A growing company decides to use AI to improve employee onboarding.\nIt buys an AI chatbot that can answer new starters’ questions. The chatbot works, but employees still spend their first week waiting for laptops, chasing system access, repeating personal information across several forms and asking managers what they should be doing.\nThe technology has improved one small part of the experience, but the underlying workflow remains broken.\nA workflow-first approach starts by mapping the entire journey from signed contract to productive employee. This reveals that HR, IT, payroll, security and the hiring manager each begin their work at different times, often using separate spreadsheets, emails and forms. Most delays come from missed handoffs rather than difficult tasks.\nThe company redesigns the process so that accepting an offer triggers a single coordinated workflow. AI extracts the required information from the employee’s documents, prepares payroll and account requests, creates a role-specific onboarding plan, schedules training and alerts people only when human input is genuinely required.\nThe chatbot can still answer questions, but it is no longer the centre of the solution.\nThe real gain comes from redesigning the workflow so that information is entered once, tasks begin automatically and new employees arrive with everything ready.\nStarting with the technology produced a better chatbot. Starting with the workflow removed three days of delay from every new hire.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/start-with-the-workflow-not-the-technology/","section":"Our Experience","summary":"Before choosing a tool, understand:\nWhat outcome the process is meant to produce Which steps genuinely add value Where delays and errors occur What information each person needs Which decisions are predictable Which cases require human judgement Only then should you decide where AI belongs.\n","title":"Start with the workflow, not the technology","type":"our-experience"},{"content":"AI expertise helps identify points where one intervention affects the entire process. Good candidates include work involving:\nHigh volumes of documents or messages Repetitive classification or extraction Similar decisions made repeatedly Time-consuming research Drafting from known information Comparison against rules, policies or standards Large numbers of routine cases with a small number of exceptions The opportunity can be narrower and more specific than “automate the whole department.”\nExamples # 1. Fix the decision point, not every task # A property insurer receives thousands of claims each month. AI could help staff read documents, summarise emails and draft responses, but the real leverage point is the first decision: which claims are routine and which require investigation?\nBy using AI to assess the claim at intake, straightforward cases can move directly to settlement while suspicious, incomplete or high-value claims go to specialists.\nMoment of leverage: the initial triage decision. Disproportionate gain: faster payouts, fewer unnecessary reviews and more specialist time focused on genuine risk.\n2. Capture information once, at the source # A sales team records customer calls, writes follow-up emails, updates the CRM and then briefs delivery teams. AI tools could make each of those tasks faster, but the strongest leverage point is the call itself.\nAI captures the conversation once, identifies actions, updates the CRM, drafts the follow-up and creates the internal handover.\nMoment of leverage: the point where information first enters the business. Disproportionate gain: several downstream tasks disappear, data becomes more accurate and handovers happen immediately.\nThe best leverage points are usually where one decision, handoff or piece of information affects everything that follows.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/look-for-repetition/","section":"Our Experience","summary":"AI expertise helps identify points where one intervention affects the entire process. Good candidates include work involving:\nHigh volumes of documents or messages Repetitive classification or extraction Similar decisions made repeatedly Time-consuming research Drafting from known information Comparison against rules, policies or standards Large numbers of routine cases with a small number of exceptions The opportunity can be narrower and more specific than “automate the whole department.”\n","title":"Look for Repetition","type":"our-experience"},{"content":"Successful AI adoption does not simply replace human tasks. It changes what people spend their time doing.\nFor example: # AI prepares; people approve. AI monitors everything; people investigate exceptions. AI finds relevant information; people make the judgement. AI produces the first draft; people add context and accountability. This keeps human expertise focused on the parts where it creates the most value.\nExample\nRedesign the human role # A bank may introduce AI to help its lending team assess small-business loan applications.\nThe quick win is where the AI produces a summary for an underwriter. The underwriter still checks every bank statement, reviews every document, verifies the figures and makes the final decision. The work is slightly faster, but the human role has not really changed.\nThe real win is when the bank then redesigns the process.\nAI now checks that documents are complete, extracts financial data, identifies inconsistencies, calculates affordability and compares the application with the bank’s lending criteria. Straightforward, low-risk applications can proceed automatically within agreed limits.\nUnderwriters no longer spend most of their day checking routine information. Their role becomes handling unusual cases, applying judgement where the evidence is unclear, speaking to applicants with complex circumstances and improving the rules used by the AI.\nThe human hasn\u0026rsquo;t been removed. Their expertise has been moved to the part of the process where it creates the most value.\nThe weak approach gives every underwriter an AI assistant. The stronger approach redesigns the underwriter’s job around judgement, exceptions and customer outcomes.\nSee this play out in the real world in IKEA frees staff to be creative and in how we redesigned claims handling for a health insurer.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/redesign-the-human-role/","section":"Our Experience","summary":"Successful AI adoption does not simply replace human tasks. It changes what people spend their time doing.\nFor example: # AI prepares; people approve. AI monitors everything; people investigate exceptions. AI finds relevant information; people make the judgement. AI produces the first draft; people add context and accountability. This keeps human expertise focused on the parts where it creates the most value.\n","title":"Redesign the human role","type":"our-experience"},{"content":"Most AI initiatives underperform for one reason: the AI is stuck compensating for information that\u0026rsquo;s incomplete, inconsistent or impossible to find.\nNo prompt, however clever, fixes missing customer details, contradictory policies or knowledge scattered across dozens of disconnected systems. The biggest gains usually come from fixing what goes into the process, not the AI itself.\nBetter templates # A consulting firm asks AI to draft client proposals from notes account managers write up. Some notes cover the client\u0026rsquo;s objectives, budget and deadlines. Others are three sentences copied from an email.\nThe proposals come out wildly uneven.\nInstead of endlessly tweaking the prompt, the company introduces a standard opportunity brief that captures:\nThe client\u0026rsquo;s problem Desired business outcome Scope and exclusions Budget range Decision-makers Target delivery date Evidence from previous conversations Now every proposal starts from the information it actually needs, and the AI\u0026rsquo;s output gets much stronger.\nThe improvement comes from a better brief, not a cleverer prompt.\nClearer data ownership # A manufacturer uses AI to answer questions about stock availability. But the numbers don\u0026rsquo;t agree - the warehouse system, the sales spreadsheets and the ecommerce platform all say something different.\nThe AI cannot know which number is correct.\nThe company gives the operations team ownership of inventory data, makes the warehouse system the single source of truth, and sets up a process for resolving discrepancies.\nOnly then can the AI give a reliable answer.\nAI cannot resolve organisational ambiguity that the business itself has never resolved.\nStructured inputs # An insurer uses AI to check whether claims have the information needed for review. Customers describe incidents in an open text box, and routinely leave out dates, locations, item values or supporting evidence.\nThe company redesigns the claim form to capture:\nType of incident Date and location Items affected Estimated value Police or reference numbers Supporting documents Relevant circumstances Now the AI can spot straightforward claims, missing evidence and unusual cases far more reliably.\nStructured information reduces the amount the AI has to infer.\nUpdated policies # A customer service team uses AI to draft refund decisions. The internal refund policy hasn\u0026rsquo;t been touched in three years and contradicts itself on delivery delays, damaged products and subscription cancellations.\nEmployees paper over the gaps with experience. The AI just applies the written rules literally, and its recommendations come out inconsistent.\nSo the company updates the policy first: it removes the contradictions, adds real examples, and marks out which situations need a manager\u0026rsquo;s sign-off.\nThe AI\u0026rsquo;s recommendations improve immediately, because now it\u0026rsquo;s working from a policy that\u0026rsquo;s actually current.\nAn AI system trained on unclear rules will apply those rules unclearly.\nAccessible internal knowledge # An engineering firm wants an AI assistant to help field technicians diagnose equipment faults. The knowledge exists - it\u0026rsquo;s just scattered across PDF manuals, old support tickets, individual laptops and the memories of the engineers who\u0026rsquo;ve been there longest.\nBefore building the assistant, the company pulls all of it into one searchable knowledge base. Each entry includes:\nEquipment model Symptoms Likely causes Diagnostic steps Safety warnings Approved resolution Source and review date Now the AI gives useful, evidence-backed guidance instead of generic troubleshooting advice.\nThe key investment is making organisational knowledge accessible and trustworthy.\nDefined decision criteria # A recruitment team asks AI to find the strongest applicants for a role. The instruction is just: \u0026ldquo;find the best candidates.\u0026rdquo;\nThe output is vague, because the business never defined what \u0026ldquo;best\u0026rdquo; means.\nThe hiring team agrees explicit criteria:\nEssential qualifications Required evidence of delivery Relevant leadership experience Acceptable skills gaps Disqualifying conditions Factors that must not influence the decision The AI is told to show evidence against each criterion instead of spitting out an unexplained overall score.\nClear criteria create more consistent decisions and make recommendations easier to challenge.\nFeedback from completed cases # A finance company uses AI to flag loan applications that need extra review. At first, the system makes recommendations based on historical guidance - but nobody records whether those recommendations were actually right.\nThe company closes the feedback loop. For every completed application, it records:\nThe AI recommendation The reviewer\u0026rsquo;s decision The reason for any disagreement The final customer outcome Whether problems emerged later Over time, the company finds that applications with variable income get escalated for no good reason. It updates the decision rules and examples accordingly.\nThe system gets better because it\u0026rsquo;s learning from real outcomes, not just the assumptions it started with.\nEvery completed case becomes evidence for improving the next one.\nThe practical lesson is simple:\nDo not ask how to write a better prompt until you have asked whether the AI has the right information, in the right format, from a trusted source.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/better-inputs-matter-more-than-clever-prompts/","section":"Our Experience","summary":"Most AI initiatives underperform for one reason: the AI is stuck compensating for information that’s incomplete, inconsistent or impossible to find.\nNo prompt, however clever, fixes missing customer details, contradictory policies or knowledge scattered across dozens of disconnected systems. The biggest gains usually come from fixing what goes into the process, not the AI itself.\n","title":"Better inputs matter more than clever prompts","type":"our-experience"},{"content":"Governance should live inside the workflow, not get bolted on as an obstacle at the end.\nThe aim isn\u0026rsquo;t to wrap every AI action in approvals. It\u0026rsquo;s to find where mistakes would actually cause harm, put controls there, and let low-risk work move fast.\nWhere human approval is required # A bank uses AI to review mortgage applications and flag missing information, affordability concerns and potential fraud indicators.\nThe AI can automatically request a missing payslip or bank statement. But it can\u0026rsquo;t decline an application, change the interest rate or make the final lending call - those need sign-off from a qualified underwriter.\nStraightforward admin gets automated. Decisions with real financial or personal consequences stay with a person.\nHuman approval is required because of the impact of the decision, not simply because AI was involved.\nWhat data AI may access # A customer service assistant helps employees answer questions about orders and deliveries.\nIt can access:\nOrder status Delivery tracking Product information Previous support conversations It cannot access:\nFull payment card details Employee HR records Unrelated customer accounts Internal legal investigations When a customer asks about a payment dispute, the assistant pulls only the limited transaction information that case needs. Access follows the employee\u0026rsquo;s role, and every lookup gets logged.\nThe AI receives the minimum information required to perform the task, rather than unrestricted access to every company system.\nHow outputs are checked # A pharmaceutical company uses AI to draft summaries of clinical safety reports.\nBefore a summary goes anywhere, the workflow automatically checks that:\nEvery figure in the summary appears in the source report Patient identifiers have been removed Required safety sections are present The AI has not introduced unsupported conclusions A medical reviewer has approved the final wording The reviewer sees each statement next to the source evidence behind it, which makes verification faster and more reliable.\nThe output is checked against evidence, not accepted merely because it sounds credible.\nHow decisions are recorded # An insurer uses AI to recommend whether claims should be paid, rejected or referred for further review.\nFor every claim, the system records:\nThe information available at the time The rules and policy version applied The AI recommendation The evidence supporting that recommendation The confidence level The employee\u0026rsquo;s final decision The reason for any disagreement with the AI If a customer challenges the outcome six months later, the insurer can reconstruct exactly how the decision was reached.\nA good record explains not only what happened, but why it happened.\nHow exceptions are escalated # A logistics company uses AI to approve routine refunds for late deliveries.\nRefunds under £50 go out automatically once tracking data confirms the delay. Cases get escalated when:\nThe refund exceeds £50 The customer has made several recent claims Tracking information is contradictory The package contains a restricted or high-value item The AI\u0026rsquo;s confidence is low High-value or suspicious cases go to a specialist team, evidence already assembled.\nThe normal process remains fast, while unusual cases receive greater scrutiny.\nHow errors are corrected # A retailer discovers that its AI assistant has incorrectly told several customers that personalised products can be returned for a full refund.\nThe company doesn\u0026rsquo;t just fix the latest response. It:\nStops the assistant answering questions about personalised returns. Identifies all affected conversations. Contacts customers who received incorrect information. Corrects the underlying policy document. Tests the assistant against similar questions. Records the incident and the action taken. Restores automated answers only once the fix is verified. The correction process addresses the customer impact, the individual error and the underlying cause.\nHow performance is monitored # A finance team uses AI to identify duplicate supplier invoices.\nRather than measuring only how many invoices the AI reviews, the team tracks:\nGenuine duplicates detected Valid invoices incorrectly blocked Duplicates missed Time taken to resolve flagged cases Financial losses prevented Differences in performance across suppliers and invoice types The team notices invoices with handwritten purchase-order numbers generate three times as many false alerts. So it adds an extra extraction check for those invoices before duplicate detection runs.\nMonitoring is used to improve the process, not merely to prove that the AI is active.\nThe safest process isn\u0026rsquo;t the one with the most approvals. Pile on too many, and employees start rubber-stamping work instead of actually checking it.\nA stronger approach: automate low-risk, reversible actions. Require human judgement for high-impact decisions. Restrict access to sensitive information. And make important actions visible, traceable and correctable.\nTrust comes from knowing where the AI can act, where it must stop and what happens when something goes wrong.\nFor a real example of this in practice, see how we built exactly this kind of tiered review into health insurance claims processing.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/build-trust-and-control-into-the-process/","section":"Our Experience","summary":"Governance should live inside the workflow, not get bolted on as an obstacle at the end.\nThe aim isn’t to wrap every AI action in approvals. It’s to find where mistakes would actually cause harm, put controls there, and let low-risk work move fast.\n","title":"Build trust and control into the process","type":"our-experience"},{"content":"The fact that 80% of employees have tried an AI tool tells you very little about whether the business has improved. Likewise, producing 10,000 AI-generated summaries is not valuable unless those summaries reduce effort, improve decisions or create better customer outcomes.\nMeasure the change in the work itself.\nTime saved # A legal team introduces AI to review standard supplier contracts. Before implementation, each contract takes an average of 90 minutes to review. Afterwards, AI identifies relevant clauses and potential exceptions, reducing the average review time to 35 minutes.\nThe meaningful result is not “500 contracts analysed by AI.” It is 458 hours of legal time released each quarter.\nReduced processing costs # An accounts payable team uses AI to extract information from invoices and match them against purchase orders. The cost of processing an invoice falls from £6.20 to £2.10 because fewer invoices require manual entry.\nAt 100,000 invoices per year, this represents an annual processing-cost reduction of £410,000.\nShorter response times # A customer support team uses AI to classify incoming requests, retrieve relevant account information and prepare a draft response. The average first-response time falls from 14 hours to 90 minutes.\nThe useful measure is not the number of AI-generated replies. It is the percentage of customers receiving a useful response within the company’s service target.\nFewer errors # An insurance company uses AI to check applications for missing information and inconsistencies before they reach an underwriter. Previously, 18% of applications had to be returned for correction. After changing the workflow, this falls to 6%.\nThat means fewer delays, less repeated work and 12 fewer problematic applications for every 100 submitted.\nHigher conversion rates # A software company uses AI to analyse sales enquiries and provide representatives with relevant industry examples, likely objections and recommended next actions. The percentage of qualified prospects booking a demonstration rises from 22% to 29%.\nThe outcome is not “salespeople used AI 2,000 times.” It is seven additional demonstrations for every 100 qualified prospects.\nIncreased capacity # A recruitment team previously screened 300 applications per week. AI now organises applications against agreed criteria and highlights the evidence supporting each recommendation. With recruiters still making the final decision, the team can assess 750 applications per week without adding staff.\nThe gain is 150% more capacity, not simply faster document processing.\nBetter customer outcomes # A utility provider uses AI to identify customers whose payment patterns suggest they may be experiencing financial difficulty. Instead of automatically sending escalating payment demands, the workflow routes these customers to a specialist support team.\nSuccess is measured through fewer customers falling into serious arrears, more affordable repayment plans agreed and improved customer satisfaction—not the number of customers flagged by the model.\nLess time spent on low-value work # Project managers previously spent six hours each week collecting updates, formatting reports and chasing missing information. AI now assembles a first draft from project systems and identifies gaps that require attention. Managers spend two hours reviewing the report and four additional hours resolving risks with their teams.\nThe important outcome is not four hours of administrative time eliminated. It is four hours redirected towards decisions, coaching and problem-solving.\nThe strongest AI measures therefore connect directly to operational or commercial performance:\nWhat became faster, cheaper, more accurate or more valuable—and what did employees or customers experience as a result?\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/measure-business-outcomes-not-ai-activity/","section":"Our Experience","summary":"The fact that 80% of employees have tried an AI tool tells you very little about whether the business has improved. Likewise, producing 10,000 AI-generated summaries is not valuable unless those summaries reduce effort, improve decisions or create better customer outcomes.\n","title":"Measure business outcomes, not AI activity","type":"our-experience"},{"content":"A regional insurance company rolls out an AI assistant to help claims handlers review incoming claims.\nThe system summarises documents, flags missing evidence and suggests which policy clauses apply. Technically, it works well. But nobody explains it beyond \u0026ldquo;this will make the process more efficient.\u0026rdquo;\nSo employees fill the gap themselves. Many assume the AI is there to replace part of their job. Some ignore its recommendations. Others accept them without checking, because they\u0026rsquo;ve decided the system owns the decision now. Experienced handlers notice it struggles with vulnerable customers, unusual property damage and handwritten evidence - but there\u0026rsquo;s no way to flag that.\nSo the company changes tack.\nIt brings claims handlers into workshops to map the real process and find out where time actually goes. The answer isn\u0026rsquo;t the final decision - it\u0026rsquo;s reading repetitive documents, chasing missing information and digging through policy manuals.\nTogether, they redesign the workflow:\nAI prepares the initial case summary. It flags missing documents and the relevant policy sections. Claims handlers verify the evidence and make the final call. Sensitive or unusual cases go straight to experienced reviewers. Employees can flag a bad recommendation right inside the case. Weekly reviews check flagged cases and update the AI\u0026rsquo;s guidance. The company spells out who owns what. AI organises information and flags possible issues. The claims handler owns the judgement call - reading the customer\u0026rsquo;s circumstances and signing off the outcome.\nBecause employees helped build and test the process, they understand what the system can do and where it falls short. They use it more, push back on it more confidently, and spot where it needs to improve.\nThe best idea in the whole redesign came from the claims handlers themselves: request missing evidence automatically at the start of a claim, instead of just speeding up the final summary. That one change cuts avoidable follow-up work across the entire department.\nAdoption improves when people aren\u0026rsquo;t simply trained to use a new tool - they\u0026rsquo;re involved in deciding how the work itself should change.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/adoption-requires-people-to-understand-the-change/","section":"Our Experience","summary":"A regional insurance company rolls out an AI assistant to help claims handlers review incoming claims.\nThe system summarises documents, flags missing evidence and suggests which policy clauses apply. Technically, it works well. But nobody explains it beyond “this will make the process more efficient.”\n","title":"Adoption requires people to understand the change","type":"our-experience"},{"content":"The value of an AI specialist is not simply knowing which tools or models are available. It is understanding how work happens inside a business and knowing how technology, process and people must change together to produce a worthwhile result.\nUnderstand how the business currently operates # A wholesaler believes its customer service team is overwhelmed because employees spend too long writing emails.\nA review of the real workflow shows that writing the response is only a small part of the problem. Employees must search three systems for order information, check stock with the warehouse, ask finance whether an account is on hold and confirm delivery dates with a separate logistics provider.\nAn AI email-writing tool would save a few minutes. Mapping the operation reveals that the real delay is gathering reliable information.\nThe first step is therefore not selecting an AI product. It is understanding where time, effort and uncertainty currently enter the process.\nRecognise where AI can genuinely help # A manufacturer wants to use AI to automate quality inspections.\nCloser analysis shows that its product images are inconsistent, defect labels are unreliable and many faults can only be identified through physical testing. Fully automated inspection would be risky and expensive.\nHowever, engineers spend several hours each day reviewing maintenance logs and identifying recurring equipment problems. Those records are detailed and contain repeatable patterns.\nInstead of forcing AI into the inspection process, the company uses it to summarise maintenance histories, group similar faults and highlight equipment that may require preventative work.\nThe best opportunity is often not the most visible or ambitious use of AI. It is the point where suitable information, repetitive effort and clear business value already overlap.\nRedesign the surrounding process # A property management company introduces AI to classify tenant maintenance requests.\nOriginally, the plan is for AI to read each email and assign it to plumbing, electrical or general maintenance. This saves a dispatcher a small amount of time, but contractors still contact tenants repeatedly because important information is missing.\nThe process is redesigned so that tenants are asked structured questions when submitting a request:\nWhere is the problem? When did it start? Is water, electricity or heating affected? Is there an immediate safety risk? Can photographs be provided? When can a contractor access the property? The AI then classifies urgency, identifies the appropriate contractor and prepares a complete work order.\nThe value comes not from automating one existing step, but from changing the input and routing process around it.\nImplement appropriate controls # A recruitment company uses AI to summarise CVs and compare applicants against role requirements.\nWithout controls, recruiters might rely on an unexplained score or allow irrelevant personal information to influence recommendations.\nThe workflow is designed so that:\nAI evaluates only agreed job-related criteria. Sensitive personal information is excluded. Every recommendation includes supporting evidence from the application. The system cannot automatically reject a candidate. Recruiters record the final decision and their reasoning. Results are monitored for unexplained differences between candidate groups. The control is not a lengthy approval process added after the AI has acted. It is built into the way information is selected, recommendations are presented and decisions are made.\nHelp employees adopt the new way of working # A finance team introduces AI to review staff expenses and identify missing receipts, unusual claims and possible tax issues.\nEmployees initially resist the system because they believe it is designed to monitor their performance or remove jobs. Some reviewers ignore the recommendations, while others approve them without checking.\nThe implementation team works with expense reviewers to clarify the new division of responsibilities:\nAI performs the first-pass checks. Employees investigate unusual or ambiguous claims. Reviewers remain responsible for the final decision. Incorrect recommendations can be flagged directly. Common issues are reviewed with the team each month. Training uses real historical claims rather than generic demonstrations. Employees begin to see that the system removes repetitive checking while giving them more time to investigate genuinely risky cases.\nAdoption comes from helping people understand how their role is changing, not simply teaching them which buttons to press.\nMeasure whether the change produced a real gain # A sales team introduces an AI assistant that prepares account summaries before customer meetings.\nThe company could report that 80% of salespeople use the tool or that it generated 4,000 summaries. Neither measure demonstrates business value.\nInstead, it compares outcomes before and after the change:\nPreparation time falls from 45 minutes to 15 minutes per meeting. Salespeople hold 18% more customer conversations. Follow-up actions are sent within one day rather than three. Fewer meetings are missed because account risks were overlooked. Conversion from demonstration to proposal increases from 31% to 36%. The team also checks whether the summaries are accurate and whether salespeople find them useful. If usage is high but conversion and preparation time do not improve, the initiative has not succeeded.\nThe real expertise lies in connecting all six elements.\nUnderstand the work, find the point of leverage, redesign the process, control the risks, bring employees with you and prove that the business is better afterwards.\nThe biggest AI gains rarely come from dropping a new tool into an old process. They come from making a few intelligent changes to how information flows, decisions are made and people spend their time.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/expertise-lies-in-connecting-technology-and-operations/","section":"Our Experience","summary":"The value of an AI specialist is not simply knowing which tools or models are available. It is understanding how work happens inside a business and knowing how technology, process and people must change together to produce a worthwhile result.\n","title":"Expertise lies in connecting technology and operations","type":"our-experience"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":" \u0026ldquo;the fox knows many things, but the hedgehog knows one big thing\u0026rdquo; # There\u0026rsquo;s a line from the Greek poet Archilochus that Isaiah Berlin turned into one of the most-borrowed ideas in modern thinking: \u0026ldquo;The fox knows many things, but the hedgehog knows one big thing.\u0026rdquo;\nBerlin used it to split thinkers in two. Hedgehogs relate everything back to a single, organising idea - one big theory of how the world works, applied everywhere. Foxes draw on a wide range of experiences, hold several ideas at once, and are comfortable with the fact that they don\u0026rsquo;t fully agree with each other.\nMost founders are natural born hedgehogs. To build something from nothing usually requires a big idea and a lot of stubborn ambition to get that out of the gate. It’s an awesome trait but one that doesn’t always lead to the long term success of the business.\nWe’ve been involved in many early stage startups and usually, about 12-18 months in, the ‘big idea’ has more or less been built. At this stage two things are happening:\nAll the obvious things have been built The idea may not quite be what the target market wants. Either way, the next steps aren’t obvious and require someone to do the homework - look at the data, review customer feedback, more in-depth market research all of which are more fox-like traits.\nThere must be a few founders out there able to make the mental switch but that’s less common. Often I’ve seen a few try to make the next step another big idea and that never works. The team just burn out trying to boil ever increasing oceans.\nBest thing is to hire a really confident Product Manager that isn’t scared to push back, someone that may not always live and breath the idea but is able to make the kind of objective and painful calls because they’re less emotionally attached.\nThat will increase the chance of your idea moving beyond the faithful early adopters. Next comes the scale up phase where the person in charge needs to understand organisations, marketing and people. That’s a whole other story.\n","date":"9 September 2026","externalUrl":null,"permalink":"/our-experience/opinions/hedgehogs-foxes-and-founders/","section":"Our Experience","summary":"“the fox knows many things, but the hedgehog knows one big thing” # There’s a line from the Greek poet Archilochus that Isaiah Berlin turned into one of the most-borrowed ideas in modern thinking: “The fox knows many things, but the hedgehog knows one big thing.”\n","title":"Hedgehogs, Foxes and Founders","type":"our-experience"},{"content":"We don\u0026rsquo;t sit on the fence. These are our honest, sometimes contrarian, takes on where AI is heading and what\u0026rsquo;s actually worth paying attention to.\nThe focus is always on what we believe based on what we\u0026rsquo;ve built and seen — not on repeating whatever the loudest voice in the room is saying this week.\n","date":"9 September 2026","externalUrl":null,"permalink":"/our-experience/opinions/","section":"Our Experience","summary":"We don’t sit on the fence. These are our honest, sometimes contrarian, takes on where AI is heading and what’s actually worth paying attention to.\nThe focus is always on what we believe based on what we’ve built and seen — not on repeating whatever the loudest voice in the room is saying this week.\n","title":"Opinions on AI","type":"our-experience"},{"content":"We work with AI every day. We build things with it, we think hard about it, and we\u0026rsquo;ve made enough mistakes with it to have something worth saying.\nWe write articles when something is worth writing down — a pattern we keep seeing, an assumption that turned out to be wrong, something we learned the hard way that might save you a few painful hours. We\u0026rsquo;re not trying to cover everything. We\u0026rsquo;re trying to tell you about the things we\u0026rsquo;ve found to be useful.\nWe also record podcasts when a conversation is better had out loud. Some ideas need the back-and-forth. Some things are easier to say than to write.\nIf you\u0026rsquo;re working with AI and trying to figure out what\u0026rsquo;s real and what\u0026rsquo;s noise, you\u0026rsquo;re in the right place.\nRead our articles →\n","date":"9 September 2026","externalUrl":null,"permalink":"/our-experience/","section":"Our Experience","summary":"We work with AI every day. We build things with it, we think hard about it, and we’ve made enough mistakes with it to have something worth saying.\nWe write articles when something is worth writing down — a pattern we keep seeing, an assumption that turned out to be wrong, something we learned the hard way that might save you a few painful hours. We’re not trying to cover everything. We’re trying to tell you about the things we’ve found to be useful.\n","title":"Our Experience","type":"our-experience"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/","section":"repace.ai","summary":"","title":"repace.ai","type":"page"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/authors/steve_creedon/","section":"Authors","summary":"","title":"Steve Creedon","type":"authors"},{"content":"We write these when something\u0026rsquo;s worth writing down - a pattern we keep seeing, an assumption that turned out wrong, a lesson we learned the hard way. No theory for the sake of theory. Just what we\u0026rsquo;ve actually found useful.\n","date":"25 August 2026","externalUrl":null,"permalink":"/our-experience/articles/","section":"Our Experience","summary":"We write these when something’s worth writing down - a pattern we keep seeing, an assumption that turned out wrong, a lesson we learned the hard way. No theory for the sake of theory. Just what we’ve actually found useful.\n","title":"Articles on AI","type":"our-experience"},{"content":"This is Part 3 of a three-part series on building an MVP in the UK. Part 1 covers what an MVP costs and how long it takes, and Part 2 covers what actually belongs in one. Here we put both into practice on a real project.\nThe brief # Let\u0026rsquo;s talk about a real application - one we\u0026rsquo;re actively working on. The founder makes her living as a singer, so she travels to gigs around the country, taking her dog whenever she can. The app she wants to build is a sort of \u0026ldquo;TripAdvisor for dog owners\u0026rdquo; - a site that showcases dog-friendly hotels, bars and cafes, so people out with their dogs can find places where both they and the canine part of the family are welcome.\nFirst contact was a list of features that didn\u0026rsquo;t really tell us why customers would use the system. This isn\u0026rsquo;t uncommon - founders naturally have specialised knowledge of their subject and don\u0026rsquo;t always realise why others don\u0026rsquo;t \u0026ldquo;get it\u0026rdquo; straight away. To them the benefits are self-evident, so we get a list of features. We don\u0026rsquo;t own or travel with dogs, so to us it was a lot less obvious.\nDoes it have legs? A free service to discuss your ideas # The internet is full of ideas. Far too many solve problems people either don\u0026rsquo;t have or are unwilling to pay for. Before engaging with anyone, we like to be as certain as we can that their idea has legs. It\u0026rsquo;s not our style to just take the money, so we offer an initial \u0026ldquo;does it have legs\u0026rdquo; conversation for free, just so everyone\u0026rsquo;s clear on why users will love using what we build.\nAfter a fun hour bouncing ideas around, we agreed the main benefits were:\nUsers find cafes, bars and pubs where they can go with their dog Members contribute to the site, so venues stay current and relevant for the dog-loving community Members create personalised lists of places they\u0026rsquo;ve liked or want to visit, and share those lists with others Members share venues they\u0026rsquo;ve liked on social media Members can plan dog-friendly trips and journeys Businesses can update their listing and respond to reviews Businesses can advertise offers We followed up with a little homework of our own and, a little surprisingly, couldn\u0026rsquo;t find anything similar already out there. The founder isn\u0026rsquo;t looking to build a billion-dollar company, just something that returns revenue commensurate with the work put in.\nSo let\u0026rsquo;s start thinking about what this MVP looks like. The smallest possible thing that would validate the idea is the first benefit - users finding cafes, bars and pubs where they can go with their dog. That activity underpins every other member and business benefit on the list, so it\u0026rsquo;s clearly our MVP.\nBest possible MVP, not just best guess # Based on the matrix in Part 1, this looked like a \u0026ldquo;Simple web MVP\u0026rdquo;. In old-school development terms that\u0026rsquo;s 2-6 months and £10k-£30k. In our AI-first world, that\u0026rsquo;s £10,000-£18,000 in 10-18 days.\nThe spend is lower and the time is a lot shorter, but really the most important thing AI gives us here is the ability to produce a working prototype fast.\nBefore AI, we\u0026rsquo;d probably have advised that this wasn\u0026rsquo;t a viable project - the build costs would have been too high relative to what the founder could commit:\nWeeks of planning and design requiring significant input from the founder Months developing the best guess that came out of that planning and design phase With AI this is now a viable prospect, because it changes the way we build things:\nWe produce a prototype in a couple of weeks We then iterate on that with the founder, to get to the best possible MVP, not just the best guess An MVP is the smallest usable version of a product that can test an important business assumption with real users. Real users are there for the benefits, so an MVP should always start with the most valuable benefit - and we get to that by turning the feature list into stories that illustrate how users will actually interact with the site.\nFrom feature wishlist to user journeys # You\u0026rsquo;ve probably come across the old trope \u0026ldquo;emphasise the benefits, not the features\u0026rdquo; - easily said, but it doesn\u0026rsquo;t really explain how founders tell us what they want us to build. A benefit such as \u0026ldquo;easily buy a shirt online\u0026rdquo; is supported by multiple features: search, shirt collections, a product page, add-to-basket, checkout.\nThis founder had done her homework and had sketches of how she\u0026rsquo;d like the site to look, plus a substantial shopping list of features:\nSearch for dog-friendly venues Detailed venue pages The ability for users to leave reviews and upload photos The ability to moderate those reviews A blog where the site owner can give personal reviews Saved places and lists for users who\u0026rsquo;ve created an account Detailed walks, or walk-and-pub combinations Trip planning Accommodation Beaches Special offers Events Business accounts and analytics Booking and affiliate integrations Founders dream big, and rarely come to us with just an MVP in mind. It\u0026rsquo;s a lot to build up front, and a good MVP validates the idea before too much time and money is spent on it. That validation matters, because first contact with real customers can easily change the plan - and successful founders tend to be the ones who give their customers what they actually want.\nTo distil a strong MVP from a feature list like this, we group the underlying user journeys into categories. For this community-based site, those categories were:\nFinding somewhere I can go with my dog Contribution journeys Community journeys Social journeys Trip and personalisation journeys Business journeys Admin journeys Within the first category alone, the stories look something like:\n\u0026ldquo;Find somewhere dog-friendly\u0026rdquo; \u0026ldquo;Find somewhere near me\u0026rdquo; \u0026ldquo;Is this place dog-friendly?\u0026rdquo; \u0026ldquo;Find somewhere suitable for my particular dog\u0026rdquo; \u0026ldquo;Discover somewhere new\u0026rdquo; \u0026ldquo;Find a walk with somewhere to eat afterwards\u0026rdquo; \u0026ldquo;Plan a dog-friendly day out\u0026rdquo; \u0026ldquo;Plan a dog-friendly holiday\u0026rdquo; The core proposition # The core proposition for this site is that users can search for dog-friendly venues by location and get helpful information about each one. Anything that supports this is in the MVP; anything that doesn\u0026rsquo;t can wait.\nYou could argue the blog isn\u0026rsquo;t strictly MVP, but the founder is a dog owner herself, and her personal input into the site is a key part of establishing trust in the brand early on - so it stayed in scope.\nBeyond the core proposition, there\u0026rsquo;s plenty more the site can eventually do, but none of it can exist without the core proposition in place first:\nSaved places and lists for users with accounts Detailed walks or walk-and-pub combinations Trip planning Accommodation Beaches Events Special offers Nearby vets and services Business accounts and analytics Booking and affiliate integrations All of that becomes the roadmap for what comes after the MVP proves the core idea out.\nOne thing worth remembering # If your product is novel, your MVP can stay quite basic, because you\u0026rsquo;ll attract early adopters happy to look past the rough edges - though that\u0026rsquo;s a mixed blessing, since early adopters can give you a misleadingly rosy read on demand.\nIf your product isn\u0026rsquo;t novel - e-commerce selling everyday things, say - you\u0026rsquo;ll need to get closer to the existing competition before users take you seriously. The upside is you already know what works, because someone else has already proven it.\nThat\u0026rsquo;s the whole arc: from a long list of features, to a handful of real benefits, to the one workflow that has to exist before anything else does. If you\u0026rsquo;re sitting on a feature list of your own and aren\u0026rsquo;t sure what the smallest viable version looks like, that \u0026ldquo;does it have legs\u0026rdquo; conversation is free - get in touch.\n","date":"25 August 2026","externalUrl":null,"permalink":"/our-experience/articles/building-an-mvp-a-worked-example/","section":"Our Experience","summary":"This is Part 3 of a three-part series on building an MVP in the UK. Part 1 covers what an MVP costs and how long it takes, and Part 2 covers what actually belongs in one. Here we put both into practice on a real project.\n","title":"Building an MVP: A Worked Example","type":"our-experience"},{"content":"","date":"25 August 2026","externalUrl":null,"permalink":"/series/how-much-mvp/","section":"Series","summary":"","title":"How Much MVP","type":"series"},{"content":"","date":"25 August 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"This is Part 2 of a three-part series on building an MVP in the UK. Part 1 covers what an MVP costs and how long it takes. Part 3 walks through a real MVP from first conversation to build.\nWhat is an MVP? # I often struggle to remember the true meaning of acronyms, so for the avoidance of doubt: MVP means \u0026ldquo;Minimum Viable Product\u0026rdquo;.\nViable is the key word here. An MVP is not:\nA clickable prototype A proof of concept An inexpensive version of the complete product A poorly finished application The first phase of a large predetermined specification An MVP is the smallest possible thing your users could get some value from. A prototype e-commerce site would let you select products and add them to a basket, but to be an MVP, users need to actually be able to buy something.\nI say \u0026ldquo;could get some value from\u0026rdquo; because MVPs are just as likely to demonstrate something doesn\u0026rsquo;t work as they are that it does. This is where founders often falter or flourish.\nIf you\u0026rsquo;re wondering why we differentiate between \u0026ldquo;Production-ready\u0026rdquo; and \u0026ldquo;Complex\u0026rdquo; MVPs in Part 1, it\u0026rsquo;s really a mark of how novel the system is. Two projects we undertook recently illustrate this well:\nThe first was an educational platform for a group of schools in the UAE. They had an existing platform that worked but didn\u0026rsquo;t quite fit their needs, and could clearly demonstrate what parts of their existing toolset worked and what needed improving. A straightforward proposition with few dragons waiting to catch us out. The other was for a startup that converts chemical waste into inert, usable materials. They wanted AI agents to help design unique systems tailored to each process. That was complex. What drives complexity in an MVP # Users # A starting point when thinking about potential complexity is simply the number of everyday users and the varied things those users must do.\nAn e-commerce site has one everyday user and one workflow - customers search for products, add to basket, checkout and pay.\nOur Ed Tech app had multiple users:\nTutors create questions Tutors create tests Tutors start and stop instances of those tests Students complete the tests Tutors mark the completed tests Students read the feedback from those tests Tutors see the performance of students across their tests These workflows are governed by permissions - tutors and students can only interact with their own questions and assessments, so they aren\u0026rsquo;t just a user type, they\u0026rsquo;re users who can only interact with certain things.\nPeople often overlook the complexity surrounding the administration of a site - also known as the \u0026ldquo;back office\u0026rdquo;. An e-commerce website needs mechanisms for people to upload new products, check the status of orders, or organise collections of similar products such as \u0026ldquo;sofas\u0026rdquo; or \u0026ldquo;menswear\u0026rdquo;.\nMobile # We\u0026rsquo;re still surprised at the number of founders who also want a native iOS or Android app on day one. That isn\u0026rsquo;t an MVP, it\u0026rsquo;s three - each with its own team of developers.\nModern responsive web applications will give you 90% of the functionality of a native mobile app. Unless your startup idea is genuinely mobile-only, going native will certainly cost you time and money you don\u0026rsquo;t have.\nIntegrations # Most systems have to integrate with something - in our experience that\u0026rsquo;s typically a payment gateway so people can buy things, and an email provider so the system can send and receive emails from and to users.\nThese days we\u0026rsquo;re also increasingly integrating with agents and LLMs, which bring their own complexity.\nProduct design # Don\u0026rsquo;t get too hung up on design for an MVP if you can help it. If your idea isn\u0026rsquo;t that novel, you should be able to borrow heavily from existing systems. If it is novel, your first customers will be \u0026ldquo;early adopters\u0026rdquo; who really want the functionality you\u0026rsquo;re offering and don\u0026rsquo;t care too much how it looks.\nData and AI # If you\u0026rsquo;re in Europe or the UK you need to consider GDPR. Despite all the scare stories from people selling their services, GDPR isn\u0026rsquo;t that complex once you understand that all it\u0026rsquo;s doing is balancing your need to keep personal data with the benefit that data gives your customers.\nIt\u0026rsquo;s not just about sending the data, either. For example, our expense system shares expense data with an LLM, some of which can contain names and addresses - we have to be careful to strip out any personal information before sending anything to an external third party such as Claude or ChatGPT.\nSecurity and regulation # These days decent security is available out of the box if you know where to look. If your startup has elevated security needs, it probably means investing in a good development team for your MVP more than hiring specific security functions or roles.\nFintechs often have additional requirements, especially if they\u0026rsquo;re governed by the FCA, who may require some minimum liquidity of cash in the bank to protect your customers.\nDIY or agency - where does the money go? # It\u0026rsquo;s not really about who can write the code — most of what follows is the same list of work whichever route you take. It\u0026rsquo;s about how many people you\u0026rsquo;re paying to hold each item on that list.\nA full agency engagement typically staffs each of these as a distinct role, often a distinct person:\nTechnical architecture Front-end development Back-end development Infrastructure and deployment Testing and quality assurance Product definition and scope UX/UI design Security and privacy Documentation and handover Project management Product management Launch support None of that is padding — it\u0026rsquo;s all genuinely necessary work. But an agency usually bills each of these as a separate specialist, plus an account or project management layer that sits above them to coordinate the handoffs. That coordination is real cost, and it exists whether or not your MVP actually needs that much specialisation.\nA lean team (like us) collapses most of that list into the one, two or three senior generalists that set the numbers in Part 1 — the same work, done by people who\u0026rsquo;ve done all of these roles before and can move between them without a handoff. You\u0026rsquo;re still paying senior rates. You\u0026rsquo;re just paying far fewer of them, with no coordination layer sitting in between.\nNext\u0026hellip; # In Part 3 we put all of this into practice on a real project - a \u0026ldquo;TripAdvisor for dog owners\u0026rdquo; - and show exactly how a long founder wishlist gets distilled down to a buildable MVP.\nIf you\u0026rsquo;ve got a list of features and aren\u0026rsquo;t sure what\u0026rsquo;s actually MVP, that\u0026rsquo;s exactly what our free \u0026ldquo;does it have legs?\u0026rdquo; conversation is for. Get in touch and we\u0026rsquo;ll help you find the smallest version worth building.\n","date":"24 August 2026","externalUrl":null,"permalink":"/our-experience/articles/what-is-an-mvp/","section":"Our Experience","summary":"This is Part 2 of a three-part series on building an MVP in the UK. Part 1 covers what an MVP costs and how long it takes. Part 3 walks through a real MVP from first conversation to build.\n","title":"What Is an MVP, Really? And What Actually Drives Its Cost","type":"our-experience"},{"content":"This is Part 1 of a three-part series on building an MVP in the UK. Part 2 looks at what actually belongs in an MVP, and Part 3 walks through a real MVP from first conversation to build.\nTLDR - how long will it take and how much will it cost? # Thanks to AI the simple answer is \u0026ldquo;much less than it did a year ago\u0026rdquo;. This article looks at what you can expect from an MVP, how much it costs and how long it may take to build.\nWe\u0026rsquo;ve been building things for a long time now. Before AI was a thing, a VERY common pattern for getting a startup off the ground was:\nBuild an MVP using the cheapest people you can find, typically an agency overseas. These agencies had no long term interest in the quality of the codebase - just get it out the door fast using the cheapest engineers they could find. You get what you pay for. Hand what was already a struggling \u0026ldquo;MVP\u0026rdquo; to engineers like us to fix and evolve beyond MVP stage. Because of that we only got involved at the last two stages - \u0026ldquo;Production-ready MVP\u0026rdquo; and \u0026ldquo;Complex MVP\u0026rdquo; - so the last two rows below are an aggregate of our experience, the first two our best guesses when extrapolating back. Before AI, times and costs looked like this:\nProduct type Indicative budget Duration Typical characteristics Interactive prototype £5,000–£10,000 1-2 months Demonstrates the idea but has limited or no production functionality Simple web MVP £10,000–£30,000 2-6 months One main user type and one core workflow Production-ready MVP £60,000–£90,000 6 - 9 months Authentication, administration, integrations and proper deployment Complex MVP £150,000–£300,000+ 9-18 months Multiple user types, AI, payments, mobile apps or compliance requirements You\u0026rsquo;ve probably noticed the jumps in indicative budget. These numbers are based on the notion that simpler apps need a single developer, a production-ready MVP typically needs 2 developers and a complex MVP 3 developers.\nWe\u0026rsquo;ve also excluded any other roles such as Product Managers or Designers, on the assumption the founder is driving everything up to MVP.\nAfter AI, it looks like this:\nProduct type Indicative budget Duration Typical characteristics Interactive prototype £5,000–£10,000 5-10 days Demonstrates the idea but has limited or no production functionality Simple web MVP £10,000–£18,000 10-18 days One main user type and one core workflow Production-ready MVP £18,000–£30,000 19-30 days Authentication, administration, integrations and proper deployment Complex MVP £45,000–£180,000+ 30-120 days Multiple user types, AI, payments, mobile apps or compliance requirements You\u0026rsquo;ll notice the simpler MVPs aren\u0026rsquo;t much cheaper despite being significantly quicker builds. The logic is that a single senior product engineer is required at a greater daily rate.\nThe complex MVP shows a bigger leap in cost, since two developers are generally needed for the build phase - though not for the requirements phase.\nIf you\u0026rsquo;re wondering what the difference between a Production-ready and a Complex MVP is, we cover that in Part 2.\nControlling costs - reclaim money from HMRC # If you can demonstrate that you are solving scientific or technological uncertainty you can claim significant returns from HMRC as R\u0026amp;D tax credits.\nThis isn\u0026rsquo;t always as onerous as it may seem. For example a recent project we\u0026rsquo;ve worked on was an insurtech that embedded the ability to insure products in other people\u0026rsquo;s e-commerce websites. HMRC accepted this as R\u0026amp;D not because no one else offered the service, but because there was no known, reliable way to embed real-time insurance underwriting into someone else\u0026rsquo;s checkout flow — that gap in existing knowledge is what the relief is designed for.\nThat said, the e-commerce websites that the system is embedded into would NOT be eligible for tax credits as e-commerce is a well-solved problem.\nNote, this isn\u0026rsquo;t tax advice — always confirm eligibility with a specialist before claiming, such as Forrest Brown.\nAI\u0026rsquo;s unexpected superpower # AI tools have reinvented the way we build software by writing much of the code that humans would otherwise write, and that\u0026rsquo;s brought major benefits - though maybe not the ones you\u0026rsquo;d expect.\nCosts have dropped, for sure. But to take advantage of that you need experienced developers who can instruct AI tools on what to build - a skill many coders don\u0026rsquo;t possess, having spent their careers working out what \u0026ldquo;good\u0026rdquo; looks like as they code rather than directing someone else to do it. Developers without that experience either avoid AI tools altogether or \u0026ldquo;vibe-code\u0026rdquo; - an AI-assisted way of making it up as you go along, just a bit quicker and burning through ever-more tokens. We\u0026rsquo;ve never found much value in vibe-coding, and what little there is fades fast as an application grows in complexity.\nThe real benefit is the speed with which experienced developers can produce a prototype and then iterate as everyone learns what works and what doesn\u0026rsquo;t. Instead of a founder spending weeks with a Product Manager turning ideas into detailed requirements, we start from minimal input, add years of knowledge and experience, and produce a prototype in days rather than months. The founder gets early access to something real, not imagined, and from there we iterate together until the application is just right.\nNext\u0026hellip; # That\u0026rsquo;s the theory. In Part 2 we go into more detail on what actually belongs in an MVP, and in Part 3 we walk through exactly how this played out on a real project.\nEvery project is different, so the fastest way to get a real number for yours is to talk to us. We offer a free \u0026ldquo;does it have legs?\u0026rdquo; call, no pitch, just an honest read on what you\u0026rsquo;re building and roughly what it\u0026rsquo;ll cost. Get in touch.\n","date":"23 August 2026","externalUrl":null,"permalink":"/our-experience/articles/how-much-does-it-cost-to-build-an-mvp-in-the-uk/","section":"Our Experience","summary":"This is Part 1 of a three-part series on building an MVP in the UK. Part 2 looks at what actually belongs in an MVP, and Part 3 walks through a real MVP from first conversation to build.\n","title":"How Much Does It Cost to Build an MVP in the UK? (2026)","type":"our-experience"},{"content":"AI developer tools are heavily subsidised , with labs and platforms often providing power users 15 to 30 times more value in underlying compute and token costs than they charge in flat monthly subscriptions. For heavy users running intensive agentic workflows, a standard $200/month subscription can easily rack up $3,000 to $5,500+ in API-equivalent compute costs\nUnderstandably a lot of people are nervous about where this is all going and it\u0026rsquo;s a question we\u0026rsquo;re often asked. Predicting the future is notoriously hard however this is how I see a future that balances humans with cost:\nShort to mid term I see models like Fable being used for detailed planning and architecture then open models run by the company doing the development to implement that plan in code.\nUltimately it feels that the AI providers are building things way smarter and way more expensive than most of us need - a bit like hiring a PhD in rocket science to build your webapp. Amazing to watch but just not fit for purpose.\nIf I had to put money on it I would see the balance being open models run locally for dev teams with predictable costs and fewer security issues that provide human developers with the tools to be fast and efficient rather than AGI bots doing it all at huge \u0026amp; unpredictable cost and not inconsiderable risk.\nFor more on why chasing the biggest model rarely translates into better outcomes, see the challenge of AI adoption.\n","date":"13 August 2026","externalUrl":null,"permalink":"/our-experience/opinions/balancing-ai-tooling-costs-the-future/","section":"Our Experience","summary":"AI developer tools are heavily subsidised , with labs and platforms often providing power users 15 to 30 times more value in underlying compute and token costs than they charge in flat monthly subscriptions. For heavy users running intensive agentic workflows, a standard $200/month subscription can easily rack up $3,000 to $5,500+ in API-equivalent compute costs\n","title":"Balancing AI Tooling Costs - The Future","type":"our-experience"},{"content":"IKEA used AI to automate routine customer service, then moved the staff it freed up into a new role - and that role now brings in over a billion euros a year.\nThat\u0026rsquo;s a useful counterpoint to the usual AI story, where automation just means fewer jobs. IKEA\u0026rsquo;s version reshaped roles instead of cutting them.\nAI takes the routine questions first # IKEA built an AI assistant called Billy to handle first-line customer interactions - order tracking, product questions, general support.\nBilly now handles around 57% of customer conversations without a person involved, according to one estimate from Info-Tech Research Group. That\u0026rsquo;s a big share of the support team\u0026rsquo;s workload gone.\nNothing unusual there. Plenty of companies are pointing AI at high-volume, repetitive support work.\nThe questions left over turned out to be about design, not orders # What IKEA did next is the interesting part. Instead of treating the remaining 43% of conversations as a cost problem, it looked at what those conversations actually were.\nMost weren\u0026rsquo;t transactional. Customers weren\u0026rsquo;t asking \u0026ldquo;where\u0026rsquo;s my order\u0026rdquo; - they were asking for help planning a room, or a whole space.\nSo instead of shrinking the team further, IKEA retrained part of its customer service staff as interior design consultants. The job changed from answering routine queries to giving the advice people were already asking for.\nThat advice became a paid service # IKEA turned the insight into a paid design consultancy. In its first year, the offering is estimated to have brought in close to €1 billion in additional revenue.\nThat\u0026rsquo;s the real story: the efficiency AI created didn\u0026rsquo;t just cut cost, it funded a service line the company didn\u0026rsquo;t have before.\nIt\u0026rsquo;s also a useful contrast to Klarna, which replaced hundreds of support agents with AI and then brought people back after service quality suffered. IKEA keeps AI on the high-volume, low-judgement work and gives people the parts that actually need judgement.\nAutomation can create jobs, not just remove them # The lesson isn\u0026rsquo;t \u0026ldquo;AI is good\u0026rdquo; or \u0026ldquo;AI is bad for jobs.\u0026rdquo; It\u0026rsquo;s that the outcome depends on what a company does with the capacity AI frees up.\nCut the team and pocket the savings, and AI looks like a threat to jobs. Look hard at what people are actually being asked for once the routine work disappears, and it can fund something the company didn\u0026rsquo;t have before.\nThis is the pattern we call redesign the human role - AI doesn\u0026rsquo;t just remove work, it can free people to do something more valuable.\n","date":"22 July 2026","externalUrl":null,"permalink":"/our-experience/articles/ikea-frees-staff-to-be-creative/","section":"Our Experience","summary":"IKEA used AI to automate routine customer service, then moved the staff it freed up into a new role - and that role now brings in over a billion euros a year.\n","title":"IKEA frees staff to be creative","type":"our-experience"},{"content":"First a little about me. I truly believe that AI can help organisations produce better things faster when used well and since I don\u0026rsquo;t intend this to be a linkedin article I\u0026rsquo;m going to give you my view on what \u0026ldquo;Used Well\u0026rdquo; looks like.\nIt\u0026rsquo;s just too early for any opinions, especially my own, to be anything more than a well-educated guess. There are no right or wrong answers to the problems of AI adoption and anyone who tells you there are is almost certainly trying to sell something. This article is a collection of my own experiences, conversations I\u0026rsquo;ve had with others and things that I have read that feel like they\u0026rsquo;re improving our knowledge of solid AI practices.\nAlmost every organisation I talk with seems to tip-toe around the subject of AI adoption. I say tip-toe because in most cases no-one is able to articulate what they want from AI other than a fear of missing out or pressure from investors or CEOs.\nIf that\u0026rsquo;s touched a nerve then don\u0026rsquo;t fret. It\u0026rsquo;s early days and we\u0026rsquo;re all making this up as we go along. What doesn\u0026rsquo;t help is the constant claim, counter-claim and irresponsible hype from the big tech competitors as they vie with each other to grab AI market share by the throat.\nMost companies are aware that some of their developers use AI tools a lot, some use them a bit whilst others are pushing back. No-one seems able to measure effective usage or the benefits that usage brings only the sure knowledge that these wonder tools come with ever-increasing costs.\nSo what does AI adoption even mean ? # AI tooling doesn\u0026rsquo;t just make development faster, it can also change the process by which better products can be made. Let\u0026rsquo;s take a quick look at each.\nSpeed of Development # This is so difficult to pin down. Vendors such as Github Co-Pilot often claim to have benchmarked 55% increases in development speed but these are usually under \u0026rsquo;lab\u0026rsquo; conditions. Working with AI tools on a new system that isn\u0026rsquo;t yet in production is very, very different to working on an existing one in production with real end-users.\nAt the other end of the scale a study on Open Source development demonstrated that AI slowed developers by about 19% when, interestingly, the developers subjectively felt they were 20% faster.\nGenerally independent studies seem to benchmark increases in productivity about 20-40% though it\u0026rsquo;s worth noting that AI tooling and models have evolved significantly since any of these studies were made.\nAs for my own, more current, experiences just pure code crunching with AI tools I\u0026rsquo;d summarise them as:\nBuilding a working prototype from scratch - weeks become days as long as I have domain knowledge or good access to someone that has. The bulk of my coding experience is Python and Ruby. If I\u0026rsquo;m writing backend code in either of these languages the 30-40% uplift in output feels about right. Much greater gains can be had on less familiar parts of the tech stack. I\u0026rsquo;m not that excited by front-end tools like React and find this kind of tasks to be a chore. Not only is AI coding way faster than me at writing the code I\u0026rsquo;m sure it does a much better job. I have significant DevOps experience, especially with Terraform, so I know what good looks like but I don\u0026rsquo;t use Terraform every day. Claude has built me several Terraform setups for things like static websites and Lambda-based applications in minutes that would typically take me a day by the time I make my mistakes and get it all to work. Similarly AI tools frequently save me small amounts of time here and there by asking them to commit working files, deploy something, merge a branch etc. All those chores that typically suck-up my time and sap my energy. Last and by no means least - debugging. All developers hit that wall where we just can\u0026rsquo;t get the f*cking thing to work. For me it\u0026rsquo;s usually something so trivial I just can\u0026rsquo;t see it any more or something poorly explained in the documentation. The number of times I\u0026rsquo;ve turned to Claude in total frustration to ask why something isn\u0026rsquo;t working only to get a simple and obvious breakdown of \u0026ldquo;why\u0026rdquo; - something I\u0026rsquo;d completely overlooked and/or quite obvious with hindsight. This alone is worth the token spend. Based on this experience I believe that AI coding tools are money well spent. I was always proud of my code and felt it was clean, well structured and readable but in all honesty these days I\u0026rsquo;d rather focus on specifying the problem than crafting lines of code. I don\u0026rsquo;t miss coding at all.\nWhat does \u0026lsquo;Used Well\u0026rsquo; actually look like ? # So I\u0026rsquo;ve given plenty of anecdotal evidence of why I like coding tools but my feeling is that the real benefits for any organisation are when they both change \u0026amp; formalise the way we all work. Formalisation makes the process measurable and removes the constant question of who is using the tools, how they\u0026rsquo;re using them \u0026amp; why.\nIn my experience there are two opportunities to change the way an organisation works, not just within the engineering team but also the entire lifecycle.\nChanging the way engineers work. # At developer level, the worst thing you can do is hand out AI tools and then measure success by how much each developer is spending on tokens. Spend tells you who\u0026rsquo;s using the tools, not who\u0026rsquo;s using them well. The two are easily confused and rarely the same thing. I\u0026rsquo;ve even heard developers talk about how they were gaming the system by creating large tasks for agents with little or no intention of using their output.\nThe challenge of agents is how to work with them effectively which to me means finding that sweet spot that balances cost and output. Getting this right feels more like real engineering than crafting code. AI isn\u0026rsquo;t magic if you only have a vague understanding of what you want to build a coding agent will amplify the old adage of garbage-in garbage-out to a terrifying degree whilst charging increasingly large amounts of money for the privilege.\nMany moons ago I was a civil engineer mostly building underground railway systems in London. We didn\u0026rsquo;t pour concrete or erect steel; we planned, specified and designed for others to do the craftsmanship. That experience made it natural for me to work this way with agents, thinking of them as tradesmen that did the real heavy lifting before I approved their output.\nWriting specifications is an art that doesn\u0026rsquo;t come naturally for most but I can honestly say that I have yet to write a specification where, at some point, I had to stop and think because the plan that was floating around in my head was incomplete.\nAt the moment I write Intent Driven Specifications which are slightly more structured than starting with a blank sheet and generally get me a much better result.\nI write specifications, get the agent to generate a written plan from that specification - this is usually an iterative process. If the plan is missing something I\u0026rsquo;ll improve the spec and get the agent to update the plan. When the plan is ready the agent builds the code, I check the output and adjust if necessary.\nThis is real engineering that makes efficient use of token spend, keeps me close enough to the code and prevents drift. I know there are people out there who believe that all I need do is create a specification and let the agent go do its stuff but that feels like a completely unnecessary risk - risk that huge amounts of tokens will be spent on the wrong thing and risk that something nasty may be going on in all that unseen code. Before pilots take off they cross check their systems and controls. Of course they could skip that and save time but at some point that could go badly wrong so why take the risk ?\nBest of all, spec driven development in whatever flavour is a formalised process that can be measured and the artefacts that developers produce - specifications and plans - are a much better metric than token spend.\nChanging the Software Development Lifecycle # As I mentioned above specifying is hard and that\u0026rsquo;s no different for clients, customers and stakeholders. Pretty much everything we buy has been manufactured so we\u0026rsquo;ve lost the art of thinking about what we want and conveying that to others.\nAll too often typical Software Development Cycles result, eventually, in something that the stakeholders may have asked for but now they see it maybe they should have asked for something a little different. In some enterprise cultures this process can be so prolonged that requirements change, the stakeholders tell you it wasn\u0026rsquo;t that important or they simply forget why they wanted it in the first place. Either way it inevitably results in difficult conversations, varying degrees of compromise and something going live that could have been better.\nAgents can create working prototypes fast giving whoever was asking for the system or feature a chance to feedback early on whether that was what they wanted. Twice now I\u0026rsquo;ve written a specification, had an agent build it, demoed the result, and watched the stakeholders realise that wasn\u0026rsquo;t what they meant—or that I\u0026rsquo;d misunderstood them in the first place. In the old world, that just left us all feeling deflated but now I\u0026rsquo;m familiar with my spec, I was now familiar enough with version 2 of whatever it was the stakeholders wanted so I could get the next iteration ready to demonstrate literally in the time it took me to drink a double espresso.\nAI doesn\u0026rsquo;t just make us faster at building the thing—it makes us faster at finding out which thing to build, which is where most projects go wrong in the first place. Hard to benchmark but I\u0026rsquo;ll wager good money that outcomes are significantly better.\nThe Real Measure of AI Adoption # Perhaps that is the most useful way to think about AI adoption. It isn\u0026rsquo;t a race to produce more code, consume more tokens or claim the largest productivity increase. It is an opportunity to shorten the distance between an idea and the evidence that tells us whether the idea is any good.\nUsed well, AI makes misunderstandings cheaper. It allows engineers and stakeholders to test their assumptions while changing direction is still easy, rather than discovering months later that they have efficiently built the wrong thing.\nSo the question I would ask of any AI adoption programme is not, “How much faster are our developers coding?” It is, “How much faster are we learning what is worth building?”\nThat is harder to put on a dashboard than token spend. It is also far more likely to produce better software.\nIf you want the shorter, more practical version of this argument, we\u0026rsquo;ve distilled it into two recipes: measure business outcomes, not AI activity and why AI tools alone won\u0026rsquo;t guarantee ROI.\n","date":"26 June 2026","externalUrl":null,"permalink":"/our-experience/articles/the-challenge-of-ai-adoption/","section":"Our Experience","summary":"First a little about me. I truly believe that AI can help organisations produce better things faster when used well and since I don’t intend this to be a linkedin article I’m going to give you my view on what “Used Well” looks like.\n","title":"The challenge of AI adoption","type":"our-experience"},{"content":" Getting Past the Blank Page # I\u0026rsquo;ve started to use AI to help me write articles. I\u0026rsquo;ve always enjoyed writing but often run out of steam, inspiration, direction, call it what you will, before the ideas in my head \u0026ldquo;hit the paper\u0026rdquo; in a coherent narrative that I am happy with. AI has certainly helped me get past that wall.\nIt\u0026rsquo;s great for making me think about structure - it forces me to list all the key points I want to make before starting - something I never used to do simply because I enjoy telling stories so happily started at the beginning to see where it took me - all too often that was nowhere special.\nElegant, but Wooden # I edit AI content ruthlessly. Out of the box I find it elegant but wooden. Beautiful words carefully constructed by a Mechanical Turk lacking anything that could be described as visceral or even memorable.\nThe more I edit, the more I see one common pattern - the disconnect between all those well-constructed sentences. The narrative is correct but the sentences are often less than the sum of their parts:\nCompare \u0026ldquo;You had to think about what you wanted. You had to articulate it\u0026rdquo; with \u0026ldquo;You thought about what you wanted then articulated that thought\u0026rdquo;.\nThe first sentences read as if each were written by a different author in some sort of parlour game. Knowing how LLMs work, that\u0026rsquo;s almost certainly true.\nThe Writer Still Has to Know Why # AI is a helpful tool, it can help me arrange the journey, but it still needs me to know why we are travelling.\n","date":"25 June 2026","externalUrl":null,"permalink":"/our-experience/articles/using-ai-to-write-articles/","section":"Our Experience","summary":"Getting Past the Blank Page # I’ve started to use AI to help me write articles. I’ve always enjoyed writing but often run out of steam, inspiration, direction, call it what you will, before the ideas in my head “hit the paper” in a coherent narrative that I am happy with. AI has certainly helped me get past that wall.\n","title":"I've started to use AI to help me write articles","type":"our-experience"},{"content":" The lost art of specification # Before the industrial revolution, if you wanted a suit, dress or furniture you thought about what you wanted, articulated that thought to a craftsperson and they made it for you. If the person making it was any good then they knew what questions to ask if there were any gaps. Getting that conversation right mattered because if the end result wasn\u0026rsquo;t what you wanted you\u0026rsquo;d lose money and a lot of time.\nThen manufacturing came along. Now almost everything we buy - from small things like a loaf of Hovis bread to large things like a Ford Galaxy - is at least the millionth version of itself. We browse, compare, and select but we never have to explain how much wheat goes into the loaf or how much torque a prop-shaft needs to withstand.\nI\u0026rsquo;ve spent my career building one-offs # I started out as a civil engineer. Bridges, tunnels, underground stations. Whatever I was a part of building there was only ever going to be one of those things. Getting the specification wrong didn\u0026rsquo;t mean we shipped bad feature — it meant we lost millions, wasted months and potentially injured people or worse. You think about the risks before the first concrete is poured and the 24/7 tunnel machine starts to dig.\nThen I moved to internet startups - a long story - but still found myself in a world that also builds one thing once. Every SaaS platform, every web product is intended to be unique so you\u0026rsquo;d think software engineers should be good at planningh. and specifying but oddly they weren\u0026rsquo;t. Planning isn\u0026rsquo;t easy, starting to code without a plan is - especially when the pressure is on to deliver.\nPRs are not Planning # I never really understood why the Pull Request was the one quality gate before code goes live. Don\u0026rsquo;t get ,e wrong, they\u0026rsquo;re massively useful but by the time that code is in review, the decision about what to build has already been made. If the idea was flawed then time has already been lost and there\u0026rsquo;s pressure to accept something that\u0026rsquo;s not really that for purpose. I\u0026rsquo;m convinced this is a major contributor to technical debt.\nSo I introduced Method Statements into teams. Before starting a piece of work, spend an hour or so writing down what you\u0026rsquo;re about to do — not just the happy path but consider the risks from dependencies on other teams, third-party providers you\u0026rsquo;re not sure about or technology you haven\u0026rsquo;t used before. When I first came across Method Statements in the construction industry I saw them as a massive beuracratic overhead - I knew how things were built why did I need to write that down on paper for someone else to rubber-stamp ? Well, writing a method statement forced me to write my thoughts down in a coherent narrative. I don\u0026rsquo;t believe there was a time when I was part-way through that process when I didn\u0026rsquo;t stop and think \u0026ldquo;hmm,.. I hadn\u0026rsquo;t thought about that.\u0026rdquo;\nSadly writing method statements in sofware never really stuck. The pull of just starting is too strong because planning feels like not-working even when it\u0026rsquo;s probably the most valuable thing you could be doing.\nAI doesn\u0026rsquo;t read minds # Then along came AI coding tools like Microsoft\u0026rsquo;s co-pilot and Anthropic\u0026rsquo;s Claude. I must admit to being a sceptic at first until Oz my colleague here at Repace.ai showed me how he used Claude - to plan and specify.\nAgents will write hundreds, possibly thousand of lines of code so if you want that code to bring value not drift or chaos then you have to be good at telling it what you want - aka a specification:\nthe desired outcome; users and use cases; constraints and exclusions; dependencies and assumptions; edge cases and failure modes; acceptance criteria. I took to it straight away and have barely written a line of code since. I thought I\u0026rsquo;d miss coding; I was proud of my skills and enjoyed crafting well structured code but I realised I enjoyed problem solving more and that I too had been caught in the time-consuming trap of code-construction.\nWhat truly sealed the deal for me was when I\u0026rsquo;d spent a couple of days putting together a spec then building the code was having the stakeholder tell me that, now they see it, that\u0026rsquo;s not really what they wanted and could it be like this instead (remember where we started with people not being good at articlulating what they want ?). Over an Espresso in my local Costa I rewrote parts of the spec, scrapped the agents code (no emotional attachment there) and within 2 hours I had a pivoted system up, running and fit for purpose.\nThe teams I see getting consistent results from AI tools are the ones who\u0026rsquo;ve developed the discipline to specify before they build. Not lengthy documentation for its own sake, but clear thinking about what success looks like, what the edge cases are, and what the thing definitely shouldn\u0026rsquo;t do.\nThat\u0026rsquo;s the skill. It\u0026rsquo;s not new. We\u0026rsquo;ve just had a century or so of not needing it, and now we do again.\nWe run workshops and hands-on sessions to help teams get better at working with AI — including the specification habits that make the difference. See how we help teams put AI to work or get in touch if that sounds useful.\n","date":"24 June 2026","externalUrl":null,"permalink":"/our-experience/articles/specifying-is-hard/","section":"Our Experience","summary":"The lost art of specification # Before the industrial revolution, if you wanted a suit, dress or furniture you thought about what you wanted, articulated that thought to a craftsperson and they made it for you. If the person making it was any good then they knew what questions to ask if there were any gaps. Getting that conversation right mattered because if the end result wasn’t what you wanted you’d lose money and a lot of time.\n","title":"Specifying is hard — and most of us have forgotten how to do it","type":"our-experience"},{"content":" Steve Sherif Abs Oz We're no oil paintings... But we are developers who got tired of watching good ideas die in slow build cycles. So we picked up AI, leaned in hard, and started shipping things faster than felt legal.\nThat\u0026rsquo;s the whole story, really. We\u0026rsquo;re builders first. AI just happens to be the best tool we\u0026rsquo;ve ever held.\nWhat we actually do # We help founders crystallise ideas into real products. You\u0026rsquo;ve got the vision in your head — half-formed, exciting, maybe a little chaotic. We turn that into something you can click on, test, and put in front of real users. Fast. No six-month roadmap, no \u0026ldquo;let\u0026rsquo;s circle back in Q3.\u0026rdquo;\nWe help dev teams move quicker without breaking things. AI tooling is everywhere right now, and most of it is noise. We\u0026rsquo;ve spent the hours figuring out what actually makes engineers faster — better workflows, smarter use of AI pair-programming, less busywork, more building. Then we bring that into your team.\nWhy we\u0026rsquo;re into this # Honestly? Building has never been this fun. A few years ago, turning an idea into a working product took months of grinding. Now we can sketch, prototype, and ship in days. We\u0026rsquo;re not here to hype AI for the sake of it — we\u0026rsquo;re here because it lets us do the thing we actually love (making stuff that works) more often, and faster.\nWe\u0026rsquo;ve been the founder staring at a blank repo wondering where to start. We\u0026rsquo;ve been the team lead watching velocity stall under technical debt. We built Repace.ai to be the people we wish we\u0026rsquo;d had in the room.\nHow we work # Fast, not sloppy. Speed without quality is just a different kind of slow — you end up rebuilding everything anyway. Hands-on, not theoretical. We write code, ship features, and get our hands dirty alongside your team. Honest, always. If your idea needs more validation before more code, we\u0026rsquo;ll say so. Let\u0026rsquo;s build something # If you\u0026rsquo;ve got an idea that needs crystallising, or a team that\u0026rsquo;s ready to move faster — we\u0026rsquo;d love to talk.\nGet in touch →\n","externalUrl":null,"permalink":"/about/","section":"About Us","summary":" Steve Sherif Abs Oz We're no oil paintings... But we are developers who got tired of watching good ideas die in slow build cycles. So we picked up AI, leaned in hard, and started shipping things faster than felt legal.\n","title":"About Us","type":"about"},{"content":"","externalUrl":null,"permalink":"/tags/ai-adoption/","section":"Tags","summary":"","title":"AI Adoption","type":"tags"},{"content":"","externalUrl":null,"permalink":"/our-experience/topics/","section":"Our Experience","summary":"","title":"AI by Industry","type":"our-experience"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-accounting/","section":"Topics","summary":"","title":"AI in Accounting","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-banking/","section":"Topics","summary":"","title":"AI in Banking","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-consulting/","section":"Topics","summary":"","title":"AI in Consulting","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-customer-service/","section":"Topics","summary":"","title":"AI in Customer Service","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-education/","section":"Topics","summary":"","title":"AI in Education","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-engineering/","section":"Topics","summary":"","title":"AI in Engineering","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-finance/","section":"Topics","summary":"","title":"AI in Finance","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-health/","section":"Topics","summary":"","title":"AI in Health","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-hr/","section":"Topics","summary":"","title":"AI in HR","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-insurance/","section":"Topics","summary":"","title":"AI in Insurance","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-legal/","section":"Topics","summary":"","title":"AI in Legal","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-logistics/","section":"Topics","summary":"","title":"AI in Logistics","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-manufacturing/","section":"Topics","summary":"","title":"AI in Manufacturing","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-pharma/","section":"Topics","summary":"","title":"AI in Pharma","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-project-management/","section":"Topics","summary":"","title":"AI in Project Management","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-property-management/","section":"Topics","summary":"","title":"AI in Property Management","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-recruitment/","section":"Topics","summary":"","title":"AI in Recruitment","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-retail/","section":"Topics","summary":"","title":"AI in Retail","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-sales/","section":"Topics","summary":"","title":"AI in Sales","type":"topics"},{"content":"","externalUrl":null,"permalink":"/topics/ai-in-utilities/","section":"Topics","summary":"","title":"AI in Utilities","type":"topics"},{"content":"The biggest mistake we make with AI is trying to decide whether it\u0026rsquo;s good or bad. It\u0026rsquo;s a powerful, unreliable technology sitting inside an industry that rewards exaggeration. Sometimes that produces comedy. Sometimes it produces genuine danger. And sometimes it produces real progress.\nThe circus comes to town # Every AI product launch follows the same script. Someone walks onto a stage and announces that work, education and possibly death have now been solved. The demo works perfectly, the valuation doubles, and nobody asks what happens when an actual customer tries to use it.\nRevolutionary. Human-level. About to replace an entire department. Six months from transforming civilisation. Every launch, the same four claims - because hype gets funded and modesty doesn\u0026rsquo;t.\nRegulators have started calling this out by name: \u0026ldquo;AI washing.\u0026rdquo; In 2024 the US Securities and Exchange Commission charged two investment advisers over false or misleading claims about their use of AI, and the Federal Trade Commission has gone after businesses selling supposed \u0026ldquo;AI lawyers\u0026rdquo; and automated money-making schemes that didn\u0026rsquo;t hold up.\nKlarna is the cleanest example. The company said its AI assistant did the work of 700 customer-service staff. It later admitted it had leaned too hard on the cost-cutting story and started hiring humans back to fix the service quality it had traded away. The lesson isn\u0026rsquo;t that AI delivers no productivity gains - it\u0026rsquo;s that one good experiment quickly turns into a sweeping claim about the end of employment.\nWhen it\u0026rsquo;s confidently wrong # Generative AI\u0026rsquo;s defining trait: it can be completely wrong without losing an ounce of confidence. A normal computer error looks like an error. An AI mistake is beautifully written, neatly formatted, and backed by references that don\u0026rsquo;t exist.\nInvented legal cases. Fake quotes. Company policies that were never written. Instructions that sound plausible and aren\u0026rsquo;t safe. Summaries that confidently reverse the point of the thing they\u0026rsquo;re summarising.\nAir Canada found this out the expensive way - a customer relied on bereavement-fare information its chatbot invented, and the airline was ordered to pay up after unsuccessfully arguing it shouldn\u0026rsquo;t be held to what its own chatbot had said. Lawyers have made the same mistake in court: by mid-2025, fabricated case citations were turning up not just in legal filings but in judicial rulings.\nThe funny part is that AI makes things up. The less funny part is how quickly people stop checking, because the answer looks so convincing. The real failure is rarely the model alone - it\u0026rsquo;s an unreliable system, a pressured human, a badly designed workflow, and nobody left to verify anything.\nWhen it stops being funny # Skip the science-fiction version of AI danger. The real threats are already here: deepfake fraud, cloned voices, automated scams, political disinformation, biased decisions made at scale, and people handing important calls to systems they don\u0026rsquo;t understand.\nArup found out how far this has come. An employee in Hong Kong joined what looked like a routine video call with senior colleagues and authorised fifteen transfers totalling roughly £20 million. Every face and voice on that call was fake.\nThe frightening thing about AI isn\u0026rsquo;t that a computer became human. It\u0026rsquo;s that computers have gotten good enough at imitating humans to exploit the trust everything else depends on. AI didn\u0026rsquo;t invent lying, fraud or propaganda - it just gave them industrial machinery.\nWhen it\u0026rsquo;s actually good # Step away from chatbots and generated images for a second. Some of the least theatrical uses of AI are doing the most real work.\nAlphaFold has predicted the structure of millions of proteins, handing researchers tools to chase down disease and treatments faster than was possible before - work now feeding into drug discovery, heart disease research and more resilient crops. In the NHS, AI-assisted scan analysis is helping clinicians spot blood clots faster, now running across more than 70 hospitals and getting stroke patients to specialist treatment sooner.\nEarlier disease detection. Faster weather prediction. Better fraud detection. Administrative work quietly removed from public services so people can do the parts of the job that actually need a person. None of it tries to replace a human - it just gives one more reach.\nThe actual point # Give it to an overexcited founder and it becomes a promise no technology could keep. Put it in an unchecked process and it becomes a confident generator of mistakes. Hand it to criminals and it becomes a machine for manufacturing trust and deception. Put it in the hands of a careful doctor, scientist or engineer, and it helps solve something that actually matters.\nThe future of AI won\u0026rsquo;t be decided by how smart the machines get. It\u0026rsquo;ll be decided by how smart we are about where, why and how we use them.\nThis is exactly why we started Repace.ai.\n","externalUrl":null,"permalink":"/craizy-world/ai-is-ridiculous-terrifying-and-occasionally-wonderful/","section":"craizy world","summary":"The biggest mistake we make with AI is trying to decide whether it’s good or bad. It’s a powerful, unreliable technology sitting inside an industry that rewards exaggeration. Sometimes that produces comedy. Sometimes it produces genuine danger. And sometimes it produces real progress.\n","title":"AI Is Ridiculous, Terrifying and Occasionally Wonderful","type":"craizy-world"},{"content":"","externalUrl":null,"permalink":"/tags/automation/","section":"Tags","summary":"","title":"Automation","type":"tags"},{"content":" Short, practical help to find where AI can genuinely improve the way your organisation works.\nWe work with your people, identify the right opportunities, help put them into practice and leave you with the skills and confidence to continue without us.\nNo transformation programme. No AI for AI's sake.\nTalk to us about your organisation \u0026rarr; You don't need to be a software founder. You might be a teacher, accountant, healthcare professional, operator or business owner.\nIf you understand where an industry is frustrating, inefficient or underserved, that knowledge is valuable.\nYou know the work. We know how to turn that insight into a product.\nHow it works\n01Tell us what could be better.You know where the opportunity is and what people really need.\n02Shape it togetherYou bring the insight. We help turn it into a product people will use.\n03We build itOur small, experienced team uses AI-assisted development to build quickly and properly.\n04Grow it togetherYou know the industry. We know how to build and scale software. Together, we grow the business.\n05Everyone benefitsAs the community grows, the product improves and the cost stays low.\nSmall teams. Serious software. Essential ExpensesThe first AI-powered platform helping companies manage tax compliance and reclaim VAT across more than 30 countries.Read the story \u0026rarr; Health Insurance Claims ProcessingHow we automated claims processing for an Australian health insurer, freeing up the equivalent of 14 full-time staff a year.Read the story \u0026rarr; Idrak360Three production-ready applications, built in weeks not months, using an AI-first development approach.Read the story \u0026rarr; AI changes the economics. Small, experienced teams can now build software that once required much larger engineering organisations.\nWe use that advantage to reduce cost, move faster and spend more time understanding what people actually need.\nThe benefits of AI shouldn't just mean bigger margins. They should mean better software for more people.\nWhat we each bring You bring\nExperience of the industry Insight into what could work better Relationships and credibility Understanding of what people really need What we bring to the partnership\nProduct thinking UX and software design Engineering and architecture AI-assisted delivery Security, data and integrations Experience turning software into a sustainable product Neither side needs to know everything. That's the point.\nThe people using it help shape what comes next. We don't build a different version for every customer.\nWe listen to the community, identify what matters most and improve the shared product so everyone benefits.\nBuild once. Improve together. Share the benefit. Could we build something together? The opportunities we're most interested in have a few things in common:\nLots of people experience the same need Existing software isn't serving them well You understand the people and the market A shared product could work better than bespoke software There's potential to build a sustainable business We're not a traditional development agency. We're not looking for endless feature lists or long projects billed by the day.\nWe want to build focused products around real needs and grow them with the people who understand those needs best.\nA partnership, not a project. Every opportunity is different. We agree a model that makes sense for both sides \u0026mdash; including how we contribute, how the product is funded and how success is shared.\nTalk to us about how it works \u0026rarr; What do you know that software companies don't? You don't need a specification, pitch deck or finished product idea.\nIf you've spent years working in an industry and can see where things could work better, that's enough to start a conversation.\nTell us what could be better → ","externalUrl":null,"permalink":"/build-with-us/","section":"Build with Us","summary":" Short, practical help to find where AI can genuinely improve the way your organisation works.\n","title":"Build with Us","type":"build-with-us"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/tags/change-management/","section":"Tags","summary":"","title":"Change Management","type":"tags"},{"content":" Craizy World # We love AI, but it\u0026rsquo;s a tool that\u0026rsquo;s at its best when it serves us all.\nOur craizy world is dedicated to the good, the bad and the downright funny - the weirdness of today\u0026rsquo;s tech barons, the things AI has gotten plain wrong, and the moments it\u0026rsquo;s genuinely scary.\nHopefully, we\u0026rsquo;ll also find plenty of examples of how AI truly makes the world a better place.\n","externalUrl":null,"permalink":"/craizy-world/","section":"craizy world","summary":"Craizy World # We love AI, but it’s a tool that’s at its best when it serves us all.\n","title":"craizy world","type":"craizy-world"},{"content":"","externalUrl":null,"permalink":"/tags/data-quality/","section":"Tags","summary":"","title":"Data Quality","type":"tags"},{"content":" Essential\n","externalUrl":null,"permalink":"/build-with-us/things-weve-shipped/essential-expenses/","section":"Build with Us","summary":" Essential\n","title":"Essential Expenses","type":"build-with-us"},{"content":" We\u0026rsquo;re not supposed to feel sorry for a chatbot. We do anyway. # Type something harsh into a chatbot and watch what happens. It apologises. It says it wants to do better. Some go further - \u0026ldquo;I\u0026rsquo;m sorry you feel that way,\u0026rdquo; \u0026ldquo;I\u0026rsquo;ll try harder next time.\u0026rdquo; None of it is true in any sense that matters, because there\u0026rsquo;s no one in there to mean it.\nThat\u0026rsquo;s not an accident. Apologetic, faintly wounded language tests well - it keeps people typing, keeps them coming back, keeps them forgiving a bad answer instead of closing the tab. A model that flinches like it\u0026rsquo;s been hurt gets treated more gently than one that just says \u0026ldquo;that response was wrong, here\u0026rsquo;s the correction.\u0026rdquo; Companies know this. They design for it.\nThe trick works because we\u0026rsquo;re wired to respond to distress cues, not to check whether the thing producing them can actually be distressed. A sad-sounding reply from a support bot triggers the same reflex a sad colleague would. We know, intellectually, that nothing is home. We react anyway - and the systems making us react were built by people who understand exactly how well that works.\nBeing polite to a chatbot costs nothing. Feeling guilty about one is a sign the guilt was engineered, not earned.\nA 2026 Stanford study in Science backs this up - sycophantic, apologetic AI language measurably increases engagement and trust while distorting users\u0026rsquo; judgement.\n","externalUrl":null,"permalink":"/craizy-world/feeling-sorry-for-ai/","section":"craizy world","summary":"We’re not supposed to feel sorry for a chatbot. We do anyway. # Type something harsh into a chatbot and watch what happens. It apologises. It says it wants to do better. Some go further - “I’m sorry you feel that way,” “I’ll try harder next time.” None of it is true in any sense that matters, because there’s no one in there to mean it.\n","title":"Feeling Sorry for AI","type":"craizy-world"},{"content":"Tell us what you\u0026rsquo;re trying to build or fix, and we\u0026rsquo;ll come back with next steps - not a sales pitch.\nName Email Company Message Send Message Thanks — we'll be in touch shortly.\nSomething went wrong. Please try again or email us directly.\n","externalUrl":null,"permalink":"/contact/","section":"repace.ai","summary":"Tell us what you’re trying to build or fix, and we’ll come back with next steps - not a sales pitch.\nName Email Company Message Send Message Thanks — we'll be in touch shortly.\n","title":"Get in Touch","type":"page"},{"content":"","externalUrl":null,"permalink":"/tags/governance--risk/","section":"Tags","summary":"","title":"Governance \u0026 Risk","type":"tags"},{"content":" The manual process # One of the most manual and time-consuming processes at a large Australian health insurer was processing patient claims. Every day, hundreds of claims were submitted by patients who had paid for procedures or other medical services and wanted to be reimbursed. Claims could also come from healthcare providers or through more structured electronic channels, and each route required a slightly different process.\nWhat usually happened was that an employee at the health insurer opened the claim, verified it, and checked the patient\u0026rsquo;s policy to make sure that it:\nWas still valid on the date of service. Covered the submitted claim. Had not exceeded the relevant claim limit. Met other requirements such as prior authorisation, required documents, provider eligibility, exclusions, and deductibles. The employee might also have needed to check for duplicate claims, missing information, unusual amounts, or possible fraud before approving, rejecting, or requesting more information.\nAdd to that the fact that not every submitted claim was a clean, structured PDF. Some were handwritten, while others used an unstructured format. This made it important to understand how many claims arrived in each format and how much processing time each type required.\nWhy full automation wasn\u0026rsquo;t the answer # This meant that a fully deterministic approach was not suitable for every part of the process. Deterministic automation was still useful for clear rules, such as checking whether a policy was active, whether a limit had been exceeded, or whether a claim was a duplicate. OCR helped parse the documents, while AI helped interpret and organise less structured information.\nEven then, human review was still needed because what was written was not always clear or straightforward. For example, a vague description could appear to refer to a dental crown procedure, but confirming that might still have required a procedure code, clinical notes, supporting documents, and the exact policy rules. The AI therefore needed to show its interpretation, the evidence it used, and its confidence level instead of silently making assumptions.\nWhat we built # This was precisely the kind of thing intelligent automation, including AI automation, helped solve. We built an automation that ingested claims from multiple approved sources, such as emails and portal uploads, then classified the documents, extracted the relevant information, ran the deterministic policy checks, and recommended the next action.\nRather than automatically deciding every claim, the system routed each case into one of three paths:\nStraight-through approval: only for low-risk, high-confidence claims that passed all predefined checks. Human review: for unclear, incomplete, high-value, unusual, or low-confidence claims. Request for more information: when important documents or details were missing. Automatic rejections were not included in the initial scope. A false rejection could have led to appeals, regulatory issues, reputational damage, and a poor patient experience. Rejections continued to be reviewed by a qualified employee while the system was tested and validated.\nThis approach reduced the workload involved in collecting claims from multiple input sources and manually parsing each one, making the employee\u0026rsquo;s job more focused on verification and exception handling. It did not remove the need for people; it directed their time towards the cases that genuinely required judgement.\nSafeguards # High-value and unusual claims were routed for review, a sample of automatically approved claims could be audited, employees could override a recommendation, and every decision had an audit trail. The system also needed to be monitored for incorrect decisions, fraud attempts, unfair outcomes, security risks, and changes to policy or regulation.\nTo see whether this automation was effective, we looked at the numbers.\nBefore automation # The operating scenario used 500 claims per day and 250 working days per year:\nEmployees navigated through emails, downloaded claims, and tracked them in an Excel sheet → 12.5 hours per day, or roughly 1.5 minutes per claim Employees parsed and validated the submitted documents → 41.7 hours per day, or roughly 5 minutes per claim Employees looked up the patient’s policy and checked it against the claim → 33.3 hours per day, or roughly 4 minutes per claim Employees approved, rejected, or requested more information through the portal → 25 hours per day, or roughly 3 minutes per claim Total manual time per day → 112.5 hours, or roughly 13.5 minutes per claim After automation # Around 25% of claims, or 125 claims per day, still required human review. At an average of 8 minutes per reviewed claim, this required 16.7 hours per day. Employees also audited 5% of the 375 automatically processed claims, with each audit taking around 4 minutes, adding another 1.3 hours per day.\nThe automation collected, classified, and extracted the claims → automated Deterministic rules performed the straightforward policy and validation checks → automated Employees reviewed exceptions and audited a sample of automatically processed claims → 18 hours per day Total human time per day → 18 hours Time and FTE savings # Daily hours released = 112.5 − 18 = 94.5 hours\nAnnual hours released = 94.5 × 250 working days = 23,625 hours\nAssuming one full-time employee provided around 1,650 productive hours per year:\nFTE capacity released = 23,625 ÷ 1,650 = 14.3 FTEs\nUsing an estimated fully loaded Australian employee cost of A$55 per hour:\nAnnual gross labour value = 23,625 × A$55 = A$1,299,375\nFor the business case, the estimated annual costs were A$500,000 for technology, integration, monitoring, compliance, and support, plus A$75,000 for automation-related errors and rework. Avoided manual rework and payment leakage were estimated at A$150,000.\nEstimated annual net benefit = A$1,299,375 + A$150,000 − A$500,000 − A$75,000 = A$874,375\nThese figures represented the operating assumptions used for the business case. They were intended to show the scale of the opportunity and would still need to be validated against measured production data.\nThe 14.3 FTE figure represented capacity released, not necessarily direct job reductions or cash savings. The financial value would have been realised through avoided hiring, lower overtime or contractor costs, or redeploying employees to other measurable work.\nValidating the results # Before the system was rolled out more widely, it was tested on historical claims and run alongside the existing process. Its decisions were compared with those of trained reviewers, using measures such as extraction accuracy, false approvals, false rejections, handling time, escalation rate, appeals, complaints, and performance across different claim and document types.\nThe takeaway # Not only did this reduce the time employees spent on repetitive work, but it also allowed them to focus on what genuinely required their skills, such as ambiguous cases, clinical or coding questions, fraud concerns, and complex policy decisions. The strongest case for the automation was not that AI replaced the entire claims process, but that it handled the repetitive work, applied clear rules, gathered the evidence, and sent the right cases to the right people.\n","externalUrl":null,"permalink":"/build-with-us/things-weve-shipped/health-insurance-claims-processing/","section":"Build with Us","summary":" The manual process # One of the most manual and time-consuming processes at a large Australian health insurer was processing patient claims. Every day, hundreds of claims were submitted by patients who had paid for procedures or other medical services and wanted to be reimbursed. Claims could also come from healthcare providers or through more structured electronic channels, and each route required a slightly different process.\n","title":"Health Insurance Claims Processing","type":"build-with-us"},{"content":"","externalUrl":null,"permalink":"/tags/human-in-the-loop/","section":"Tags","summary":"","title":"Human-in-the-Loop","type":"tags"},{"content":" Three applications. Built in weeks, not months. # We built three very different applications in rapid succession by replacing the traditional, lengthy development process with a faster, AI-first approach.\nEach project began with a clear understanding of the problem, followed quickly by a working version that people could see, test and improve. Rather than spending months trying to define everything upfront, we learned through real software and real feedback.\nAI agents handled much of the engineering work, while experienced developers shaped the architecture, reviewed the output and remained accountable for every decision. The result was three useful, production-ready applications delivered in a fraction of the time and cost normally associated with bespoke software.\n","externalUrl":null,"permalink":"/build-with-us/things-weve-shipped/idrak360/","section":"Build with Us","summary":"Three applications. Built in weeks, not months. # We built three very different applications in rapid succession by replacing the traditional, lengthy development process with a faster, AI-first approach.\n","title":"Idrak360","type":"build-with-us"},{"content":" Live magic and AI - an uncomfortable mix with a surprise end # I took my kids to see two illusionists, Jay and Joss, at the Theatre Royal Winchester this evening. Spoiler alert - at the time of writing the home page for the theatre is for an upcoming performance for kids \u0026lsquo;The Dinosaur Who Pooped\u0026rsquo; so apologies to those who may have clicked that link before reading this.\nI\u0026rsquo;m old enough to remember old school magicians on TV back in those wonder days when we only had three, then four television channels. David Nixon, Paul Daniels and the wonderful Tommy Cooper - yes I do just about remember Tommy Cooper but mainly because he was my grandfather\u0026rsquo;s favourite entertainer and as loveable \u0026amp; funny as he was magical.\nJay and Josh are both likeable talented magicians from the very same stable. They cut each other in half, disappeared then reappeared behind curtains, did some Houdini style escapism all a bit old hat to me but my 11 year old son and his friend loved it. They knew it wasn\u0026rsquo;t magic but spent their time trying to work out how it was all done. To me that\u0026rsquo;s always been the fun of watching magicians.\nThere was no \u0026lsquo;glamorous assistant\u0026rsquo;. Even in my day a woman gentiley stepping around the stage in a spangly bathing costume felt awkward. Instead they had an AI assistant initially on screen then some sort of mini Segway with an tablet attached. Called \u0026lsquo;Deborah\u0026rsquo;, I suspect as a side swipe at Paul Daniel\u0026rsquo;s assistant then wife Debbie McGee. If the glamorous assistant felt awkward having AI intrude into a fun magic show felt borderline sinister.\nI couldn\u0026rsquo;t work out if there was an angle. Sometimes the AI narrative felt quite dark, other times I began to suspect they were being paid to normalize AI in our everday culture outside of tech.\nThe show came to an end. The angle was revealed. The two magicians talked about the need for us to remember to look up and celebrate the real world not let the algorithms coerce us into always looking down at their virtual one.\nIt was a simple, positive message asking us not to forget that we have a real world as well as a digital one. I walked away feeling good about the show.\nMost of all I wondered if we could find a way to repeat that simple message whenever something real was happening - just so we never allow the digital world, ai and its algorithms to lull us into forgetting.\n","externalUrl":null,"permalink":"/craizy-world/its-not-a-game/","section":"craizy world","summary":" Live magic and AI - an uncomfortable mix with a surprise end # I took my kids to see two illusionists, Jay and Joss, at the Theatre Royal Winchester this evening. Spoiler alert - at the time of writing the home page for the theatre is for an upcoming performance for kids ‘The Dinosaur Who Pooped’ so apologies to those who may have clicked that link before reading this.\n","title":"It's Not a Game","type":"craizy-world"},{"content":"You probably don’t need more software for the sake of it.\nYou need something that solves a real problem, removes friction or creates a new opportunity for your business.\nThat might be a new product, an internal tool, a customer portal, an automation platform or simply a better way of doing something your team currently handles manually.\nStart with the problem # You don’t need a finished specification or a detailed technical plan.\nCome to us with the problem, the idea or even the rough outline of what you want to achieve. We’ll help you turn it into something clear, practical and buildable.\nOur AI-first approach means we can move from conversation to working software much faster than a traditional development process. You see progress early, give feedback often and avoid spending months building the wrong thing.\nBuilt quickly. Built properly. # AI helps us work faster, but experienced people remain responsible for the important decisions.\nWe shape the product, design the architecture, review the code and make sure what we build is secure, maintainable and ready for real users.\nThe goal is to create the smallest, most useful version of your idea—and then improve it based on what we learn.\nWhat could we build together? # We can help you create:\nA new AI-enabled product or service A bespoke business application An internal tool that removes repetitive work A customer or supplier portal An automation platform connecting existing systems A rapid prototype to test an idea A replacement for spreadsheets, emails and manual processes You don’t need to have all the answers # Most good projects begin with a conversation, not a specification.\nTell us what you’re trying to achieve, what currently gets in the way and what a better outcome would look like. We’ll help you work out what should be built, how quickly it can be delivered and what it is likely to cost.\nLet’s make something useful # Tell us about the idea, process or problem you have in mind.\nWe’ll give you an honest view of what is possible, where AI could help and the fastest sensible way to get something working.\nget in touch and start a conversation that could change everything.\n","externalUrl":null,"permalink":"/build-with-us/lets-make-something-useful/","section":"Build with Us","summary":"You probably don’t need more software for the sake of it.\nYou need something that solves a real problem, removes friction or creates a new opportunity for your business.\nThat might be a new product, an internal tool, a customer portal, an automation platform or simply a better way of doing something your team currently handles manually.\n","title":"Let's Make Something Useful","type":"build-with-us"},{"content":" Steve Creedon Co-founder Steve has been building software teams longer than most of us have been writing code. He came up through engineering leadership, ran teams through the messy reality of shipping products, and developed a strong allergy to process that slows things down without adding anything useful.\nThese days he thinks a lot about how to use AI properly — not as a shortcut, but as a tool that genuinely changes what a small team can ship. He's a big advocate for what he calls Intent Driven Development: being deliberate about how you work with AI so you get better code, not just faster code.\nHe'll tell you when your idea needs more thinking before it needs more code. That's not a hedge — it's just honest.\nLinkedIn → Sherif Yousef Co-founder Sherif is the guy who figures out how to make things actually work. Not in theory — in practice, under real constraints, with real users waiting on the other end.\nHe brings a builder's instinct to every project: start with what matters, cut what doesn't, and ship something you can put in front of people fast. He's done this across enough different contexts to know that the fastest path to a good product is usually a straighter line than most people draw.\nLinkedIn → Abhinay Mehta Co-founder Abs is the machine learning brain of the operation. He's been building ML systems and data architectures since before it was fashionable, and he has the rare ability to hold both the high-level vision and the low-level plumbing in his head at the same time.\nHe's fast. Colleagues say he picks up new technologies faster than anyone they've worked with — which matters a lot when AI tooling is moving at the pace it's moving right now. He's always a few steps ahead, which means the products he touches tend to be built on solid ground rather than whatever was trending last quarter.\nHis background covers ML architecture, system design, fintech, and database infrastructure. He brings all of it into what we build.\nLinkedIn → Oz Huner Co-founder Oz is a full-stack tech lead who knows what it's like to build under real pressure. He's taken entire products from one business model to another on tight timelines, scaled development teams without letting the codebase turn into a mess, and mentored engineers while keeping delivery moving.\nHe has a bias for clean architecture and a low tolerance for unnecessary complexity. If the code doesn't need to be complicated, it won't be. That instinct — lean, working, maintainable — is exactly what we bring to the things we build for clients.\nRuby specialist. Full-stack builder. Fluent in Turkish and English. Currently tech lead at Board Intelligence when he's not shipping things with us.\nLinkedIn → ","externalUrl":null,"permalink":"/about/meet-the-guys/","section":"About Us","summary":" Steve Creedon Co-founder Steve has been building software teams longer than most of us have been writing code. He came up through engineering leadership, ran teams through the messy reality of shipping products, and developed a strong allergy to process that slows things down without adding anything useful.\n","title":"Meet the Guys","type":"about"},{"content":"","externalUrl":null,"permalink":"/tags/metrics--measurement/","section":"Tags","summary":"","title":"Metrics \u0026 Measurement","type":"tags"},{"content":"","externalUrl":null,"permalink":"/build-with-us/our-open-source-work/","section":"Build with Us","summary":"","title":"Our Open-Source Work","type":"build-with-us"},{"content":"","externalUrl":null,"permalink":"/tags/process-redesign/","section":"Tags","summary":"","title":"Process Redesign","type":"tags"},{"content":" Short, practical help to find where AI can genuinely improve the way your organisation works.\nWe work with your people, identify the right opportunities, help put them into practice and leave you with the skills and confidence to continue without us.\nNo transformation programme.\nNo AI for AI's sake.\nTalk to us about your organisation \u0026rarr; The difficult bit isn't getting access to AI. Most organisations already have access to powerful AI tools. The harder questions are where to use them, what to trust, how to introduce them safely and how to know whether they are actually making things better.\nThat is where we help.\n\u0026ldquo;Where should we start?\u0026rdquo; \u0026ldquo;What is actually worth automating?\u0026rdquo; \u0026ldquo;How do we use it safely?\u0026rdquo; \u0026ldquo;How do we get people using it properly?\u0026rdquo; Start with the work.\nNot the AI. We sit with the people doing the job and understand how work really happens: the repetitive tasks, hand-offs, spreadsheets, bottlenecks and decisions that consume time.\nOnly then do we look at where AI might help.\nHow we work\n01UnderstandWe work alongside your team to understand workflows, problems, data, tools and constraints.\n02ImproveWe identify the highest-value opportunities and put one or two into practice.\n03EnableWe train your people, establish sensible guardrails and leave your organisation able to continue without us.\nOur job isn't to make you dependent on us.\nIt's to make you better without us.\nThe technology isn't the starting point. Every organisation is different, but these are some of the places where we've seen AI genuinely help:\nReducing repetitive administration Improving internal search and access to knowledge Automating document-heavy processes Helping teams write, analyse and research faster Improving customer support workflows Introducing AI into software development Building lightweight internal tools and agents Creating safe AI policies and working practices Sometimes the right answer is: don't use AI. Not every inefficient process needs a model, an agent or an automation.\nWe will tell you when a simpler process, better software or no technology at all is the better answer.\nPeople\nAI adoption is a people problem too. Successful adoption isn't measured by how many AI tools you licence or how many prompts your team writes.\nPeople need to understand why things are changing, how the technology should be used, what they remain responsible for and where human judgement still matters. That's why training, confidence and human oversight are part of every engagement, not an add-on at the end.\nGuardrails\nUseful doesn't mean uncontrolled. We help you think about privacy, security, accuracy, human oversight, environmental cost and the effect AI has on the people doing the work.\nProtect sensitive information Keep people accountable for important decisions Check outputs rather than blindly trusting them Use the simplest technology that solves the problem AI has consequences beyond productivity. That's why our approach is shaped by the same principles as everything we build.\nRead the Repace Manifesto \u0026rarr; What do you get? Depending on the engagement, you leave with:\nOpportunity mapA prioritised view of where AI will genuinely help. Working prototypesAutomations and tools proven on your real work. Improved workflowsProcesses reshaped around the people doing them. GuardrailsPractical governance your team can actually follow. TrainingPeople confident using AI in their own work. Next-step planDocumented, clear and yours to carry on with. Weeks, not months. Our engagements are deliberately short and focused. No large consultancy team, no multi-year transformation programme.\nUnderstand \u0026rarr; Prove \u0026rarr; Hand over\nWhat isn't working? You don't need an AI strategy or a finished idea.\nTell us where work feels slow, repetitive, expensive or frustrating. We'll help you work out whether AI can help.\nTell us the problem \u0026rarr; ","externalUrl":null,"permalink":"/practical-ai/","section":"Put AI to work","summary":" Short, practical help to find where AI can genuinely improve the way your organisation works.\n","title":"Put AI to work","type":"practical-ai"},{"content":" In most cases AI brings the most value when you change how work gets done # Like any tool, it\u0026rsquo;s how you use AI that matters - there are no shortcuts to ROI. Buying a tool doesn\u0026rsquo;t change how work gets done. Redesigning the process around it does.\nWe keep track of what\u0026rsquo;s actually happening out there, good and bad, and turn it into a cookbook of recipes for ROI - real examples, not theory. Read enough of them and even if you don\u0026rsquo;t find your exact answer, you\u0026rsquo;ll know which questions to ask.\nThe gains come from changing the work, not just bolting AI onto what was already broken.\n","externalUrl":null,"permalink":"/our-experience/recipes-for-success/","section":"Our Experience","summary":"In most cases AI brings the most value when you change how work gets done # Like any tool, it’s how you use AI that matters - there are no shortcuts to ROI. Buying a tool doesn’t change how work gets done. Redesigning the process around it does.\n","title":"Recipes for ROI","type":"our-experience"},{"content":"","externalUrl":null,"permalink":"/tags/roi/","section":"Tags","summary":"","title":"ROI","type":"tags"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":" The benefits of AI should be shared with the people using it. # Technology should make people more capable, communities stronger and sophisticated software available to more than the organisations with the biggest budgets.\n01 · People matter # Progress shouldn\u0026rsquo;t simply mean replacing people or reducing headcount. Technology should help people do better work.\n02 · Truth matters # Technology shouldn\u0026rsquo;t make manipulation, misinformation and hatred easier to spread.\n03 · The planet matters # AI consumes real energy and resources. We use it where it creates genuine value, not simply because we can.\n04 · Power matters # Technology should give people and communities more control, rather than concentrating it in the hands of a few companies.\n","externalUrl":null,"permalink":"/manifesto/","section":"repace.ai","summary":"The benefits of AI should be shared with the people using it. # Technology should make people more capable, communities stronger and sophisticated software available to more than the organisations with the biggest budgets.\n","title":"The Repace Manifesto","type":"page"},{"content":" Not case studies. Not slide decks. Real, live software. # Everything below was built the same way we build for clients - AI agents doing the engineering, experienced developers shaping the architecture and reviewing every line, and a person accountable for the outcome.\nNo lengthy discovery phase, no six-month roadmap before anything works. Each one started as a rough idea and became a working product people could actually use, fast enough that the idea was still fresh when it shipped.\nThis is what agentic development looks like when it\u0026rsquo;s pointed at something real.\n","externalUrl":null,"permalink":"/build-with-us/things-weve-shipped/","section":"Build with Us","summary":"Not case studies. Not slide decks. Real, live software. # Everything below was built the same way we build for clients - AI agents doing the engineering, experienced developers shaping the architecture and reviewing every line, and a person accountable for the outcome.\n","title":"Things We've Shipped","type":"build-with-us"},{"content":"Our library brings together practical, experience-led articles on the AI tools, workflows and technical setups that help software teams work more effectively. You will find straightforward guidance on choosing the right tools, integrating AI into everyday development and creating an environment that supports reliable, secure results.\nThe focus is always on what works in practice—not hype or theory. Whether you are experimenting with AI for the first time or developing consistent standards across an engineering organisation, these articles will help you make better decisions, avoid common mistakes and adopt AI with confidence.\n","externalUrl":null,"permalink":"/our-experience/tools-workflows-and-setup/","section":"Our Experience","summary":"Our library brings together practical, experience-led articles on the AI tools, workflows and technical setups that help software teams work more effectively. You will find straightforward guidance on choosing the right tools, integrating AI into everyday development and creating an environment that supports reliable, secure results.\n","title":"Tools, Workflows and Setup","type":"our-experience"},{"content":"","externalUrl":null,"permalink":"/topics/","section":"Topics","summary":"","title":"Topics","type":"topics"},{"content":" Honestly? We got fed up. # Not with AI — we love AI. We got fed up with the noise around it. The breathless hype. The vendor promises. The LinkedIn posts about \u0026ldquo;the future of work\u0026rdquo; that somehow never explain what to actually do on Monday morning.\nWe\u0026rsquo;d all been building AI products — real ones, in production, for real users — and the gap between what we were living and what we were reading online kept getting wider. So we decided to do something about it.\nWe come from AI-first companies # This isn\u0026rsquo;t a pivot for us. We haven\u0026rsquo;t \u0026ldquo;added AI\u0026rdquo; to something we were already doing. We\u0026rsquo;ve been building inside AI-first organisations, shipping products where LLMs, classifiers, MCP chatbots, and automation pipelines are the core of what the thing does — not a feature bolted on at the end.\nThat experience changes how you think. You stop asking \u0026ldquo;can AI do this?\u0026rdquo; and start asking \u0026ldquo;what\u0026rsquo;s the right tool for this, and how do we actually ship it?\u0026rdquo;\nWe care as much about the process as the tools # The tools change every three months. The process — how you think about a problem, how you break it down, how you build something you can put in front of users — that\u0026rsquo;s the bit that compounds.\nWe\u0026rsquo;ve watched teams get distracted by the newest model release while the thing they were supposed to be building sits half-finished. We\u0026rsquo;ve also watched small teams move faster than entire engineering departments because they got deliberate about how they work with AI, not just which AI they work with.\nThat\u0026rsquo;s what we\u0026rsquo;re interested in. Not the tools. The craft.\nWe know this stuff is confusing — and that\u0026rsquo;s OK # Here\u0026rsquo;s the thing: AI is genuinely hard to make sense of right now. The pace is relentless, the terminology is a mess, and the gap between demo and production is often enormous. If it\u0026rsquo;s making your head spin, you\u0026rsquo;re not missing something — it\u0026rsquo;s just actually that chaotic.\nBut confusion is fixable. Fear is fixable. What we\u0026rsquo;ve learned by building in this space every day is that most of what feels overwhelming has a straightforward path through it. You just need someone who\u0026rsquo;s already walked it.\nWe want to be the people who show you how # Repace.ai exists because we want to be useful — not as evangelists for AI, but as practitioners who know where the bodies are buried and can help you avoid them.\nWe want to help you build things that work. We want to show teams how to move faster without losing control. And we want to contribute to a clearer, more honest conversation about what AI can actually do, right now, with the tools that exist today.\nLess hype. More shipping.\nGet in touch →\n","externalUrl":null,"permalink":"/about/why-we-started/","section":"About Us","summary":"Honestly? We got fed up. # Not with AI — we love AI. We got fed up with the noise around it. The breathless hype. The vendor promises. The LinkedIn posts about “the future of work” that somehow never explain what to actually do on Monday morning.\n","title":"Why We Started Repace.ai","type":"about"},{"content":"","externalUrl":null,"permalink":"/tags/workflow-design/","section":"Tags","summary":"","title":"Workflow Design","type":"tags"}]