[{"data":1,"prerenderedAt":616},["ShallowReactive",2],{"home-posts":3},[4,273,440],{"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",1781193456019]