[{"data":1,"prerenderedAt":668},["ShallowReactive",2],{"hub-posts":3},[4,200,444],{"id":5,"title":6,"body":7,"datePublished":188,"description":189,"extension":190,"meta":191,"navigation":192,"path":193,"seo":194,"stem":195,"tags":196,"updatedAt":188,"__hash__":199},"blog\u002Fblog\u002Fchoose-software-development-partner-cambridge.md","Choose a Software Development Partner in Cambridge: 12 Questions",{"type":8,"value":9,"toc":166},"minimark",[10,14,19,22,25,29,34,42,46,49,53,56,60,63,67,70,74,77,81,84,88,97,101,104,108,111,115,118,122,125,129,132,135,138,141,149,153],[11,12,13],"p",{},"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.",[15,16,18],"h2",{"id":17},"why-questions-beat-portfolios","Why questions beat portfolios",[11,20,21],{},"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,23,24],{},"Ask every vendor the same questions, in writing where you can, and keep the answers. Ambiguity at the sales stage never improves later.",[15,26,28],{"id":27},"the-12-questions","The 12 questions",[30,31,33],"h3",{"id":32},"_1-who-will-actually-write-my-code","1. Who will actually write my code?",[11,35,36,37,41],{},"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 ",[38,39,40],"em",{},"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.",[30,43,45],{"id":44},"_2-how-do-you-estimate-and-when-were-you-last-wrong","2. How do you estimate, and when were you last wrong?",[11,47,48],{},"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.",[30,50,52],{"id":51},"_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,54,55],{},"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.",[30,57,59],{"id":58},"_4-what-happens-when-i-change-my-mind-mid-project","4. What happens when I change my mind mid-project?",[11,61,62],{},"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.",[30,64,66],{"id":65},"_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,68,69],{},"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.",[30,71,73],{"id":72},"_6-what-happens-after-launch","6. What happens after launch?",[11,75,76],{},"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.",[30,78,80],{"id":79},"_7-when-did-you-last-turn-down-work-and-why","7. When did you last turn down work, and why?",[11,82,83],{},"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.",[30,85,87],{"id":86},"_8-do-you-understand-my-domain-or-just-your-stack","8. Do you understand my domain, or just your stack?",[11,89,90,91,96],{},"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 ",[92,93,95],"a",{"href":94},"\u002Fsoftware-development-cambridge","software development in Cambridge"," specifically.",[30,98,100],{"id":99},"_9-who-do-i-actually-talk-to-during-the-build","9. Who do I actually talk to during the build?",[11,102,103],{},"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.",[30,105,107],{"id":106},"_10-what-does-done-mean-to-you","10. What does \"done\" mean to you?",[11,109,110],{},"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?",[30,112,114],{"id":113},"_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,116,117],{},"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.",[30,119,121],{"id":120},"_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,123,124],{},"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.",[15,126,128],{"id":127},"small-studio-or-large-agency-the-honest-trade-offs","Small studio or large agency? The honest trade-offs",[11,130,131],{},"Neither is better in general; they're better at different jobs.",[11,133,134],{},"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,136,137],{},"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,139,140],{},"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,142,143,144,148],{},"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 ",[92,145,147],{"href":146},"\u002Fabout","about Overclock Minds"," page.",[15,150,152],{"id":151},"take-the-list-with-you","Take the list with you",[11,154,155,156,160,161,165],{},"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 ",[92,157,159],{"href":158},"mailto:hello@overclockminds.co.uk","hello@overclockminds.co.uk"," or use the ",[92,162,164],{"href":163},"\u002Fcontact","contact"," page. No discovery call required; a plain email describing your problem is a perfectly good place to start.",{"title":167,"searchDepth":168,"depth":168,"links":169},"",2,[170,171,186,187],{"id":17,"depth":168,"text":18},{"id":27,"depth":168,"text":28,"children":172},[173,175,176,177,178,179,180,181,182,183,184,185],{"id":32,"depth":174,"text":33},3,{"id":44,"depth":174,"text":45},{"id":51,"depth":174,"text":52},{"id":58,"depth":174,"text":59},{"id":65,"depth":174,"text":66},{"id":72,"depth":174,"text":73},{"id":79,"depth":174,"text":80},{"id":86,"depth":174,"text":87},{"id":99,"depth":174,"text":100},{"id":106,"depth":174,"text":107},{"id":113,"depth":174,"text":114},{"id":120,"depth":174,"text":121},{"id":127,"depth":168,"text":128},{"id":151,"depth":168,"text":152},"2026-06-11","An honest buyer's guide to choosing a software development partner in Cambridge — 12 questions to ask, and which answers should disqualify a vendor.","md",{},true,"\u002Fblog\u002Fchoose-software-development-partner-cambridge",{"title":6,"description":189},"blog\u002Fchoose-software-development-partner-cambridge",[197,198],"cambridge","buyers-guide","isJryy0lmIBhDXE0-UBom9RHVprDpVq0EmfFDfIKxYQ",{"id":201,"title":202,"body":203,"datePublished":188,"description":435,"extension":190,"meta":436,"navigation":192,"path":437,"seo":438,"stem":439,"tags":440,"updatedAt":188,"__hash__":443},"blog\u002Fblog\u002Fmvp-development-cambridge-startups.md","MVP development for Cambridge startups: what to build first",{"type":8,"value":204,"toc":422},[205,212,215,219,222,225,232,235,239,242,246,249,253,256,259,263,266,269,273,276,300,303,306,310,321,324,327,348,354,358,361,398,402,405,408,412],[11,206,207,208,211],{},"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 ",[38,209,210],{},"not"," to build.",[11,213,214],{},"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.",[15,216,218],{"id":217},"an-mvp-is-an-experiment-not-version-one","An MVP is an experiment, not version one",[11,220,221],{},"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,223,224],{},"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,226,227,228,231],{},"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: ",[38,229,230],{},"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,233,234],{},"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.",[15,236,238],{"id":237},"what-to-fake","What to fake",[11,240,241],{},"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:",[30,243,245],{"id":244},"admin-panels-use-a-spreadsheet","Admin panels: use a spreadsheet",[11,247,248],{},"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.",[30,250,252],{"id":251},"automation-do-it-by-hand-first","\"Automation\": do it by hand first",[11,254,255],{},"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,257,258],{},"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.",[30,260,262],{"id":261},"configurable-flows-hard-code-them","Configurable flows: hard-code them",[11,264,265],{},"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,267,268],{},"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).",[15,270,272],{"id":271},"what-must-be-real","What must be real",[11,274,275],{},"One thing cannot be faked: the thing your riskiest assumption is about.",[277,278,279,288,294],"ul",{},[280,281,282,283,287],"li",{},"If the risk is ",[284,285,286],"strong",{},"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.",[280,289,282,290,293],{},[284,291,292],{},"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.",[280,295,282,296,299],{},[284,297,298],{},"behavioural"," — will users actually change their workflow? — the workflow itself must be real and genuinely pleasant to use, and everything else stays minimal.",[11,301,302],{},"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,304,305],{},"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.",[15,307,309],{"id":308},"the-cambridge-problem-milestone-shaped-mvps","The Cambridge problem: milestone-shaped MVPs",[11,311,312,313,316,317,320],{},"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 ",[38,314,315],{},"looking finished",". Experiments reward ",[38,318,319],{},"finding the truth quickly",". Those pull in opposite directions, and the milestone usually wins.",[11,322,323],{},"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,325,326],{},"You can handle this without torching your funding:",[328,329,330,336,342],"ol",{},[280,331,332,335],{},[284,333,334],{},"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.",[280,337,338,341],{},[284,339,340],{},"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.",[280,343,344,347],{},[284,345,346],{},"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,349,350,351,353],{},"Navigating those funding-cycle pressures alongside the build is a large part of what our ",[92,352,95],{"href":94}," work involves, because the build and the milestones have to be planned together or one quietly eats the other.",[15,355,357],{"id":356},"tech-choices-that-keep-options-open","Tech choices that keep options open",[11,359,360],{},"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:",[277,362,363,369,375,381,392],{},[280,364,365,368],{},[284,366,367],{},"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.",[280,370,371,374],{},[284,372,373],{},"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.",[280,376,377,380],{},[284,378,379],{},"Buy, don't run."," Managed auth, managed email, managed payments, managed hosting. Your differentiation is the experiment, not your infrastructure.",[280,382,383,386,387,391],{},[284,384,385],{},"Web first, unless hardware or native genuinely demands otherwise."," Responsive ",[92,388,390],{"href":389},"\u002Fservices\u002Fweb-applications","web application development"," reaches every device from one codebase; native apps and app-store review cycles can wait until the experiment says yes.",[280,393,394,397],{},[284,395,396],{},"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.",[15,399,401],{"id":400},"budget-reality","Budget reality",[11,403,404],{},"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,406,407],{},"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.",[15,409,411],{"id":410},"where-to-start","Where to start",[11,413,414,415,417,418,421],{},"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 ",[92,416,159],{"href":158}," or ",[92,419,420],{"href":163},"get in touch",".",{"title":167,"searchDepth":168,"depth":168,"links":423},[424,425,430,431,432,433,434],{"id":217,"depth":168,"text":218},{"id":237,"depth":168,"text":238,"children":426},[427,428,429],{"id":244,"depth":174,"text":245},{"id":251,"depth":174,"text":252},{"id":261,"depth":174,"text":262},{"id":271,"depth":168,"text":272},{"id":308,"depth":168,"text":309},{"id":356,"depth":168,"text":357},{"id":400,"depth":168,"text":401},{"id":410,"depth":168,"text":411},"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":202,"description":435},"blog\u002Fmvp-development-cambridge-startups",[441,442,197],"startups","mvp","7zZGsX2z6J0SK1-ZNEJ8kVGyxLUsDZqZTS5isw5zojk",{"id":445,"title":446,"body":447,"datePublished":188,"description":659,"extension":190,"meta":660,"navigation":192,"path":661,"seo":662,"stem":663,"tags":664,"updatedAt":188,"__hash__":667},"blog\u002Fblog\u002Fsoftware-for-biotech-spinouts-cambridge.md","From lab to product: software for biotech and research spinouts",{"type":8,"value":448,"toc":646},[449,452,456,459,462,488,495,499,502,506,518,522,525,529,537,541,544,548,551,557,567,577,581,584,587,591,594,626,632,636],[11,450,451],{},"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.",[15,453,455],{"id":454},"research-code-and-product-software-are-different-artefacts","Research code and product software are different artefacts",[11,457,458],{},"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,460,461],{},"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:",[277,463,464,470,476,482],{},[280,465,466,469],{},[284,467,468],{},"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.",[280,471,472,475],{},[284,473,474],{},"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.",[280,477,478,481],{},[284,479,480],{},"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.",[280,483,484,487],{},[284,485,486],{},"Versioned environments."," \"It works on the lab Mac\" is not a deployment strategy.",[11,489,490,491,494],{},"The honest answer is that most research code shouldn't be ported — it should be treated as a ",[38,492,493],{},"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.",[15,496,498],{"id":497},"what-spinouts-actually-need-its-usually-one-of-four-things","What spinouts actually need (it's usually one of four things)",[11,500,501],{},"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.",[30,503,505],{"id":504},"instrument-integration-and-data-capture","Instrument integration and data capture",[11,507,508,509,512,513,517],{},"Instruments speak serial protocols, vendor SDKs, undocumented USB interfaces, or — depressingly often — they export CSVs to a shared drive and that ",[38,510,511],{},"is"," 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 ",[92,514,516],{"href":515},"\u002Fservices\u002Fembedded-hardware","embedded & hardware integration"," capability gets used so heavily by science clients: half the job is firmware-adjacent, not web development.",[30,519,521],{"id":520},"sample-and-experiment-tracking-when-a-lims-is-too-heavy","Sample and experiment tracking when a LIMS is too heavy",[11,523,524],{},"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.",[30,526,528],{"id":527},"data-pipelines-with-provenance","Data pipelines with provenance",[11,530,531,532,536],{},"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 ",[92,533,535],{"href":534},"\u002Fservices\u002Fai-ml","AI & LLM integration"," work, and our consistent advice is the unfashionable bit comes before the fashionable bit.",[30,538,540],{"id":539},"dashboards-for-people-who-dont-open-notebooks","Dashboards for people who don't open notebooks",[11,542,543],{},"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.",[15,545,547],{"id":546},"the-spinout-reality-budgets-regulation-ip","The spinout reality: budgets, regulation, IP",[11,549,550],{},"Generic software advice tends to ignore the constraints that actually shape decisions at a science company.",[11,552,553,556],{},[284,554,555],{},"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,558,559,562,563,566],{},[284,560,561],{},"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 ",[38,564,565],{},"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,568,569,572,573,576],{},[284,570,571],{},"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 ",[38,574,575],{},"shape",", not necessarily its secrets.",[15,578,580],{"id":579},"why-hardware-and-software-capability-matters","Why hardware-and-software capability matters",[11,582,583],{},"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,585,586],{},"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.",[15,588,590],{"id":589},"engaging-a-software-partner-without-burning-runway","Engaging a software partner without burning runway",[11,592,593],{},"A few honest recommendations, including ones that cost us work:",[328,595,596,602,608,614,620],{},[280,597,598,601],{},[284,599,600],{},"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.",[280,603,604,607],{},[284,605,606],{},"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.",[280,609,610,613],{},[284,611,612],{},"Insist on owning everything."," Your repositories, your cloud accounts, your documentation. Any arrangement where the supplier holds the keys is a future hostage negotiation.",[280,615,616,619],{},[284,617,618],{},"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.",[280,621,622,625],{},[284,623,624],{},"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,627,628,629,631],{},"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 ",[92,630,95],{"href":94}," — research software development in Cambridge is, unapologetically, the work we set this company up to do.",[15,633,635],{"id":634},"talk-to-us","Talk to us",[11,637,638,639,641,642,645],{},"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 ",[92,640,159],{"href":158}," or use our ",[92,643,644],{"href":163},"contact page",". Worst case, you leave with a clearer map of the problem.",{"title":167,"searchDepth":168,"depth":168,"links":647},[648,649,655,656,657,658],{"id":454,"depth":168,"text":455},{"id":497,"depth":168,"text":498,"children":650},[651,652,653,654],{"id":504,"depth":174,"text":505},{"id":520,"depth":174,"text":521},{"id":527,"depth":174,"text":528},{"id":539,"depth":174,"text":540},{"id":546,"depth":168,"text":547},{"id":579,"depth":168,"text":580},{"id":589,"depth":168,"text":590},{"id":634,"depth":168,"text":635},"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":446,"description":659},"blog\u002Fsoftware-for-biotech-spinouts-cambridge",[665,666,197],"biotech","research","0ZR_uYK9np0_xSmtEmto457iUzNQ0z63Kq-hysLQf08",1781193456504]