[{"data":1,"prerenderedAt":1829},["ShallowReactive",2],{"all-posts":3},[4,273,440,616,853,1099,1334,1614],{"id":5,"title":6,"body":7,"datePublished":260,"description":261,"extension":262,"meta":263,"navigation":264,"path":265,"seo":266,"stem":267,"tags":268,"updatedAt":260,"__hash__":272},"blog\u002Fblog\u002Fai-llm-integration-smes-cambridge.md","LLM integration for SMEs: a pragmatic guide (without the hype)",{"type":8,"value":9,"toc":243},"minimark",[10,20,25,33,38,41,45,48,52,55,59,67,71,74,80,86,99,103,106,112,122,133,137,140,146,155,161,167,171,174,177,181,184,218,221,225],[11,12,13,14,19],"p",{},"Most of what small businesses are told about AI falls into two camps: breathless promises that it will transform everything, or vague warnings that it's all hype. Neither helps you decide whether to spend money on it. We build ",[15,16,18],"a",{"href":17},"\u002Fservices\u002Fai-ml","AI & LLM integration"," into real systems for real businesses, and the honest answer is narrower and more useful than either camp admits: LLMs are very good at a specific set of jobs, mediocre at others, and genuinely dangerous in a few. This guide covers which is which, how integration actually works under the bonnet, what UK GDPR requires of you, and what it realistically costs.",[21,22,24],"h2",{"id":23},"where-llms-genuinely-pay-off","Where LLMs genuinely pay off",[11,26,27,28,32],{},"The pattern behind every good LLM use case is the same: ",[29,30,31],"strong",{},"high-volume, language-heavy work where a human reviews or could review the output",". If a task fits that shape, the economics are usually compelling. Four examples come up again and again with SMEs.",[34,35,37],"h3",{"id":36},"document-processing-and-extraction","Document processing and extraction",[11,39,40],{},"If your team spends hours retyping information from PDFs, invoices, purchase orders, CVs, tenancy agreements or delivery notes into a spreadsheet or a CRM, this is the single most reliable win available. An LLM can read an unstructured document and return clean, structured data — supplier name, line items, totals, dates — ready to drop into your existing systems. It copes with the messy variety that breaks traditional template-based OCR: every supplier formats their invoice differently, and that's exactly the variability LLMs handle well.",[34,42,44],{"id":43},"enquiry-triage","Enquiry triage",[11,46,47],{},"Imagine a letting agency receiving two hundred emails a day: maintenance requests, viewing enquiries, rent queries, complaints. An LLM can classify each one, extract the key details (property, urgency, tenant name), and route it to the right person or queue — before anyone opens their inbox. Nobody is replaced; the person who used to spend the first ninety minutes of each day sorting email now starts on actual work. Triage is forgiving of imperfection, which makes it a good early project: a misrouted email gets re-routed by a human, and nothing bad happens.",[34,49,51],{"id":50},"internal-search-over-company-knowledge","Internal search over company knowledge",[11,53,54],{},"Most companies over about ten people have the same problem: the answer exists, but it's in a PDF on someone's drive, a wiki page nobody updates, or the head of one long-serving employee. LLMs paired with retrieval (more on that below) let staff ask questions in plain English — \"what's our returns policy for trade customers?\" — and get an answer grounded in your actual documents, with a citation back to the source. The citation matters: it turns \"trust the robot\" into \"here's the paragraph, check it yourself\".",[34,56,58],{"id":57},"drafting-assistance","Drafting assistance",[11,60,61,62,66],{},"First drafts of quotes, job adverts, customer replies, product descriptions and report sections. The key word is ",[63,64,65],"em",{},"drafts",". A person reads, corrects and sends. Used this way, an LLM doesn't need to be right every time — it needs to be right often enough that editing its output is faster than writing from scratch, and for routine business writing it comfortably clears that bar.",[21,68,70],{"id":69},"where-they-dont-pay-off","Where they don't pay off",[11,72,73],{},"This list matters more than the previous one, because the expensive failures all start with someone ignoring it.",[11,75,76,79],{},[29,77,78],{},"Anything that needs guaranteed correctness without review."," LLMs are probabilistic. They will occasionally state something false with complete confidence, and no amount of prompt engineering eliminates this entirely. Calculating payroll, generating legal documents that go out unreviewed, quoting binding prices to customers automatically — these are not LLM jobs, full stop. The rule is simple: if a wrong output costs you real money or legal exposure and nobody checks it before it takes effect, don't put an LLM there.",[11,81,82,85],{},[29,83,84],{},"Replacing judgment."," An LLM can summarise the five candidate CVs; it should not decide who gets the interview. It can draft the response to a complaint; it shouldn't decide whether to refund. Decisions involving fairness, money, employment or anything a regulator cares about should stay with people — and under UK GDPR, individuals have rights around solely automated decisions with significant effects, so this is a legal point as well as a practical one.",[11,87,88,91,92,94,95,98],{},[29,89,90],{},"Tasks ordinary software already does well."," If the job is \"add up the numbers in column C\" or \"send a reminder three days before the deadline\", you want boring deterministic code, not a language model. We see budgets wasted bolting an LLM onto problems a database query solves. Good ",[15,93,18],{"href":17}," work is partly knowing when ",[63,96,97],{},"not"," to use the model.",[21,100,102],{"id":101},"how-integration-actually-works","How integration actually works",[11,104,105],{},"Demystifying the mechanics helps you scope projects sensibly, so here is the short version.",[11,107,108,111],{},[29,109,110],{},"You don't train a model."," For almost every SME use case, you call an existing model through an API — a few lines of code send your text to the provider, the model responds, your software acts on the response. Training your own model costs hundreds of thousands of pounds and is almost never the right answer. The real engineering work is everything around the API call: getting your data in, validating what comes out, handling failures, and wiring it into the systems you already run.",[11,113,114,117,118,121],{},[29,115,116],{},"RAG, in plain English."," Models know nothing about your business out of the box. Retrieval-augmented generation (RAG) fixes that: when someone asks a question, your system first ",[63,119,120],{},"searches your own documents"," for the relevant passages, then hands those passages to the model along with the question and says, in effect, \"answer using only this\". The model isn't remembering your data — it's reading the excerpts you just showed it, which is why answers can carry citations and why your documents never need to be used to train anything.",[11,123,124,127,128,132],{},[29,125,126],{},"Structured output."," Modern APIs can be forced to reply in a fixed format — a JSON object with exactly the fields you specified, not freeform prose. This is the unglamorous feature that makes LLMs usable in real systems: when the model must return ",[129,130,131],"code",{},"{\"invoice_number\": ..., \"total\": ..., \"due_date\": ...}",", your existing software can consume the result like any other data source, and anything malformed gets rejected automatically rather than silently corrupting your records.",[21,134,136],{"id":135},"data-privacy-and-uk-gdpr","Data privacy and UK GDPR",[11,138,139],{},"This is the area where SMEs are most often either paralysed or careless. The sensible middle ground:",[11,141,142,145],{},[29,143,144],{},"Know what leaves your building."," When you call an LLM API, the text you send is processed on the provider's servers. So the first question for any project is: what data is in that text? Customer names? Financial details? Health information? Map it before you build anything — this is the core of a data protection impact assessment, and for anything touching personal data you should do one.",[11,147,148,151,152,154],{},[29,149,150],{},"Provider terms vary, so read them."," The major providers' business and API tiers generally commit ",[63,153,97],{}," to train on your data and offer zero- or limited-retention options, which is materially different from someone pasting customer records into a free consumer chatbot. The provider becomes a data processor; you need a data processing agreement in place, exactly as you would with any other processor, and your privacy notice should reflect the processing.",[11,156,157,160],{},[29,158,159],{},"UK and EU hosting exists."," The big cloud platforms now serve frontier models from UK and EU regions, so prompts can be processed without leaving the jurisdiction. If your clients, sector or risk appetite demand it, this is a configuration choice, not an exotic requirement. For the strictest cases, smaller open-weight models can run on your own infrastructure — at a real cost in capability and maintenance, so treat self-hosting as a last resort, not a default.",[11,162,163,166],{},[29,164,165],{},"Redact before you send."," Often the model doesn't need the personal data at all. A triage system can classify an email with names and phone numbers stripped out and substituted with placeholders; your own system reattaches the real details afterwards. Pseudonymisation like this shrinks your GDPR exposure and is usually a modest amount of engineering.",[21,168,170],{"id":169},"what-it-actually-costs","What it actually costs",[11,172,173],{},"The pricing model surprises most business owners, in a good direction. API-based LLMs are metered per unit of text. At current prices, extracting structured data from a typical one-page document costs a fraction of a penny to a few pence, depending on the model. Classifying an email costs less. A business processing 2,000 documents a month might spend less on model usage than on its coffee — these are not enterprise-licence numbers.",[11,175,176],{},"The real cost is the engineering: connecting the model to your inbox or document store, validating outputs, building the review step, integrating with your CRM or accounts package, and testing against your actual messy data rather than tidy demos. That's a development project measured in weeks, not a seven-figure transformation programme. The caveat worth stating plainly: a flat per-seat \"AI platform\" subscription can easily cost more per year than a bespoke integration costs to build once — and the bespoke version does your workflow, not a generic one.",[21,178,180],{"id":179},"how-to-pilot-without-betting-the-business","How to pilot without betting the business",[11,182,183],{},"Don't start with a strategy. Start with one workflow.",[185,186,187,194,200,206,212],"ol",{},[188,189,190,193],"li",{},[29,191,192],{},"Pick something annoying, frequent and low-stakes."," Invoice data entry and email triage are good. Anything customer-facing or compliance-critical is not, yet.",[188,195,196,199],{},[29,197,198],{},"Measure the current state first."," Hours per week, error rate, backlog. Without a baseline you'll never know whether the pilot worked.",[188,201,202,205],{},[29,203,204],{},"Keep a human in the loop."," The model proposes, a person approves. Confidence to remove the review step is earned with data, not assumed on day one.",[188,207,208,211],{},[29,209,210],{},"Run on real historical data before going live."," Take last month's two hundred invoices and check the extraction against what was actually entered. Disagreements tell you exactly where it's safe to automate.",[188,213,214,217],{},[29,215,216],{},"Set a kill criterion."," Decide up front what accuracy or time saving justifies continuing. If it isn't met in four to six weeks, stop — a cheap, fast \"no\" is a perfectly good pilot outcome.",[11,219,220],{},"A pilot like this is typically a few weeks of focused development. It produces either a working tool or a clear, evidenced reason to wait — both of which beat a year of wondering.",[21,222,224],{"id":223},"talk-to-us","Talk to us",[11,226,227,228,232,233,237,238,242],{},"We're a bespoke ",[15,229,231],{"href":230},"\u002Fsoftware-development-cambridge","software development company in Cambridge",", and this kind of work suits how we build: total immersion in one client problem at a time, and the pattern recognition to spot which of your workflows will actually benefit — and which won't. If you're weighing up an LLM project and want a straight answer about whether it stacks up, email us at ",[15,234,236],{"href":235},"mailto:hello@overclockminds.co.uk","hello@overclockminds.co.uk"," or use the ",[15,239,241],{"href":240},"\u002Fcontact","contact page",". A short conversation costs nothing, and if the honest answer is \"don't do this yet\", that's what we'll tell you.",{"title":244,"searchDepth":245,"depth":245,"links":246},"",2,[247,254,255,256,257,258,259],{"id":23,"depth":245,"text":24,"children":248},[249,251,252,253],{"id":36,"depth":250,"text":37},3,{"id":43,"depth":250,"text":44},{"id":50,"depth":250,"text":51},{"id":57,"depth":250,"text":58},{"id":69,"depth":245,"text":70},{"id":101,"depth":245,"text":102},{"id":135,"depth":245,"text":136},{"id":169,"depth":245,"text":170},{"id":179,"depth":245,"text":180},{"id":223,"depth":245,"text":224},"2026-06-11","Where AI integration genuinely pays off for small businesses, where it doesn't, what it costs, and how to pilot safely under UK GDPR.","md",{},true,"\u002Fblog\u002Fai-llm-integration-smes-cambridge",{"title":6,"description":261},"blog\u002Fai-llm-integration-smes-cambridge",[269,270,271],"ai","llm","smes","yQEjX-ne5sLYSLwdSwEyYLPmFxCUyKUaRbDJuWVZ0zI",{"id":274,"title":275,"body":276,"datePublished":260,"description":430,"extension":262,"meta":431,"navigation":264,"path":432,"seo":433,"stem":434,"tags":435,"updatedAt":260,"__hash__":439},"blog\u002Fblog\u002Faudhd-founded-software-studio.md","Why an AuDHD-founded studio ships better software",{"type":8,"value":277,"toc":416},[278,281,285,288,291,294,298,302,305,308,311,315,318,321,325,328,331,335,338,341,345,348,354,360,366,370,373,376,380,383,387,390,402,406],[11,279,280],{},"Overclock Minds is a bespoke software studio based near Cambridge, founded by someone with AuDHD — autism and ADHD together. We put that on the front page rather than burying it in an FAQ, because it shapes how we work in ways that directly affect what clients get. This post is the explanation: what AuDHD actually is, which cognitive traits show up in our engineering, what they cost us, and what you experience as a result. It is not an inspiration story. It's an honest account of how one neurodivergent software company operates.",[21,282,284],{"id":283},"what-audhd-actually-means","What AuDHD actually means",[11,286,287],{},"AuDHD is the informal term for being both autistic and having ADHD. They're distinct diagnoses that co-occur frequently, and the combination is its own thing rather than two conditions stacked neatly on top of each other.",[11,289,290],{},"Briefly and factually: autism affects how a person processes information — detail-first perception, a strong drive towards precision and internal consistency, deep and sustained interests, and a preference for explicit, literal communication. ADHD affects attention regulation and executive function. It's poorly named; the problem isn't a shortage of attention but difficulty steering it. Attention either locks onto something completely or slides off it entirely, with not much in between.",[11,292,293],{},"Put together, you get a brain that is unusually good at some things and reliably bad at others. Neither condition is a superpower, and we're sceptical of companies that market them that way. They are differences in cognition with genuine costs. But for the specific job of designing and building software, several of the traits line up remarkably well with what the work actually demands.",[21,295,297],{"id":296},"the-traits-that-show-up-in-the-work","The traits that show up in the work",[34,299,301],{"id":300},"hyperfocus-total-immersion-until-its-solved","Hyperfocus: total immersion until it's solved",[11,303,304],{},"ADHD attention is interest-driven, and a hard technical problem — an undocumented legacy system, a flaky hardware integration, an LLM pipeline that hallucinates under one specific input shape — is reliably interesting. When attention locks on, it locks on completely. Hyperfocus means living inside a client's problem domain: reading the source of dependencies rather than just their docs, reading the protocol spec rather than someone's blog summary of it, building a mental model of the system that's accurate rather than approximate.",[11,306,307],{},"The practical consequence is that we come up to speed on a domain quickly and we don't half-understand it. When we modernise a legacy codebase, we read the original code properly and work out what it actually does, rather than guessing intent from the edges and hoping.",[11,309,310],{},"The caveat: hyperfocus is not infinite and not always steerable on command. We manage it deliberately, which we'll cover below.",[34,312,314],{"id":313},"pattern-recognition-spotting-the-inconsistency-early","Pattern recognition: spotting the inconsistency early",[11,316,317],{},"Autistic cognition tends to be bottom-up. Details register first, and inconsistencies that most people read straight past produce a kind of cognitive friction that demands resolution. In software, that looks like noticing that two API endpoints handle null differently before it becomes a production incident, or that a spec describes three possible states while the database schema only allows two.",[11,319,320],{},"A clearly hypothetical example: imagine a booking system spec that says \"users can cancel up to 24 hours before their slot\". A detail-first reading immediately generates questions. Twenty-four hours in whose timezone? What happens at exactly 24 hours? What if the booking was made 23 hours before the slot, so the cancellation window never existed? None of that is pedantry — each unanswered question is a future support ticket, and the cheapest time to find a structural flaw is before anyone has built on top of it.",[34,322,324],{"id":323},"systems-thinking-holding-the-whole-stack-in-mind","Systems thinking: holding the whole stack in mind",[11,326,327],{},"Software mostly fails at boundaries — between frontend and API, between firmware and cloud, between the deploy pipeline and the production config nobody remembers changing. We're at our best when we can see the whole system at once, and we find it genuinely uncomfortable to work on one layer while treating the others as someone else's magic.",[11,329,330],{},"That's part of why our services deliberately span web applications, mobile apps, AI and LLM integration, embedded and hardware work, and cloud and DevOps. Not because we collect specialisms for the brochure, but because the failures that matter live in the joins. If a sensor reading arrives wrong, the cause might be firmware, the network, a queue configuration, or a rounding bug in the frontend — and it helps enormously to have one head that can hold all four hypotheses at once.",[34,332,334],{"id":333},"directness-estimates-you-can-plan-around","Directness: estimates you can plan around",[11,336,337],{},"Autistic communication runs literal and direct. In a sales meeting that's supposedly a weakness. In an engineering relationship it's most of what matters. We'll tell you when an estimate is a guess and what would firm it up. We'll tell you when a feature is cheaper to buy than to build, even when building it would earn us more. We'll say no to scope we think is a mistake, and explain why in writing.",[11,339,340],{},"What you won't get is \"it'll be ready soon\". You get a date with stated confidence, or an honest \"we don't know yet — here's the experiment that will tell us\".",[21,342,344],{"id":343},"how-we-structure-work-around-these-traits","How we structure work around these traits",[11,346,347],{},"None of the following came from a management book. We work this way because we fail when we don't.",[11,349,350,353],{},[29,351,352],{},"Deep work blocks."," Engineering happens in long, protected, uninterrupted stretches; meetings and admin are batched around them. Always-on instant messaging is genuinely destructive for how we work, so we don't pretend to offer it. We offer agreed response windows instead — and we hit them, because they're written down and we take written commitments literally.",[11,355,356,359],{},[29,357,358],{},"Written-first communication."," Decisions, scope, trade-offs, and estimates go in documents, not in the fog of a call. Writing is how we think most clearly, and it gives clients something they can re-read, question line by line, and forward to colleagues. Meetings still happen; they're just for discussion, with the conclusions captured afterwards in text.",[11,361,362,365],{},[29,363,364],{},"Prototypes over slide decks."," Given a week, we'd rather build a rough working slice of the real thing than a polished deck about a hypothetical one. Working software answers questions that slides can't — including the questions nobody knew to ask. It also plays to our strengths: building is where the hyperfocus goes anyway.",[21,367,369],{"id":368},"the-honest-costs","The honest costs",[11,371,372],{},"Context-switching is expensive for us — noticeably more expensive than for a typical engineer. Dropping out of deep focus on one system and reloading another project's full context can burn an hour or more of genuinely productive time. So we don't run twenty accounts at once. We take on a small number of clients and go deep on each. If you want an agency that can rotate fifteen people through your project at short notice, that isn't us. If you want the same brains fully loaded with your problem from kick-off to handover, it is.",[11,374,375],{},"Other costs, stated plainly: vague, unstructured early conversations are hard for us, so expect a lot of clarifying questions up front — most clients end up valuing this, but it can feel intense. Novelty-seeking means we have to actively guard against over-engineering, which is one reason we insist on written scope. And energy management is real: we don't sell heroic overnight turnarounds as a standard service, because we won't promise a pace we can't sustain across a whole project.",[21,377,379],{"id":378},"this-is-how-we-work-not-how-all-neurodivergent-people-work","This is how we work — not how all neurodivergent people work",[11,381,382],{},"A necessary caveat, and we mean it. Autism and ADHD present differently in every individual. Plenty of neurodivergent engineers have strengths nothing like ours; some share the strengths without the costs, or the costs without the strengths. We're describing one studio's cognition as honestly as we can, not making claims about a population — and we'd be doing other neurodivergent people a disservice if a client read this and treated it as a template. Judge any company, neurodivergent-founded or otherwise, on its actual work.",[21,384,386],{"id":385},"what-clients-actually-experience","What clients actually experience",[11,388,389],{},"Strip away the neuroscience and here's the observable behaviour: hard questions early, while changing the spec is still cheap. A working prototype sooner than you expected. Decisions and estimates in writing, with confidence levels attached. A \"no\" when no is the right answer. And, because we keep the client count low, sustained senior attention on your project rather than fractional slices of many people.",[11,391,392,393,397,398,401],{},"The label explains the why. The behaviour is what you're actually buying. There's more about the studio and how engagements run on our ",[15,394,396],{"href":395},"\u002Fabout","about"," page, and if you're local and looking for ",[15,399,400],{"href":230},"software development in Cambridge"," specifically, we work with labs, startups, and established firms around the city — face to face when that's useful.",[21,403,405],{"id":404},"if-this-sounds-like-a-fit","If this sounds like a fit",[11,407,408,409,411,412,415],{},"No pitch, just an open door. If you've got a project where depth matters more than headcount, email ",[15,410,236],{"href":235}," or use our ",[15,413,414],{"href":240},"contact"," page. A few honest paragraphs about your problem is plenty. We'll tell you plainly whether we're the right studio for it — and if we're not, we'll say so and point you somewhere better.",{"title":244,"searchDepth":245,"depth":245,"links":417},[418,419,425,426,427,428,429],{"id":283,"depth":245,"text":284},{"id":296,"depth":245,"text":297,"children":420},[421,422,423,424],{"id":300,"depth":250,"text":301},{"id":313,"depth":250,"text":314},{"id":323,"depth":250,"text":324},{"id":333,"depth":250,"text":334},{"id":343,"depth":245,"text":344},{"id":368,"depth":245,"text":369},{"id":378,"depth":245,"text":379},{"id":385,"depth":245,"text":386},{"id":404,"depth":245,"text":405},"What AuDHD means in practice for a software studio — hyperfocus, pattern recognition, systems thinking — and the honest costs we manage around.",{},"\u002Fblog\u002Faudhd-founded-software-studio",{"title":275,"description":430},"blog\u002Faudhd-founded-software-studio",[436,437,438],"audhd","neurodivergence","company","7fPxm7cf1RyZ4ANhyp3Jcpp7KhXr8F7vAm8iAQlRs_I",{"id":441,"title":442,"body":443,"datePublished":260,"description":607,"extension":262,"meta":608,"navigation":264,"path":609,"seo":610,"stem":611,"tags":612,"updatedAt":260,"__hash__":615},"blog\u002Fblog\u002Fchoose-software-development-partner-cambridge.md","Choose a Software Development Partner in Cambridge: 12 Questions",{"type":8,"value":444,"toc":588},[445,448,452,455,458,462,466,473,477,480,484,487,491,494,498,501,505,508,512,515,519,525,529,532,536,539,543,546,550,553,557,560,563,566,569,576,580],[11,446,447],{},"Buying bespoke software is mostly a trust decision. You can't inspect the quality of code that hasn't been written yet, references are curated, and every portfolio shows the projects that went well. By the time you find out whether you chose wisely, you're months in and the cost of switching is real. Full disclosure before we go any further: we are a vendor. Overclock Minds is a small software development company in Cambridge, and any guide like this written by a vendor will tilt towards the author's strengths. We've tried to compensate the only honest way we know how — for each question, we'll say what a good answer sounds like, what should disqualify a vendor outright, and where the trade-offs genuinely cut against a studio like ours.",[21,449,451],{"id":450},"why-questions-beat-portfolios","Why questions beat portfolios",[11,453,454],{},"A portfolio tells you what a company shipped on its best days. It says nothing about how they behave under stress — when an estimate turns out to be wrong, when your requirements shift, when you and they disagree about what \"finished\" means. Almost any vendor handles the first month of a project well. The differences show up in month four. These twelve questions are designed to surface month-four behaviour while you're still in month zero, when you can still walk away for free.",[11,456,457],{},"Ask every vendor the same questions, in writing where you can, and keep the answers. Ambiguity at the sales stage never improves later.",[21,459,461],{"id":460},"the-12-questions","The 12 questions",[34,463,465],{"id":464},"_1-who-will-actually-write-my-code","1. Who will actually write my code?",[11,467,468,469,472],{},"Plenty of agencies sell with their most senior people and deliver with subcontractors or offshore teams you'll never meet. Subcontracting isn't automatically bad — bringing in a specialist for one gnarly component can be exactly the right call — but ",[63,470,471],{},"undisclosed"," subcontracting is. Ask for the names and roles of the people who'll do the work, whether they're employees, and whether you can meet them before you sign. A good answer is specific. A disqualifying answer is \"our delivery team will handle that\" with no names attached.",[34,474,476],{"id":475},"_2-how-do-you-estimate-and-when-were-you-last-wrong","2. How do you estimate, and when were you last wrong?",[11,478,479],{},"Honest estimation produces a range plus the assumptions behind it, not a single confident number. Anyone quoting a fixed price for a vaguely specified project has either padded it heavily or is planning to make their margin on change requests. Ask how they break work down, and — more revealing — ask about a project that ran over and what they did about it. A good answer involves telling the client early and re-planning together. A vendor who claims never to have missed an estimate is not telling you the truth, and that's the bigger problem.",[34,481,483],{"id":482},"_3-what-does-discovery-cost-and-what-do-i-walk-away-with","3. What does discovery cost, and what do I walk away with?",[11,485,486],{},"A discovery phase should be a small, fixed-price engagement you can buy on its own — typically days to a few weeks of work, priced accordingly. It should produce documents you own and could take to a different vendor: a written scope, an architecture sketch, a prioritised backlog, known risks, and an estimate range for the build. Be wary of free discovery — it's usually a sales call wearing a lanyard — and equally wary of a \"discovery\" whose only output is a proposal to buy more from the same company.",[34,488,490],{"id":489},"_4-what-happens-when-i-change-my-mind-mid-project","4. What happens when I change my mind mid-project?",[11,492,493],{},"You will change your mind. Everyone does, because building the first version teaches you things you couldn't know up front. Pretending otherwise is the root cause of most vendor disputes. A good answer is a lightweight written process: an impact assessment, what gets deprioritised to make room, the cost and schedule effect, and your sign-off before anything changes. \"We're flexible, we'll sort it out as we go\" sounds friendly but ends in an argument over an invoice. A change process so heavy that a one-line copy tweak needs a fortnight of paperwork is the opposite failure.",[34,495,497],{"id":496},"_5-who-owns-the-ip-and-when-can-i-see-the-source","5. Who owns the IP, and when can I see the source?",[11,499,500],{},"You should own the intellectual property in the bespoke work once you've paid for it; the vendor may reasonably retain ownership of pre-existing libraries, licensed to you. Just as important: source access from day one, meaning a repository in your organisation's account or with you holding admin rights — not screenshots and demo links. Disqualifiers here are blunt ones. Code withheld until final payment as leverage. A proprietary platform you can't take elsewhere. Any arrangement where you end up licensing back the thing you paid to build.",[34,502,504],{"id":503},"_6-what-happens-after-launch","6. What happens after launch?",[11,506,507],{},"Software isn't finished when it ships. Dependencies need updating, security patches need applying, operating systems and browsers change underneath you, and hosting bills arrive monthly. Ask what a typical month of maintenance costs, what's included, and whether the people who built the system are the ones who'll maintain it. No maintenance story at all — \"thirty days' warranty, then good luck\" — should worry you. So should the opposite: a mandatory, expensive retainer with no exit clause.",[34,509,511],{"id":510},"_7-when-did-you-last-turn-down-work-and-why","7. When did you last turn down work, and why?",[11,513,514],{},"A vendor who says yes to everything is either enormous or not being straight with you. Saying no — to a project outside their competence, to a feature that would hurt the product, to a deadline that can't be met — is the clearest sign a company understands its own limits. Ask for a real example and listen for specifics. \"We can do anything\" is a disqualifier, because nobody can, and you'll discover their actual limits at your expense, on your timeline.",[34,516,518],{"id":517},"_8-do-you-understand-my-domain-or-just-your-stack","8. Do you understand my domain, or just your stack?",[11,520,521,522,524],{},"This is the depth-versus-breadth question. Being able to write Python or ship a React app is table stakes; the question is whether the vendor understands regulated data, hardware constraints, clinical workflows, or whatever it is your users actually live with. Deep domain experience isn't always essential — a strong engineer learns fast — but they should be asking sharp questions about your domain in the first meeting, not reciting the same pitch they'd give a logistics firm and a bakery. The local context matters too: the mix of deep tech, life sciences and university spin-outs around here shapes what projects look like, and we've written more about ",[15,523,400],{"href":230}," specifically.",[34,526,528],{"id":527},"_9-who-do-i-actually-talk-to-during-the-build","9. Who do I actually talk to during the build?",[11,530,531],{},"In a layered agency, your requirement can pass from account manager to project manager to tech lead to developer — three retellings before anyone writes a line of code, like a game of expensive whispers. Ask whether you can talk directly to the engineers, what the cadence is (weekly demos of working software is a reasonable baseline), and how quickly questions get answered between meetings. A disqualifier: your only contact is a non-technical account manager, and demos happen at \"milestones\" months apart.",[34,533,535],{"id":534},"_10-what-does-done-mean-to-you","10. What does \"done\" mean to you?",[11,537,538],{},"Get the definition of done in writing. Tested how — automated tests, or someone clicking around once? Deployed where — is there a staging environment you can poke at yourself? Documented for whom? Ask to see redacted acceptance criteria from a real project. A good answer ties \"done\" to written criteria you sign off against. \"Done means the feature works\" is not an answer — works on whose machine, under what load, for which users?",[34,540,542],{"id":541},"_11-how-many-projects-do-you-run-in-parallel-and-what-happens-when-someones-ill","11. How many projects do you run in parallel — and what happens when someone's ill?",[11,544,545],{},"This question cuts against small studios, ours included, so we'll be straight about it. A small team has limited parallel capacity, and key-person risk is real: if one engineer holds a system entirely in their head and they're off for a month, you have a problem. The honest mitigations are documentation, more than one person knowing each system, and realistic scheduling instead of overcommitting. Large agencies have bench cover, which is a genuine advantage — though the person covering may never have seen your codebase. Either way, a vendor with no answer to this question hasn't thought about it, and that's the disqualifier.",[34,547,549],{"id":548},"_12-if-we-part-ways-tomorrow-what-do-i-walk-away-with","12. If we part ways tomorrow, what do I walk away with?",[11,551,552],{},"Ask the exit question while everyone is still friendly. You should walk away with the repository, the deployment configuration, infrastructure running under your own accounts, documentation good enough for a competent new team to take over, and an agreed handover period. Disqualifiers: hosting, domains or app store accounts registered in the vendor's name, or \"we'd need to discuss that at the time\". Discuss it now. A vendor confident in their work doesn't need to hold your project hostage to keep you.",[21,554,556],{"id":555},"small-studio-or-large-agency-the-honest-trade-offs","Small studio or large agency? The honest trade-offs",[11,558,559],{},"Neither is better in general; they're better at different jobs.",[11,561,562],{},"A large agency can staff six workstreams at once, absorb someone leaving without your project noticing, and produce the paperwork that big-company procurement departments love. The costs: layers between you and the people building, senior staff who rotate off to the next pitch after winning yours, and the quiet risk that a smaller account gets deprioritised when a bigger one shouts.",[11,564,565],{},"A small studio offers the inverse. The people you meet are the people who build. The same engineers carry the project from discovery through to maintenance, so context never gets lost in a handover. Your project is a meaningful share of the company's attention rather than a rounding error. The costs are real too: lower parallel capacity, no fifteen-person programmes, and sometimes the honest answer to \"can you start Monday?\" is \"we can start in six weeks\".",[11,567,568],{},"Match the shape of the vendor to the shape of the project. A multi-workstream programme with a hard regulatory deadline probably needs an agency. A single product where deep understanding, continuity and direct access to engineers matter most is usually better served by a small team.",[11,570,571,572,575],{},"We're a small studio, and deliberately so. Overclock Minds is AuDHD-founded, and we organised the company around how our minds actually work: hyperfocus means total immersion in one client's problem at a time rather than a tenth of our attention across ten accounts; pattern recognition means spotting the architecture a problem actually needs before code gets written; systems thinking means caring about the whole thing end to end, including long after launch. The flipside is everything in question 11 — we take on a small number of projects at once, and we'd rather tell you our start date honestly than overcommit. There's more on how we work on the ",[15,573,574],{"href":395},"about Overclock Minds"," page.",[21,577,579],{"id":578},"take-the-list-with-you","Take the list with you",[11,581,582,583,237,585,587],{},"Ask all twelve questions, ask every vendor the same ones, and write the answers down — the comparison is more revealing than any single answer. And if you'd like to point the list at us, we'd genuinely welcome it, awkward questions included. Email ",[15,584,236],{"href":235},[15,586,414],{"href":240}," page. No discovery call required; a plain email describing your problem is a perfectly good place to start.",{"title":244,"searchDepth":245,"depth":245,"links":589},[590,591,605,606],{"id":450,"depth":245,"text":451},{"id":460,"depth":245,"text":461,"children":592},[593,594,595,596,597,598,599,600,601,602,603,604],{"id":464,"depth":250,"text":465},{"id":475,"depth":250,"text":476},{"id":482,"depth":250,"text":483},{"id":489,"depth":250,"text":490},{"id":496,"depth":250,"text":497},{"id":503,"depth":250,"text":504},{"id":510,"depth":250,"text":511},{"id":517,"depth":250,"text":518},{"id":527,"depth":250,"text":528},{"id":534,"depth":250,"text":535},{"id":541,"depth":250,"text":542},{"id":548,"depth":250,"text":549},{"id":555,"depth":245,"text":556},{"id":578,"depth":245,"text":579},"An honest buyer's guide to choosing a software development partner in Cambridge — 12 questions to ask, and which answers should disqualify a vendor.",{},"\u002Fblog\u002Fchoose-software-development-partner-cambridge",{"title":442,"description":607},"blog\u002Fchoose-software-development-partner-cambridge",[613,614],"cambridge","buyers-guide","isJryy0lmIBhDXE0-UBom9RHVprDpVq0EmfFDfIKxYQ",{"id":617,"title":618,"body":619,"datePublished":260,"description":843,"extension":262,"meta":844,"navigation":264,"path":845,"seo":846,"stem":847,"tags":848,"updatedAt":260,"__hash__":852},"blog\u002Fblog\u002Fhardware-software-integration-guide.md","Hardware-Software Integration: The Firmware-to-Cloud Gap",{"type":8,"value":620,"toc":829},[621,624,627,631,634,637,640,646,652,662,665,669,672,676,679,682,686,689,693,696,700,703,707,710,714,717,723,729,735,739,742,745,761,765,768,812,815,819],[11,622,623],{},"The hardware works on the bench. The app demos beautifully on the office Wi-Fi. Then five hundred units ship, and within a month you're fielding support tickets about devices that show \"online\" but ignore commands, charts full of garbage readings, and a firmware update that half the fleet refuses to take. Nobody on either team wrote a bug, exactly. The product is failing in the space between them.",[11,625,626],{},"We do hardware-software integration for a living, and this is the single most consistent thing we see: connected products almost never die because the electronics were badly designed or the cloud was badly architected. They die at the boundary — the place where firmware, connectivity, and cloud meet — because that boundary belonged to nobody.",[21,628,630],{"id":629},"the-two-teams-problem","The two-teams problem",[11,632,633],{},"Most IoT product development happens like this. A company hires an electronics or firmware consultancy to build the device, and a separate web agency to build the app and backend. Both are competent in their own domain. Between them sits a contract: a protocol document, a JSON schema, maybe an OpenAPI spec and a shared Slack channel.",[11,635,636],{},"The contract describes the happy path. The product lives everywhere else.",[11,638,639],{},"Three things reliably fall into the gap:",[11,641,642,645],{},[29,643,644],{},"Protocols."," The document says the device publishes a reading every 60 seconds over MQTT. It doesn't say what happens when the broker connection drops mid-publish, whether messages are queued on-device or discarded, whether QoS 1 duplicates are possible (they are), or who deduplicates them. The firmware team assumes the backend is idempotent. The backend team assumes the device sends each reading once. Both assumptions are reasonable. Both can't be true.",[11,647,648,651],{},[29,649,650],{},"Timing."," Firmware engineers think in milliseconds, interrupt latencies, and watchdog timeouts. Backend engineers think in request-response cycles and eventual consistency. So the device times out and retries after 5 seconds, while the backend takes 8 seconds to process under load, and now every slow request is processed twice. Nobody specified the timeout relationship because each side's timing was an internal detail — until it wasn't.",[11,653,654,657,658,661],{},[29,655,656],{},"Error states."," The device reports fault code ",[129,659,660],{},"0x4F",". The backend logs it as \"unknown error\" because the fault table lives in a C header file the cloud team has never seen. Meanwhile the cloud returns HTTP 429 under load, and the firmware treats anything that isn't 200 as \"retry immediately\", which is exactly the wrong response to a rate limit.",[11,663,664],{},"The gap is contract-shaped: everything written down works, and everything implied breaks.",[21,666,668],{"id":667},"where-integrated-products-actually-die","Where integrated products actually die",[11,670,671],{},"After enough of these projects, the failure points stop being surprising. They cluster in five places.",[34,673,675],{"id":674},"over-the-air-updates","Over-the-air updates",[11,677,678],{},"OTA is the hardest problem in connected hardware because it spans the entire stack. The bootloader and A\u002FB partition scheme are firmware concerns. The update server, signing infrastructure, and staged rollout policy are cloud concerns. The decision logic — when to update, how to verify health afterwards, when to roll back — is both, which in a two-team project usually means neither.",[11,680,681],{},"The questions that matter: what happens if power is cut mid-flash? How does a device prove the new firmware is healthy before committing to it? Can the cloud keep talking to version 1.2 devices while version 1.4 rolls out, and for how long? An update mechanism that hasn't answered these isn't an update mechanism; it's a fleet-bricking mechanism on a delay.",[34,683,685],{"id":684},"fleet-provisioning","Fleet provisioning",[11,687,688],{},"Everything works when an engineer hand-flashes ten development boards with credentials. It falls apart when a contract manufacturer needs to produce five thousand units, each with a unique identity and certificate, claimed by the right customer account on first boot. Provisioning has to be idempotent — devices get factory-reset, returned, refurbished, and re-sold — and it has to work without an engineer in the loop. This is where projects discover, late, that \"how does a device become trusted?\" was never anyone's job.",[34,690,692],{"id":691},"device-state-synchronisation","Device state synchronisation",[11,694,695],{},"A connected device has two states: what the device is actually doing, and what the cloud believes it's doing. The moment connectivity is imperfect — which is always — those diverge. If the app writes commands straight at the device and assumes success, a user toggles a setting while the device is offline and the system now permanently disagrees with itself. Solving this properly means a desired-state\u002Freported-state model (a device shadow or twin), conflict rules, and a UI honest about staleness. It's well-understood architecture, but it has to be designed across the boundary, not bolted on from one side.",[34,697,699],{"id":698},"flaky-connectivity","Flaky connectivity",[11,701,702],{},"The bench has perfect Wi-Fi. The field has cellular dead zones, captive portals, hostile NAT, and routers that lie about DNS. Two specific failures recur. First, devices that retry without exponential backoff and jitter: after a regional power cut, ten thousand devices reconnect in the same second and take down your own broker — a self-inflicted denial of service. Second, on-device buffering with no policy: how much data do you store offline, what do you drop first, and what timestamp do you attach when the real-time clock hasn't synced yet? \"It reconnects eventually\" is not a design.",[34,704,706],{"id":705},"instrument-data-formats","Instrument data formats",[11,708,709],{},"For scientific and industrial equipment, the payload itself is a boundary. Packed binary structs with endianness assumptions, raw ADC counts that need device-specific calibration coefficients, units that exist only in a comment in the firmware source. Then firmware 1.3 adds a field, half the fleet is still on 1.2, and the cloud parser has to handle both — forever. Payload schema versioning across a mixed-version fleet is unglamorous and absolutely product-critical.",[21,711,713],{"id":712},"what-this-looks-like-when-it-goes-wrong","What this looks like when it goes wrong",[11,715,716],{},"These are hypothetical, but each is a composite of failure modes we've seen variants of in the wild.",[11,718,719,722],{},[29,720,721],{},"Imagine a lab instrument company."," The device's clock resets to 1970 on power loss and corrects itself once NTP syncs, a minute or so after boot. Firmware timestamps readings locally; the cloud trusts device timestamps. Every power cycle produces a burst of readings dated fifty-six years ago, which the backend's retention policy silently deletes as expired. The data isn't wrong in either codebase. It's wrong in the gap.",[11,724,725,728],{},[29,726,727],{},"Imagine a heating controller."," The app reads state from the cloud's cached record, which says \"on\" because that was the last command sent. The device has been offline for two days. Customers stare at an app confidently displaying a fiction, and the support team has no tool that shows the difference between \"device reports on\" and \"we told it to turn on and heard nothing back\".",[11,730,731,734],{},[29,732,733],{},"Imagine an OTA rollout"," where the new firmware reports update health over a connection that a customer's captive-portal Wi-Fi quietly blocks. The device can't confirm health, dutifully rolls back, re-downloads the update overnight, and repeats — an invisible update loop chewing through a metered SIM. The bootloader behaved correctly. The server behaved correctly. The product failed.",[21,736,738],{"id":737},"what-changes-when-one-team-owns-sensor-to-screen","What changes when one team owns sensor-to-screen",[11,740,741],{},"When the same team designs the firmware, the protocol, and the cloud — what we'd call sensor-to-screen ownership — the gap doesn't get bridged. It stops existing.",[11,743,744],{},"Decisions get made once, with the whole system in view. The message format is designed knowing both the device's RAM budget and the dashboard's query patterns. The retry policy is one policy, with backoff tuned against real broker limits. Error states share a single taxonomy from ADC fault to support dashboard, so when a customer calls, someone can actually trace the failure. And the integration gets tested as a system: hardware-in-the-loop rigs in CI, cloud deployments validated against real devices on a desk — not two halves meeting for the first time in a customer's building.",[11,746,747,748,752,753,757,758,760],{},"This is also where how we work matters. Our ",[15,749,751],{"href":750},"\u002Fservices\u002Fembedded-hardware","embedded & hardware integration"," practice and our ",[15,754,756],{"href":755},"\u002Fservices\u002Fcloud-devops","cloud & DevOps"," practice are the same people, deliberately. Hyperfocus means the protocol design, the power budget, and the rollout policy are held in one head at the same time — which is precisely what boundary problems require, because they're invisible to anyone holding only half the system. Pattern recognition across layers is how you spot that a \"random\" cloud data anomaly is actually a clock-sync issue three layers down before it ships. Cambridge happens to be a good place to do this from: the region is dense with instrument makers, deep-tech spinouts, and hardware companies, which is a large part of why we focus on ",[15,759,400],{"href":230}," and the surrounding area for embedded systems development in the UK.",[21,762,764],{"id":763},"questions-to-ask-any-vendor-about-the-boundary","Questions to ask any vendor about the boundary",[11,766,767],{},"Whoever you're evaluating — including us — these questions expose whether the gap has an owner:",[185,769,770,776,782,788,794,800,806],{},[188,771,772,775],{},[29,773,774],{},"Who owns the protocol spec, and how does it change after launch"," when devices in the field still speak the old version?",[188,777,778,781],{},[29,779,780],{},"Walk me through an OTA update that loses power halfway."," What does the device do? What does the cloud see? Who finds out?",[188,783,784,787],{},[29,785,786],{},"How does a unit get its identity and certificates at the factory",", and what happens when one is factory-reset and resold?",[188,789,790,793],{},[29,791,792],{},"What does the app show when a device has been offline for an hour?"," Where do commands sent during that hour go?",[188,795,796,799],{},[29,797,798],{},"What happens when the whole fleet reconnects at once"," after a network outage?",[188,801,802,805],{},[29,803,804],{},"How is the integration tested?"," Is real hardware in the CI loop, or do firmware and cloud first meet in the field?",[188,807,808,811],{},[29,809,810],{},"How many firmware versions can the backend handle simultaneously",", and for how long?",[11,813,814],{},"A vendor who answers these crisply has built integrated products before. A vendor who says \"the firmware team handles that\" is showing you the gap.",[21,816,818],{"id":817},"building-or-rescuing-a-connected-product","Building or rescuing a connected product?",[11,820,821,822,824,825,828],{},"If you're planning an integrated product — or have one in the field that's behaving in ways nobody can explain — we're happy to talk through the architecture. No pitch deck, no obligation; sometimes a one-hour conversation about where your boundary lives is genuinely all that's needed. Email us at ",[15,823,236],{"href":235}," or ",[15,826,827],{"href":240},"get in touch here",".",{"title":244,"searchDepth":245,"depth":245,"links":830},[831,832,839,840,841,842],{"id":629,"depth":245,"text":630},{"id":667,"depth":245,"text":668,"children":833},[834,835,836,837,838],{"id":674,"depth":250,"text":675},{"id":684,"depth":250,"text":685},{"id":691,"depth":250,"text":692},{"id":698,"depth":250,"text":699},{"id":705,"depth":250,"text":706},{"id":712,"depth":245,"text":713},{"id":737,"depth":245,"text":738},{"id":763,"depth":245,"text":764},{"id":817,"depth":245,"text":818},"Connected products rarely die in the firmware or the cloud. They die in the gap between. Here's where it happens and how to close it.",{},"\u002Fblog\u002Fhardware-software-integration-guide",{"title":618,"description":843},"blog\u002Fhardware-software-integration-guide",[849,850,851],"embedded","hardware","iot","gI4mrvFN2-IF3Ue87zcXhx_v95N6HqGdGGmsKC4lY-Q",{"id":854,"title":855,"body":856,"datePublished":260,"description":1089,"extension":262,"meta":1090,"navigation":264,"path":1091,"seo":1092,"stem":1093,"tags":1094,"updatedAt":260,"__hash__":1098},"blog\u002Fblog\u002Flegacy-system-modernisation-rewrite-trap.md","Legacy System Modernisation: Escaping the Big-Rewrite Trap",{"type":8,"value":857,"toc":1073},[858,861,864,868,871,875,878,882,885,889,892,896,903,907,910,913,939,942,945,949,952,956,959,967,971,974,980,984,987,1008,1011,1015,1018,1050,1058,1062],[11,859,860],{},"There is a conversation that happens in almost every company running software older than ten years. Someone — often a new technical hire, sometimes a frustrated director — looks at the creaking system that runs the business and says: \"We should just rewrite it.\" It sounds decisive. It sounds clean. And in our experience, it is usually the most expensive mistake on the table.",[11,862,863],{},"Legacy system modernisation is most of what serious software work actually is. Very few businesses get to start from a blank page; most are carrying a system that works well enough to be indispensable and badly enough to be resented. This post is about how to replace that system without betting the company on a single cutover weekend — and about the rarer cases where a clean rewrite genuinely is the right answer.",[21,865,867],{"id":866},"why-big-bang-rewrites-fail","Why big-bang rewrites fail",[11,869,870],{},"A \"big rewrite\" — or big-bang legacy software replacement, if you prefer the formal term — means building a complete new system in parallel, then switching everything over at once. The failure modes are well documented and depressingly consistent.",[34,872,874],{"id":873},"the-second-system-effect","The second-system effect",[11,876,877],{},"The team rebuilding a system they already know tends to design for every frustration they ever had with the old one. Every shortcut gets corrected, every \"we should have\" gets included, every speculative future requirement gets an abstraction. The result is a second system that is more ambitious, more complex, and slower to deliver than the first — a pattern Fred Brooks named the second-system effect over fifty years ago. It has not gone away.",[34,879,881],{"id":880},"the-target-keeps-moving","The target keeps moving",[11,883,884],{},"The old system does not freeze while you rebuild it. The business still needs new features, regulatory changes still land, customers still report bugs. So either the old system keeps evolving — and the rewrite is chasing a moving target it can never quite catch — or the business accepts a feature freeze that gets harder to justify every quarter. We have seen rewrites where, by year two, the new system was further from parity than it was at the start.",[34,886,888],{"id":887},"hidden-business-rules-surface-at-the-worst-moment","Hidden business rules surface at the worst moment",[11,890,891],{},"Old code accumulates decisions nobody wrote down. That odd rounding behaviour in the invoicing module is not a bug — it matches a 2014 agreement with your largest customer. The strange validation rule exists because of a fraud incident everyone has forgotten. In a big-bang rewrite, you discover these rules at cutover, in production, with real customers, all at once. The old system was the only complete specification of itself, and you just turned it off.",[34,893,895],{"id":894},"years-with-nothing-shipped","Years with nothing shipped",[11,897,898,899,902],{},"This is the failure that kills rewrites politically rather than technically. A big rewrite delivers nothing until it delivers everything. For eighteen months or three years, the business pays two costs — maintaining the old system and building the new one — and receives no visible benefit. Budgets get questioned, sponsors move on, and a half-finished rewrite is worth almost nothing. Plenty of companies end up running the old system ",[63,900,901],{},"and"," fragments of the abandoned new one, which is strictly worse than where they started.",[21,904,906],{"id":905},"the-strangler-fig-pattern-in-plain-english","The strangler-fig pattern, in plain English",[11,908,909],{},"The alternative has an evocative name. A strangler fig is a plant that grows around a host tree, gradually taking over its structure until the original tree is gone and the fig stands on its own. Applied to software, the idea is simple: the new system grows around the old one, taking over responsibility piece by piece, until one day the old system has nothing left to do and can be switched off almost as an afterthought.",[11,911,912],{},"Mechanically, it usually works like this:",[185,914,915,921,927,933],{},[188,916,917,920],{},[29,918,919],{},"Put a routing layer in front of the old system."," This might be a reverse proxy, an API gateway, or routing logic in the application itself. At first it sends 100% of traffic to the legacy system — nothing changes for users.",[188,922,923,926],{},[29,924,925],{},"Build one piece in the new system."," A single screen, a single API endpoint, a single report. Something small with clear edges.",[188,928,929,932],{},[29,930,931],{},"Move that route over."," The routing layer now sends requests for that one piece to the new code. Everything else still goes to the old system. If something goes wrong, you flip the route back in minutes, not days.",[188,934,935,938],{},[29,936,937],{},"Repeat."," Route by route, module by module, traffic migrates. The old system shrinks in importance without ever being torn out.",[11,940,941],{},"The decisive advantage is that every step is small, reversible, and shipped. You get value early — often within weeks — and the business never has a moment where everything depends on one untested cutover. Hidden business rules still exist, but you discover them one module at a time, while the old system is still running and can be checked against.",[11,943,944],{},"The honest caveats: the strangler approach requires discipline, and it requires that someone holds the whole picture in their head — old system, new system, the routing layer, and the data flowing between them. Data is the hard part. While both systems are live, you need a clear answer to \"which system owns this record?\", and that answer has to hold under failure. This is where most strangler migrations get into trouble, and it is exactly the kind of end-to-end systems problem we are built for. Hyperfocus is genuinely useful here: tracing one invoice through a fifteen-year-old codebase to understand why it rounds the way it does is tedious work for most teams and absorbing work for ours.",[21,946,948],{"id":947},"sequencing-by-risk-where-to-start","Sequencing by risk: where to start",[11,950,951],{},"Not all modules are equal, and the order in which you migrate them is most of the strategy. Two rules cover most of it.",[34,953,955],{"id":954},"start-with-read-only-views","Start with read-only views",[11,957,958],{},"The safest possible first step is something that displays data without changing it — a dashboard, a search screen, a report. If a read-only view has a bug, someone sees a wrong number and tells you; no data is corrupted, no order is lost, no money moves incorrectly. Read-only work also forces you to solve the unglamorous foundations — authentication, access to legacy data, deployment, monitoring — while the stakes are low. By the time you migrate something that writes data, the plumbing is proven.",[11,960,961,962,966],{},"This is also where modern ",[15,963,965],{"href":964},"\u002Fservices\u002Fweb-applications","web application development"," earns its keep quickly. A fast, well-designed read layer over legacy data is often the most visible improvement users get in the entire project, and it ships in the first month rather than the last.",[34,968,970],{"id":969},"then-lowest-risk-highest-pain","Then lowest-risk, highest-pain",[11,972,973],{},"Plot every module on two axes: how much it hurts the business today, and how dangerous it would be to get wrong. Migrate the ones that are high-pain and low-risk first. Imagine a distributor whose stock-lookup screen takes thirty seconds to load and infuriates the warehouse team daily, but whose payment processing works fine and touches real money. The stock screen goes first — maximum relief, minimal blast radius. Payments go near the end, when the team has a dozen successful migrations behind it and the tooling is battle-tested.",[11,975,976,977,979],{},"What you should ",[63,978,97],{}," do is start with the hardest module \"to de-risk the project\". The hardest module is hardest precisely because it is full of hidden rules and tangled dependencies. Earn the right to touch it.",[21,981,983],{"id":982},"when-a-rewrite-is-the-right-call","When a rewrite is the right call",[11,985,986],{},"We are opinionated about this, but not dogmatic. There are real cases where a clean rewrite beats incremental migration:",[988,989,990,996,1002],"ul",{},[188,991,992,995],{},[29,993,994],{},"Genuinely small systems."," If the whole thing is a few thousand lines and one developer can understand it completely in a fortnight, the overhead of routing layers and parallel running exceeds the cost of just rebuilding it. Strangler patterns are for systems too large to hold in one head.",[188,997,998,1001],{},[29,999,1000],{},"Dead platforms."," If the system runs on a language, framework, or operating system that is no longer maintained — no security patches, no available developers, no way to hire — incremental migration may be impossible because you cannot safely change the old side at all. Sometimes the host tree is already dead.",[188,1003,1004,1007],{},[29,1005,1006],{},"Security cliff edges."," If the legacy system has unfixable vulnerabilities, fails a compliance requirement with a hard deadline, or handles data in a way that is now indefensible, the timeline is set by the risk, not by engineering preference. A focused rewrite of the exposed surface — note: the exposed surface, not necessarily everything — can be the only responsible option.",[11,1009,1010],{},"Even in these cases, the rewrite should be scoped ruthlessly: rebuild what exists, resist the second-system urge to \"improve\" everything at once, and ship improvements as a second phase once parity is proven.",[21,1012,1014],{"id":1013},"keeping-the-business-running-throughout","Keeping the business running throughout",[11,1016,1017],{},"Whatever the approach, the non-negotiable constraint is that the business keeps operating. A few practices make that realistic:",[988,1019,1020,1026,1032,1038,1044],{},[188,1021,1022,1025],{},[29,1023,1024],{},"One writer per record."," At any moment, exactly one system is the source of truth for any given piece of data. Both systems may read; only one writes. Ambiguity here is how migrations corrupt data.",[188,1027,1028,1031],{},[29,1029,1030],{},"Reversibility as a requirement."," Every migration step needs a tested way back. If a route cannot be flipped back to the legacy system, it is not ready to flip forward.",[188,1033,1034,1037],{},[29,1035,1036],{},"Run in shadow before you cut over."," For high-stakes modules, run the new code alongside the old, compare outputs on real traffic, and only switch when they agree. Discrepancies found in shadow mode are free; discrepancies found in production are not.",[188,1039,1040,1043],{},[29,1041,1042],{},"A narrow, honest feature freeze."," You usually cannot freeze the whole legacy system, but you can freeze the module currently being migrated. Keep the frozen zone small and the freeze short.",[188,1045,1046,1049],{},[29,1047,1048],{},"Tell users what is changing and when."," Most migration pain reported by users is actually surprise. A two-line email beats a perfect rollback plan you never needed.",[11,1051,1052,1053,1057],{},"None of this is exotic. It is mostly the patient application of systems thinking: seeing the old system, the new system, the data, and the people who depend on them as one whole, and refusing to break any part of it for the convenience of the project plan. That end-to-end view — and the pattern recognition to spot the landmines in an unfamiliar codebase early — is the core of how we approach ",[15,1054,1056],{"href":1055},"\u002Fservices\u002Flegacy-modernisation","legacy modernisation",", and frankly it is the kind of work our brains are wired for.",[21,1059,1061],{"id":1060},"talk-to-us-before-you-commit-to-a-rewrite","Talk to us before you commit to a rewrite",[11,1063,1064,1065,1067,1068,237,1070,1072],{},"If you are weighing up a legacy migration — or you are partway through a rewrite that has stopped feeling like a good idea — a second opinion is cheap and the alternative is not. We do ",[15,1066,400],{"href":230}," and remotely across the UK, and we are happy to look at a system and tell you honestly whether it needs a strangler, a rewrite, or just six weeks of targeted repair. Email us at ",[15,1069,236],{"href":235},[15,1071,241],{"href":240},". No deck, no pressure — just send a description of the system and what is hurting.",{"title":244,"searchDepth":245,"depth":245,"links":1074},[1075,1081,1082,1086,1087,1088],{"id":866,"depth":245,"text":867,"children":1076},[1077,1078,1079,1080],{"id":873,"depth":250,"text":874},{"id":880,"depth":250,"text":881},{"id":887,"depth":250,"text":888},{"id":894,"depth":250,"text":895},{"id":905,"depth":245,"text":906},{"id":947,"depth":245,"text":948,"children":1083},[1084,1085],{"id":954,"depth":250,"text":955},{"id":969,"depth":250,"text":970},{"id":982,"depth":245,"text":983},{"id":1013,"depth":245,"text":1014},{"id":1060,"depth":245,"text":1061},"Why big-bang legacy software replacement usually fails, how the strangler-fig pattern works, and when a full rewrite genuinely is the right call.",{},"\u002Fblog\u002Flegacy-system-modernisation-rewrite-trap",{"title":855,"description":1089},"blog\u002Flegacy-system-modernisation-rewrite-trap",[1095,1096,1097],"legacy","modernisation","architecture","j3RQG8SrENYkdZHG33J7I5jRIn7zMUCkTswXAoGBIAs",{"id":1100,"title":1101,"body":1102,"datePublished":260,"description":1325,"extension":262,"meta":1326,"navigation":264,"path":1327,"seo":1328,"stem":1329,"tags":1330,"updatedAt":260,"__hash__":1333},"blog\u002Fblog\u002Fmvp-development-cambridge-startups.md","MVP development for Cambridge startups: what to build first",{"type":8,"value":1103,"toc":1312},[1104,1110,1113,1117,1120,1123,1130,1133,1137,1140,1144,1147,1151,1154,1157,1161,1164,1167,1171,1174,1195,1198,1201,1205,1216,1219,1222,1242,1248,1252,1255,1290,1294,1297,1300,1304],[11,1105,1106,1107,1109],{},"Most MVPs don't fail in production. They fail in the planning document, months earlier, when someone wrote \"minimum viable product\" at the top of a page and then listed every feature the finished product would need. If you're a Cambridge startup — a spinout, a grant-funded venture, or two people with a Companies House registration and a hypothesis — the highest-leverage decision you'll make this year is what ",[63,1108,97],{}," to build.",[11,1111,1112],{},"We build software for early-stage companies, and the pattern is consistent enough to be worth writing down: the startups that learn fastest build the least, fake the most, and are brutally honest about which assumption their MVP actually exists to test.",[21,1114,1116],{"id":1115},"an-mvp-is-an-experiment-not-version-one","An MVP is an experiment, not version one",[11,1118,1119],{},"The useful definition of an MVP: the cheapest thing you can put in front of real users that gives you a definitive answer to your riskiest assumption.",[11,1121,1122],{},"That framing changes everything, because experiments have a hypothesis and v1 products have feature lists. Ask \"what would the product need?\" and the answer is everything — accounts, billing, settings, notifications, an admin panel. Ask \"what does the experiment need?\" and the answer is usually one core interaction and a way to observe what users do with it.",[11,1124,1125,1126,1129],{},"So before any technology discussion, write your riskiest assumption down as a single sentence. Something like: \"Lab managers will trust an automated system to schedule shared equipment instead of the whiteboard.\" Then put every proposed feature through one filter: ",[63,1127,1128],{},"if we cut this, does the experiment still produce a clear answer?"," If yes, cut it. Most features survive scoping meetings not because they're necessary but because nobody asked.",[11,1131,1132],{},"This is ruthless, and it should be. Every week spent building something the experiment doesn't need is a week of runway converted into code you'll probably delete.",[21,1134,1136],{"id":1135},"what-to-fake","What to fake",[11,1138,1139],{},"Faking parts of a product feels wrong to engineers. It isn't wrong; it's correct sequencing. Users can't see your architecture — they can only see the surface — and at MVP stage the surface is the only part that has to hold. Three categories almost never need to be real:",[34,1141,1143],{"id":1142},"admin-panels-use-a-spreadsheet","Admin panels: use a spreadsheet",[11,1145,1146],{},"Nobody outside your company will ever see the admin panel, so stop designing one. A CRUD interface with role management and audit logging is weeks of work serving two members of staff. Instead, have the application read from a shared spreadsheet or Airtable base, or accept that \"updating a record\" means someone runs a script. From the outside, the product is identical. Build real admin tooling when staff time becomes the bottleneck — at MVP scale, it won't be.",[34,1148,1150],{"id":1149},"automation-do-it-by-hand-first","\"Automation\": do it by hand first",[11,1152,1153],{},"The concierge MVP is the most underused trick in early-stage product work. If your product promises matching, report generation, scheduling, or any other clever processing, do it manually behind the scenes. The user uploads their data; your \"engine\" is a person with a spreadsheet and a four-hour turnaround.",[11,1155,1156],{},"This buys you two things. First, it validates demand before you've spent anything on the clever part. Second — and this is the bit people miss — doing the job by hand teaches you what the automation actually needs to do. Every edge case you hit manually is a requirement you'd otherwise have discovered in production. Yes, it doesn't scale. It doesn't need to. It needs to survive twenty users, not twenty thousand.",[34,1158,1160],{"id":1159},"configurable-flows-hard-code-them","Configurable flows: hard-code them",[11,1162,1163],{},"Settings pages, pricing tiers, white-labelling, \"flexible\" workflows — hard-code all of it. One plan, one flow, one configuration. If a second customer needs something different, change a constant and redeploy; that's minutes, against the weeks a configuration UI costs. You'll also guess the wrong axes of configurability anyway — you don't know which knobs matter until customers tell you.",[11,1165,1166],{},"The same logic covers payments (a Stripe payment link instead of integrated billing), auth (magic links instead of full account management), and transactional email (sent by a person, at first).",[21,1168,1170],{"id":1169},"what-must-be-real","What must be real",[11,1172,1173],{},"One thing cannot be faked: the thing your riskiest assumption is about.",[988,1175,1176,1183,1189],{},[188,1177,1178,1179,1182],{},"If the risk is ",[29,1180,1181],{},"demand"," — will anyone pay? — the front of the product must be real enough to take money, even if the back is a person with a spreadsheet.",[188,1184,1178,1185,1188],{},[29,1186,1187],{},"technical"," — can our model, sensor, or algorithm do this at all? — the core technology must be real, and everything around it (UI, onboarding, billing) can be scaffolding.",[188,1190,1178,1191,1194],{},[29,1192,1193],{},"behavioural"," — will users actually change their workflow? — the workflow itself must be real and genuinely pleasant to use, and everything else stays minimal.",[11,1196,1197],{},"The common failure mode is building everything to 70%: a polished interface wrapped around a faked core, when the core was the question. That demo lies to you, and you make your next funding decision on the lie.",[11,1199,1200],{},"A good MVP is lopsided on purpose. One part is disproportionately solid — the experiment — and everything else is openly held together with tape. This is, candidly, where the way we work earns its keep: we're an AuDHD-founded studio, and when we lock onto the one component that has to be real, it gets total immersion, while pattern recognition from previous builds makes it faster to spot which parts are safely fakeable.",[21,1202,1204],{"id":1203},"the-cambridge-problem-milestone-shaped-mvps","The Cambridge problem: milestone-shaped MVPs",[11,1206,1207,1208,1211,1212,1215],{},"Cambridge startups operate inside a specific distortion field. University spinouts and grant-funded ventures don't only answer to users — they answer to milestones: the investor demo day, the Innovate UK quarterly deliverable, the departmental review. Milestones reward ",[63,1209,1210],{},"looking finished",". Experiments reward ",[63,1213,1214],{},"finding the truth quickly",". Those pull in opposite directions, and the milestone usually wins.",[11,1217,1218],{},"The result is a familiar shape: a demo build that impresses a panel but tests nothing — one hard-coded happy path that no user outside the room could survive. Or grant deliverables written eighteen months ago dictating what gets built this quarter, regardless of everything learnt since.",[11,1220,1221],{},"You can handle this without torching your funding:",[185,1223,1224,1230,1236],{},[188,1225,1226,1229],{},[29,1227,1228],{},"Separate the demo from the experiment, explicitly."," A demo is allowed to be a film set — scripted path, hard-coded data — provided everyone internally knows it's a set. The danger isn't the set; it's the moment the team starts believing it's a building.",[188,1231,1232,1235],{},[29,1233,1234],{},"Write deliverables around learning where you can."," Monitoring officers and assessors generally accept milestones framed as validated questions — \"completed pilot with N users and a go\u002Fno-go decision\" — rather than shipped feature lists. That phrasing gives you room to follow the evidence. The honest caveat: sometimes the deliverable list is already fixed. In that case, build each deliverable as cheaply as honesty allows and ring-fence part of the budget for the real experiment.",[188,1237,1238,1241],{},[29,1239,1240],{},"Spinouts: test the commercial risk, not the science."," If the technology was de-risked in the lab, re-demonstrating it is comfort work. The untested assumption is almost always commercial — will anyone outside academia pay for it, integrate it, change their process for it? Aim the MVP there.",[11,1243,1244,1245,1247],{},"Navigating those funding-cycle pressures alongside the build is a large part of what our ",[15,1246,400],{"href":230}," work involves, because the build and the milestones have to be planned together or one quietly eats the other.",[21,1249,1251],{"id":1250},"tech-choices-that-keep-options-open","Tech choices that keep options open",[11,1253,1254],{},"Over-engineering is the respectable-looking way to kill an MVP. Microservices for zero users, Kubernetes for one container, an event-sourced architecture because the conference talk was persuasive. The opposite failure — \"just throw something together\" — produces a build too brittle to learn from. The middle path:",[988,1256,1257,1263,1269,1275,1284],{},[188,1258,1259,1262],{},[29,1260,1261],{},"Boring, mainstream stack."," Postgres, a mainstream web framework, one server or a simple managed platform. Boring means problems are searchable, hiring is easier later, and nothing about it prevents scaling. Most products you use daily started as a monolith on exactly this.",[188,1264,1265,1268],{},[29,1266,1267],{},"A monolith with clean seams."," Keep modules separated inside one deployable. You get most of the future flexibility of services with none of the operational cost.",[188,1270,1271,1274],{},[29,1272,1273],{},"Buy, don't run."," Managed auth, managed email, managed payments, managed hosting. Your differentiation is the experiment, not your infrastructure.",[188,1276,1277,1280,1281,1283],{},[29,1278,1279],{},"Web first, unless hardware or native genuinely demands otherwise."," Responsive ",[15,1282,965],{"href":964}," reaches every device from one codebase; native apps and app-store review cycles can wait until the experiment says yes.",[188,1285,1286,1289],{},[29,1287,1288],{},"Decide what's scaffolding and what's foundation — upfront."," Either answer is fine. Pretending the code is both is how a \"temporary\" prototype ends up carrying five years of production traffic. Realistically, successful MVP code gets refactored rather than rewritten, so keep one boundary clean — the core domain logic — and let the edges be scrappy.",[21,1291,1293],{"id":1292},"budget-reality","Budget reality",[11,1295,1296],{},"An MVP scoped as an experiment, with aggressive faking, is a build measured in weeks, not months — and the cost should reflect that. If a proposal for your \"MVP\" runs six months before first user contact, it isn't an MVP; it's a v1 wearing the name to get through budget approval.",[11,1298,1299],{},"Two rules of thumb we'd stand behind. First: if the build costs more than running the manual concierge version for six months would, the scoping went wrong. Second: reserve 20–30% of the budget for changes after launch. The first version will be wrong in specific, informative ways — that's the point of it — and the startups that budget for iteration learn from those signals instead of just absorbing them.",[21,1301,1303],{"id":1302},"where-to-start","Where to start",[11,1305,1306,1307,824,1309,828],{},"If you're scoping an MVP — spinout, grant-funded, or bootstrapped — we're happy to talk through what to build and what to fake, with no pitch deck required. Email ",[15,1308,236],{"href":235},[15,1310,1311],{"href":240},"get in touch",{"title":244,"searchDepth":245,"depth":245,"links":1313},[1314,1315,1320,1321,1322,1323,1324],{"id":1115,"depth":245,"text":1116},{"id":1135,"depth":245,"text":1136,"children":1316},[1317,1318,1319],{"id":1142,"depth":250,"text":1143},{"id":1149,"depth":250,"text":1150},{"id":1159,"depth":250,"text":1160},{"id":1169,"depth":245,"text":1170},{"id":1203,"depth":245,"text":1204},{"id":1250,"depth":245,"text":1251},{"id":1292,"depth":245,"text":1293},{"id":1302,"depth":245,"text":1303},"How Cambridge startups should scope an MVP — what to fake, what must be real, and how investor demos and Innovate UK milestones distort the build.",{},"\u002Fblog\u002Fmvp-development-cambridge-startups",{"title":1101,"description":1325},"blog\u002Fmvp-development-cambridge-startups",[1331,1332,613],"startups","mvp","7zZGsX2z6J0SK1-ZNEJ8kVGyxLUsDZqZTS5isw5zojk",{"id":1335,"title":1336,"body":1337,"datePublished":260,"description":1604,"extension":262,"meta":1605,"navigation":264,"path":1606,"seo":1607,"stem":1608,"tags":1609,"updatedAt":260,"__hash__":1613},"blog\u002Fblog\u002Freplace-spreadsheets-custom-software.md","When to Replace Spreadsheets with Custom Software",{"type":8,"value":1338,"toc":1591},[1339,1342,1345,1349,1352,1356,1367,1371,1374,1378,1389,1393,1396,1399,1403,1406,1412,1418,1424,1430,1433,1437,1443,1446,1482,1485,1495,1499,1502,1508,1518,1524,1528,1531,1570,1573,1577,1580],[11,1340,1341],{},"Spreadsheets are probably the most successful programming tool ever shipped. Millions of people who would never call themselves developers use them to model, calculate and automate real work, and most of the time that's exactly right. We're not here to tell you Excel is bad. We're here to talk about the moment a spreadsheet stops being a tool and quietly becomes a system — load-bearing infrastructure that the business depends on, with none of the safeguards a system needs.",[11,1343,1344],{},"That transition almost never happens on purpose. Someone builds a sheet to solve Tuesday's problem. It works, so it absorbs Wednesday's problem too. Three years later it has forty tabs, a macro nobody dares touch, and a starring role in every month-end. If that sounds familiar, this post is for you: how to recognise the tipping point, what it's actually costing you, and what a sensible replacement looks like — which is usually much smaller than people fear.",[21,1346,1348],{"id":1347},"the-symptoms-when-a-spreadsheet-becomes-infrastructure","The symptoms: when a spreadsheet becomes infrastructure",[11,1350,1351],{},"You don't need a consultant's maturity audit. You need an honest look at four symptoms.",[34,1353,1355],{"id":1354},"version-chaos","Version chaos",[11,1357,1358,1359,1362,1363,1366],{},"There's a file called ",[129,1360,1361],{},"Pricing_Master_FINAL_v7_USE_THIS_ONE.xlsx",", and another called ",[129,1364,1365],{},"Pricing_Master_FINAL_v7_USE_THIS_ONE (Sarah's copy).xlsx",", and nobody is completely certain which one fed last quarter's numbers. Files get emailed, copied to laptops, edited in parallel and merged by eye. Shared drives and co-editing help, but they don't fix the underlying issue: a spreadsheet has no real concept of one canonical record that everyone reads from and writes to.",[34,1368,1370],{"id":1369},"one-person-who-understands-the-spreadsheet","One person who understands THE spreadsheet",[11,1372,1373],{},"Every business that has hit this point has one. Ask how the rebate calculation works and the answer is \"ask Dave\". Dave built it in 2019, Dave knows which cells you must never sort, Dave is the only person who can run month-end. Dave is excellent. Dave is also a single point of failure with annual leave booked.",[34,1375,1377],{"id":1376},"silent-formula-errors","Silent formula errors",[11,1379,1380,1381,1384,1385,1388],{},"This is the symptom people underestimate most. Code fails loudly: an exception, a failed test, a red pipeline. A spreadsheet fails silently. A row gets inserted and a ",[129,1382,1383],{},"SUM"," range doesn't stretch to cover it. A ",[129,1386,1387],{},"VLOOKUP"," falls back to an almost-right match. Someone pastes values over a formula to \"fix\" one cell. The sheet keeps producing confident-looking numbers, and nothing anywhere tells you they're wrong. Published studies of operational spreadsheets have repeatedly found that a large proportion contain errors — and your sheets weren't built under audit conditions either.",[34,1390,1392],{"id":1391},"copy-paste-as-a-business-process","Copy-paste as a business process",[11,1394,1395],{},"Watch how data moves through the company. If the answer involves a person exporting from one system, pasting into a sheet, massaging columns, then pasting the result into another sheet or re-keying it into another system — that's not admin, that's an unpaid, error-prone integration layer made of human attention. It's also usually the job everyone hates, which means it gets rushed, which means it gets wrong.",[11,1397,1398],{},"Two or more of these, on a spreadsheet the business genuinely depends on, and you've crossed the line. The sheet is infrastructure now. It's just infrastructure with no backups discipline, no access control, no tests and no audit trail.",[21,1400,1402],{"id":1401},"what-its-actually-costing-you","What it's actually costing you",[11,1404,1405],{},"The costs hide well because no invoice ever arrives marked \"spreadsheet tax\". They show up elsewhere.",[11,1407,1408,1411],{},[29,1409,1410],{},"Errors with real money attached."," Mis-quoted prices, missed renewals, stock ordered twice, a margin calculation that's been subtly wrong since someone reorganised the tabs. Individually small, cumulatively significant — and occasionally not small at all, when the wrong number lands in front of a customer or an accountant.",[11,1413,1414,1417],{},[29,1415,1416],{},"Key-person risk."," If the person who understands the sheet leaves, you don't lose a file, you lose the operating knowledge encoded in it. We've seen businesses pay departed employees as contractors purely to keep a workbook alive. That's not a process; that's a hostage situation with a formula bar.",[11,1419,1420,1423],{},[29,1421,1422],{},"No audit trail."," When a number looks wrong, can you say who changed it, when, from what, and why? In a spreadsheet, generally not. That's irritating day to day and genuinely serious the moment a dispute, an insurance claim, an FCA question or a tax inspection turns up. \"The spreadsheet said so\" is not an evidence trail.",[11,1425,1426,1429],{},[29,1427,1428],{},"Scaling walls."," Spreadsheets degrade non-linearly. They're fine at 500 rows, sluggish at 50,000, and unusable somewhere after that — usually discovered at the worst possible moment. The same applies to people: two careful users is fine, ten concurrent users is chaos. Growth turns a workable sheet into a bottleneck without anyone changing anything.",[11,1431,1432],{},"There's also a quieter cost: the hours. Add up the weekly time spent reconciling versions, fixing breakages and shuttling data between sheets. At even modest salaries it often funds the replacement within the first year or two.",[21,1434,1436],{"id":1435},"what-a-minimal-replacement-actually-looks-like","What a minimal replacement actually looks like",[11,1438,1439,1440,1442],{},"Here's the part that surprises people: the answer is almost never \"an ERP\". Big off-the-shelf suites solve a thousand generic problems adequately; your load-bearing spreadsheet solves one specific problem precisely, in the exact shape of your business. Replacing it with a system that forces your process into someone else's template frequently makes things worse — and that's how you end up with the ERP ",[63,1441,901],{}," the spreadsheet.",[11,1444,1445],{},"The minimal honest replacement for most load-bearing spreadsheets is a small web application sitting on a proper database. Concretely:",[988,1447,1448,1454,1460,1466,1472],{},[188,1449,1450,1453],{},[29,1451,1452],{},"A database"," as the single source of truth. One record per thing, no competing copies, structured so a quantity can't accidentally become a date. This is the core of any Excel-to-database move, and it's where most of the value lives.",[188,1455,1456,1459],{},[29,1457,1458],{},"A handful of screens"," for entering, finding and editing data — with validation, so the nonsense gets rejected at the door instead of discovered at month-end.",[188,1461,1462,1465],{},[29,1463,1464],{},"The calculations"," moved out of cells into tested code, where they run the same way every time and a change is deliberate, reviewed and recorded.",[188,1467,1468,1471],{},[29,1469,1470],{},"Permissions and history."," Who can see what, who can change what, and a log of every change. The audit trail you currently don't have, by default rather than by heroics.",[188,1473,1474,1477,1478,1481],{},[29,1475,1476],{},"Exports back to Excel",", because spreadsheets remain a superb way to ",[63,1479,1480],{},"explore"," data. You're removing them from the trust-critical path, not banishing them.",[11,1483,1484],{},"Imagine a hypothetical testing lab that tracks samples in a giant workbook: intake on one tab, results on another, certificates generated by mail-merge, statuses copy-pasted between them. The minimal replacement is a sample register with a database behind it: book samples in, record results against them, generate certificates from live data, see status at a glance. Perhaps five screens. Not a laboratory information management platform with a six-month configuration project — a small, boring, correct system.",[11,1486,1487,1488,1491,1492,1494],{},"This kind of tightly-scoped build is the bulk of what ",[15,1489,1490],{"href":964},"bespoke web application development"," actually is in practice, and where it borders on ",[15,1493,1056],{"href":1055}," when the workbook is old enough to have its own folklore. The craft is in scope discipline: building exactly the system the spreadsheet was pretending to be, and nothing more. Our bias here is structural — we're wired to trace how data genuinely flows through a business end to end, which is precisely the skill spreadsheet sprawl punishes you for lacking. The spreadsheet itself is a gift in this process: it's a complete, battle-tested specification of your real rules, including the weird edge cases, written by the people who live them.",[21,1496,1498],{"id":1497},"build-vs-buy-honestly","Build vs buy, honestly",[11,1500,1501],{},"We build custom software for a living, so treat this with appropriate scepticism — but the honest answer is that you should check for an off-the-shelf product first.",[11,1503,1504,1507],{},[29,1505,1506],{},"Buy when"," your process is genuinely standard. Accounting, payroll, basic CRM, appointment booking, helpdesk: these are solved problems with mature products, and competing with Xero on bookkeeping would be silly. If 90% of an existing tool fits and you can adjust your process to cover the rest, buy it.",[11,1509,1510,1513,1514,1517],{},[29,1511,1512],{},"Build when"," the spreadsheet encodes something specific to how ",[63,1515,1516],{},"you"," operate — your pricing logic, your compliance workflow, your scheduling constraints, the thing that's actually your edge. Forcing that into a generic product means either losing the specificity (bad) or bolting spreadsheets back on around the product to cover the gaps (worse, and extremely common).",[11,1519,1520,1523],{},[29,1521,1522],{},"Watch the trap in the middle:"," a cheap-looking SaaS subscription that fits 70%, where the missing 30% is the part that mattered. Per-user pricing also compounds quietly; a custom system you own can be cheaper over five years than a subscription that scales with headcount. Run the numbers over five years, not one.",[21,1525,1527],{"id":1526},"when-to-stay-on-spreadsheets","When to stay on spreadsheets",[11,1529,1530],{},"Plenty of spreadsheets should remain exactly where they are. Keep the spreadsheet when:",[988,1532,1533,1542,1548,1558,1564],{},[188,1534,1535,1538,1539,828],{},[29,1536,1537],{},"It's analysis, not operations."," One-off modelling, scenario planning, exploring an export — this is what spreadsheets are ",[63,1540,1541],{},"for",[188,1543,1544,1547],{},[29,1545,1546],{},"One careful person owns it end to end"," and nobody else writes to it.",[188,1549,1550,1553,1554,1557],{},[29,1551,1552],{},"It's genuinely temporary",", or the process it supports might not exist next year. Don't build software for a process that hasn't stabilised; the spreadsheet ",[63,1555,1556],{},"is"," the prototype, and a good one.",[188,1559,1560,1563],{},[29,1561,1562],{},"Being wrong is cheap."," The lunch rota does not need an audit trail.",[188,1565,1566,1569],{},[29,1567,1568],{},"The volume is small and will stay small."," A 200-row list updated monthly has no scaling wall to hit.",[11,1571,1572],{},"The test isn't \"is it a spreadsheet?\" — it's \"is it shared, operational, and expensive to get wrong?\" Score yes on all three and it deserves to be real software. Score no, and the most expensive thing you could do is replace something that was working fine.",[21,1574,1576],{"id":1575},"a-sensible-first-step","A sensible first step",[11,1578,1579],{},"If one workbook in your business made you wince while reading this, the next step isn't a big project — it's a conversation about that one workbook: what it really does, what breaks when it's wrong, and what the smallest credible replacement looks like. Sometimes the honest answer is \"leave it alone\", and we'll tell you so.",[11,1581,1582,1583,1585,1586,1588,1589,828],{},"We're a ",[15,1584,231],{"href":230}," and happy to have that conversation with no obligation attached — email us at ",[15,1587,236],{"href":235}," or get in touch via our ",[15,1590,241],{"href":240},{"title":244,"searchDepth":245,"depth":245,"links":1592},[1593,1599,1600,1601,1602,1603],{"id":1347,"depth":245,"text":1348,"children":1594},[1595,1596,1597,1598],{"id":1354,"depth":250,"text":1355},{"id":1369,"depth":250,"text":1370},{"id":1376,"depth":250,"text":1377},{"id":1391,"depth":250,"text":1392},{"id":1401,"depth":245,"text":1402},{"id":1435,"depth":245,"text":1436},{"id":1497,"depth":245,"text":1498},{"id":1526,"depth":245,"text":1527},{"id":1575,"depth":245,"text":1576},"Spreadsheet sprawl has real costs: silent errors, key-person risk, no audit trail. When (and when not) to replace Excel with custom software.",{},"\u002Fblog\u002Freplace-spreadsheets-custom-software",{"title":1336,"description":1604},"blog\u002Freplace-spreadsheets-custom-software",[1610,1611,1612],"web-applications","business-systems","spreadsheets","XDoQLxVARatqGdP0j9e54C4K_Brd-exPYN146S5KNpk",{"id":1615,"title":1616,"body":1617,"datePublished":260,"description":1820,"extension":262,"meta":1821,"navigation":264,"path":1822,"seo":1823,"stem":1824,"tags":1825,"updatedAt":260,"__hash__":1828},"blog\u002Fblog\u002Fsoftware-for-biotech-spinouts-cambridge.md","From lab to product: software for biotech and research spinouts",{"type":8,"value":1618,"toc":1807},[1619,1622,1626,1629,1632,1658,1665,1669,1672,1676,1685,1689,1692,1696,1702,1706,1709,1713,1716,1722,1732,1742,1746,1749,1752,1756,1759,1791,1797,1799],[11,1620,1621],{},"Cambridge produces world-class science and, with remarkable consistency, software that nearly sinks it. Not because researchers write bad code — they write code that does exactly what a paper or a grant deliverable needed it to do. The trouble starts when a spinout forms around that science and the Jupyter notebook that generated Figure 3 quietly becomes the company's core product. We build software for biotech companies and research spinouts, and this post is about the gap between those two worlds: what it actually looks like, what most early-stage science companies genuinely need, and how to get it built without spending your runway on the wrong things.",[21,1623,1625],{"id":1624},"research-code-and-product-software-are-different-artefacts","Research code and product software are different artefacts",[11,1627,1628],{},"Research code is optimised for one thing: getting a result the author trusts. It lives in notebooks and scripts, it assumes the author's machine, the author's folder layout, and the author's memory of which cell to run first. It is usually maintained by whoever wrote it — often a postdoc — and when that person moves on, the knowledge moves with them.",[11,1630,1631],{},"None of that is a criticism. It is the correct trade-off for research. But product software has different jobs: it must run reliably for people who didn't write it, on machines the author never touched, with data the author never saw, and it must keep doing so after the team changes. The gap between the two is not \"tidying up the code\". It is usually:",[988,1633,1634,1640,1646,1652],{},[188,1635,1636,1639],{},[29,1637,1638],{},"Implicit knowledge made explicit."," The magic constants, the \"always discard the first three readings\", the manual step where someone renames files before the script runs. Product software has to encode all of it.",[188,1641,1642,1645],{},[29,1643,1644],{},"Failure handling."," Research code can crash and be re-run. A system capturing live instrument data cannot lose a run because a serial cable was unplugged for four seconds.",[188,1647,1648,1651],{},[29,1649,1650],{},"Identity and audit."," Who ran this, on which sample, with which protocol version? A notebook doesn't care. An investor's technical due diligence team, a regulator, or a future you absolutely will.",[188,1653,1654,1657],{},[29,1655,1656],{},"Versioned environments."," \"It works on the lab Mac\" is not a deployment strategy.",[11,1659,1660,1661,1664],{},"The honest answer is that most research code shouldn't be ported — it should be treated as a ",[63,1662,1663],{},"specification",". It tells you precisely what the science requires, which is enormously valuable. The product gets rebuilt around that, usually smaller and simpler than people expect, because a lot of research code is scaffolding for experiments the company no longer needs to run.",[21,1666,1668],{"id":1667},"what-spinouts-actually-need-its-usually-one-of-four-things","What spinouts actually need (it's usually one of four things)",[11,1670,1671],{},"Across instrument companies, assay developers and research-tools businesses, the same needs recur. If you're a founder wondering what \"getting the software sorted\" means, it's almost always some combination of these.",[34,1673,1675],{"id":1674},"instrument-integration-and-data-capture","Instrument integration and data capture",[11,1677,1678,1679,1681,1682,1684],{},"Instruments speak serial protocols, vendor SDKs, undocumented USB interfaces, or — depressingly often — they export CSVs to a shared drive and that ",[63,1680,1556],{}," the integration. Getting data off instruments automatically, with timestamps, device identity and run metadata attached at the point of capture, is the single highest-leverage piece of software most lab-based companies can buy. It removes transcription errors, it makes every downstream system more trustworthy, and it's the foundation everything else sits on. This work sits right on the hardware–software boundary, which is why our ",[15,1683,751],{"href":750}," capability gets used so heavily by science clients: half the job is firmware-adjacent, not web development.",[34,1686,1688],{"id":1687},"sample-and-experiment-tracking-when-a-lims-is-too-heavy","Sample and experiment tracking when a LIMS is too heavy",[11,1690,1691],{},"Commercial LIMS platforms are built for established labs with stable processes. An eight-person spinout iterating on its protocol weekly will fight a heavyweight LIMS constantly — and pay enterprise licensing for the privilege. What early teams usually need is far smaller: barcoded samples, a record of what was done to each one and when, links to the resulting data files, and search that works. That's a focused web application, not a six-month LIMS deployment. The trick is building it so it can grow into (or hand over to) a proper LIMS later, rather than becoming the next thing that has to be thrown away.",[34,1693,1695],{"id":1694},"data-pipelines-with-provenance","Data pipelines with provenance",[11,1697,1698,1699,1701],{},"When your dataset becomes your moat — and for many research-tools companies it does — provenance stops being academic hygiene and becomes commercial necessity. Every processed result should trace back to raw files, instrument, operator, protocol version and pipeline version. Done early, this is cheap: it's mostly discipline plus a modest amount of plumbing. Retrofitted after two years of \"results_final_v3_USE_THIS.xlsx\", it's archaeology. Provenance is also the unglamorous prerequisite for anything involving machine learning: if you want models trained on your data, or LLM-assisted analysis over your experiment history, the lineage has to exist first. We cover that boundary in our ",[15,1700,18],{"href":17}," work, and our consistent advice is the unfashionable bit comes before the fashionable bit.",[34,1703,1705],{"id":1704},"dashboards-for-people-who-dont-open-notebooks","Dashboards for people who don't open notebooks",[11,1707,1708],{},"Your investors, your commercial lead and your collaborators at a partner organisation should not need a Python environment to know how the science is going. A dashboard showing runs completed, yield trends, QC pass rates — fed automatically from the systems above — changes the texture of board meetings and partner calls. It's often the most visible return on the whole effort, even though it's technically the simplest layer.",[21,1710,1712],{"id":1711},"the-spinout-reality-budgets-regulation-ip","The spinout reality: budgets, regulation, IP",[11,1714,1715],{},"Generic software advice tends to ignore the constraints that actually shape decisions at a science company.",[11,1717,1718,1721],{},[29,1719,1720],{},"Grant-shaped money."," Budgets often arrive as Innovate UK milestones or tranche-gated investment, with deliverables and deadlines attached. Software work needs to be scoped to match: discrete phases with demonstrable outputs, not an open-ended retainer. A good partner will structure engagements around your funding reality rather than pretending it doesn't exist.",[11,1723,1724,1727,1728,1731],{},[29,1725,1726],{},"Regulatory awareness without GxP overkill."," If you're heading towards diagnostics or therapeutics, GxP, 21 CFR Part 11 and friends are in your future. They are mostly not in your present. The mistake we see in both directions: teams that ignore regulation entirely and build systems that can never be validated, and teams that gold-plate an MVP to full compliance standards and burn a year doing it. The pragmatic middle is building with a ",[63,1729,1730],{},"validation-ready posture"," — audit trails, access control, immutable raw data, documented data flows — while deferring the formal validation effort until the product and the regulatory pathway are actually settled. That posture costs perhaps ten per cent more at MVP stage and saves multiples of that later.",[11,1733,1734,1737,1738,1741],{},[29,1735,1736],{},"IP sensitivity."," Your protocol, your training data and your assay design may be the entire company. That has practical software consequences: be deliberate about what goes into third-party SaaS, what leaves the building (or the country), and what terms your software partner signs. We work under NDA as a matter of course and we're comfortable with arrangements where the sensitive science stays compartmentalised — we need to understand your data's ",[63,1739,1740],{},"shape",", not necessarily its secrets.",[21,1743,1745],{"id":1744},"why-hardware-and-software-capability-matters","Why hardware-and-software capability matters",[11,1747,1748],{},"If your product touches an instrument — yours or someone else's — a web-only development shop will struggle at exactly the point where your problems are hardest. Instrument-adjacent work means reading vendor protocol documents of varying honesty, debugging timing issues with a logic analyser rather than a browser console, handling devices that disconnect mid-run, and designing software that degrades gracefully when hardware misbehaves — because hardware always, eventually, misbehaves.",[11,1750,1751],{},"This is where the way we work is a genuine advantage rather than a slogan. We're an AuDHD-founded company and we build differently: hyperfocus means when we take on your instrument's undocumented serial behaviour, we are fully inside that problem until it yields. Pattern recognition built across embedded systems, cloud platforms and data engineering means we spot the architecture where the firmware, the capture service and the analysis pipeline fit together cleanly — instead of three teams building three things that meet badly in the middle. And systems thinking end to end means nobody has to be the integrator of last resort: that's the job we take on.",[21,1753,1755],{"id":1754},"engaging-a-software-partner-without-burning-runway","Engaging a software partner without burning runway",[11,1757,1758],{},"A few honest recommendations, including ones that cost us work:",[185,1760,1761,1767,1773,1779,1785],{},[188,1762,1763,1766],{},[29,1764,1765],{},"Start with a short, paid discovery."," One to two weeks. Output: a map of your data flows, the riskiest technical unknowns, and a phased plan with costs. If a partner won't show you their thinking before asking for a six-month commitment, walk away.",[188,1768,1769,1772],{},[29,1770,1771],{},"Build the smallest system that removes your worst manual step."," Not the platform. Not the vision. The one thing that's costing you hours or corrupting data every week. Prove the partnership on that.",[188,1774,1775,1778],{},[29,1776,1777],{},"Insist on owning everything."," Your repositories, your cloud accounts, your documentation. Any arrangement where the supplier holds the keys is a future hostage negotiation.",[188,1780,1781,1784],{},[29,1782,1783],{},"Don't hire a full-time software team too early."," A founding-stage science company rarely has enough sustained software work to keep good engineers engaged, and the hiring itself eats months. A partner who can flex up for a build phase and down to maintenance is usually better economics until the product demands otherwise — at which point a good partner helps you hire and hands over cleanly.",[188,1786,1787,1790],{},[29,1788,1789],{},"Ask hypothetical-you questions."," Imagine a lab whose lead developer — the postdoc who wrote everything — leaves in three months. Could anyone else run the system? If a proposal doesn't make the answer \"yes\", it isn't a product proposal.",[11,1792,1793,1794,1796],{},"Being genuinely local matters more in this niche than most. Instrument work means being physically in the lab; data-sensitivity conversations go better across a table. If you want the broader picture of how we work with companies here, see our page on ",[15,1795,400],{"href":230}," — research software development in Cambridge is, unapologetically, the work we set this company up to do.",[21,1798,224],{"id":223},[11,1800,1801,1802,411,1804,1806],{},"If you're a spinout staring at a folder of scripts and wondering how it becomes a product — or a research-tools company whose lab data management is held together by naming conventions — we're happy to have a no-obligation conversation about it. Email ",[15,1803,236],{"href":235},[15,1805,241],{"href":240},". Worst case, you leave with a clearer map of the problem.",{"title":244,"searchDepth":245,"depth":245,"links":1808},[1809,1810,1816,1817,1818,1819],{"id":1624,"depth":245,"text":1625},{"id":1667,"depth":245,"text":1668,"children":1811},[1812,1813,1814,1815],{"id":1674,"depth":250,"text":1675},{"id":1687,"depth":250,"text":1688},{"id":1694,"depth":250,"text":1695},{"id":1704,"depth":250,"text":1705},{"id":1711,"depth":245,"text":1712},{"id":1744,"depth":245,"text":1745},{"id":1754,"depth":245,"text":1755},{"id":223,"depth":245,"text":224},"How biotech spinouts turn research code into product software — instrument integration, lab data management and provenance, without burning runway.",{},"\u002Fblog\u002Fsoftware-for-biotech-spinouts-cambridge",{"title":1616,"description":1820},"blog\u002Fsoftware-for-biotech-spinouts-cambridge",[1826,1827,613],"biotech","research","0ZR_uYK9np0_xSmtEmto457iUzNQ0z63Kq-hysLQf08",1781193456504]