[{"data":1,"prerenderedAt":1524},["ShallowReactive",2],{"archive-2026":3,"categories":1485},[4,491,1130],{"date":5,"authorId":6,"category":7,"tags":8,"image":14,"readingTime":15,"published":16,"cluster":17,"post_type":18,"faq":19,"id":32,"title":33,"body":34,"description":484,"extension":485,"meta":486,"navigation":16,"path":487,"seo":488,"stem":489,"__hash__":490},"2026-10-12",2,"engineering",[9,10,11,12,13],"technical debt","developer productivity","engineering velocity","software architecture","startup founders","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1504639725590-34d0984388bd?w=1200&q=80",8,true,"Build to Scale","spoke",[20,23,26,29],{"question":21,"answer":22},"How much does technical debt actually cost a development team?","Estimates vary by company, but the best-known survey data is from Stripe's 2018 Developer Coefficient study: developers estimated they spend about 13.5 hours of a 41-hour working week on technical debt — roughly a third of their time — plus several more hours on bad code. The cost shows up as slower delivery, missed estimates and work that keeps getting re-opened, not as a line item in the budget.",{"question":24,"answer":25},"How do I know if technical debt is slowing my team down?","Look for patterns rather than single incidents: estimates that keep getting missed by multiples, small changes that require touching many files, bugs that return after being fixed, features scoped around what the system can do rather than what customers need, and upgrades or security patches that keep getting postponed. DORA's delivery metrics — change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate — turn those patterns into numbers you can track.",{"question":27,"answer":28},"Should we stop building features to pay down technical debt?","Rarely. A feature freeze or a full rewrite usually costs more than it saves. The approach that works is to pay debt down continuously and selectively: reserve a share of every cycle for it, and concentrate that effort on the parts of the codebase that change most often, because that is where the interest is highest.",{"question":30,"answer":31},"Is all technical debt bad?","No. Debt taken on deliberately — a known shortcut to hit a launch, with an understanding of what it will cost to fix — can be a sound business decision. The problem is debt nobody chose, nobody recorded and nobody is paying down. That kind of debt does not stay a code problem; it becomes a constraint on the product and the business.","content\u002Fblog\u002Fhidden-cost-of-technical-debt.md","The Hidden Cost of Technical Debt: Why a Three-Day Feature Takes Three Weeks",{"type":35,"value":36,"toc":472},"minimark",[37,41,44,47,50,55,58,64,67,70,77,81,84,96,99,106,109,113,116,119,153,156,160,163,170,177,184,187,191,194,238,242,245,255,287,290,302,312,316,319,322,325,358,362,365,382,385,389,463],[38,39,40],"p",{},"Your team estimated three days. It took three weeks. Nobody was lazy, nobody was incompetent, and the post-mortem — if there was one — blamed \"unexpected complexity.\"",[38,42,43],{},"Then it happened again on the next feature. And the one after that.",[38,45,46],{},"When delivery slows down without an obvious cause, the cause is very often technical debt. Not in the way most founders picture it — a few messy files a developer wants to tidy up — but as something more expensive: a growth constraint that quietly consumes a large share of your engineering capacity and, if nobody manages it, starts making technical decisions on your behalf.",[38,48,49],{},"This post is about seeing that cost clearly, measuring it, and paying it down without stopping the roadmap.",[51,52,54],"h2",{"id":53},"what-technical-debt-actually-is","What technical debt actually is",[38,56,57],{},"Ward Cunningham introduced the term in 1992, in an experience report about a financial software product called WyCash. His framing was deliberately financial:",[59,60,61],"blockquote",{},[38,62,63],{},"\"Shipping first time code is like going into debt.\"",[38,65,66],{},"The metaphor works because of what comes next. Cunningham continued: \"Every minute spent on not-quite-right code counts as interest on that debt\" — and \"the danger occurs when the debt is not repaid.\"",[38,68,69],{},"Martin Fowler sharpened the idea of interest: \"The extra effort that it takes to add new features is the interest paid on the debt.\" He also pointed out where the metaphor breaks down, and it matters for founders. Financial interest accrues with time. Technical interest is only paid when someone works in the affected part of the system. Debt in a corner of the product nobody touches costs almost nothing. Debt in the code every new feature passes through is charged on every single feature you build.",[38,71,72,73],{},"That is the first thing to understand about the hidden cost: ",[74,75,76],"strong",{},"it is concentrated exactly where your roadmap is.",[51,78,80],{"id":79},"the-hidden-metric-how-much-capacity-debt-consumes","The hidden metric: how much capacity debt consumes",[38,82,83],{},"Technical debt rarely appears on a dashboard, which is why it is so easy to underestimate. But it has been measured.",[38,85,86,87,91,92,95],{},"In Stripe's ",[88,89,90],"em",{},"Developer Coefficient"," study, published in September 2018 and conducted with Harris Poll among more than 1,000 developers and more than 1,000 C-level executives, developers estimated that they spend an average of ",[74,93,94],{},"13.5 hours of a 41.1-hour working week on technical debt"," — roughly a third of their time — and another 3.8 hours on bad code.",[38,97,98],{},"Treat that as a survey estimate, not a law of nature; your team's number may be lower or considerably higher. But the order of magnitude is the point. If anything close to a third of your engineering capacity goes to working around past decisions, then a team of six is effectively shipping like a team of four — and you are paying for six.",[38,100,101,102,105],{},"Fowler makes a related point about how quickly this sets in. In ",[88,103,104],{},"Is High Quality Software Worth the Cost?"," (2019), he writes that \"developers find poor quality code significantly slows them down within a few weeks.\" This is not a problem that waits years to show up. It starts compounding almost as soon as the shortcuts are taken.",[38,107,108],{},"The reason it stays hidden is simple: as Fowler notes, \"customers and users cannot perceive the architecture of the software.\" Neither, usually, can founders. What you perceive is the symptom — the three-day feature that took three weeks — not the cause.",[51,110,112],{"id":111},"how-unmanaged-debt-makes-decisions-on-your-behalf","How unmanaged debt makes decisions on your behalf",[38,114,115],{},"The most expensive effect of technical debt is not the hours. It is the decisions it takes away from you.",[38,117,118],{},"When debt goes unmanaged long enough, the system starts answering questions that should be business decisions:",[120,121,122,129,135,141,147],"ul",{},[123,124,125,128],"li",{},[74,126,127],{},"Which features you can build."," A data model that cannot represent what your largest prospect needs means the answer to \"can we support multi-location accounts?\" is no longer a product decision. It is \"not without a rewrite.\"",[123,130,131,134],{},[74,132,133],{},"How fast you can respond."," If every change requires touching a dozen tightly coupled files, a competitor's two-week response to a market shift becomes your two-month response.",[123,136,137,140],{},[74,138,139],{},"Which technology you run on."," Frameworks and libraries reach end of life. If upgrading is too risky because nothing is covered by tests, you stay on the old version — and inherit its security vulnerabilities — not because anyone chose to, but because the debt chose for you.",[123,142,143,146],{},[74,144,145],{},"Who can work on the product."," Code that only one person understands turns that person into a bottleneck and a retention risk, and makes onboarding new engineers slow and expensive.",[123,148,149,152],{},[74,150,151],{},"What your estimates mean."," When every estimate carries an unknown amount of debt, planning stops being reliable, and the roadmap you present to your board or customers becomes a guess.",[38,154,155],{},"None of these show up as \"technical debt\" in a meeting. They show up as missed deadlines, lost deals, delayed launches and engineering hires that do not seem to increase output.",[51,157,159],{"id":158},"not-all-debt-is-bad","Not all debt is bad",[38,161,162],{},"Debt is not a moral failing, and a codebase with zero debt usually belongs to a product that shipped too late.",[38,164,165,166,169],{},"In 2009, Fowler classified technical debt along two axes — deliberate or inadvertent, prudent or reckless. ",[74,167,168],{},"Prudent, deliberate debt"," is a team knowingly taking a shortcut to hit a launch window, with an understanding of what it will cost to repay. That is a legitimate business decision, the same way taking a loan to fund growth is.",[38,171,172,173,176],{},"Even excellent teams also accumulate ",[74,174,175],{},"prudent, inadvertent debt",": once a product has been in front of real users for a while, the team learns what the design should have been. Fowler calls this kind of debt inevitable.",[38,178,179,180,183],{},"The dangerous kind is ",[74,181,182],{},"reckless"," debt — shortcuts taken without understanding their cost, or messes created because nobody knew better. Fowler's verdict on the latter is blunt: \"a mess is not a debt.\" It has no repayment plan. It just compounds.",[38,185,186],{},"The goal is not zero debt. The goal is debt that was chosen, recorded and is being paid down — instead of debt that is choosing for you.",[51,188,190],{"id":189},"symptoms-you-can-spot-without-reading-the-code","Symptoms you can spot without reading the code",[38,192,193],{},"You do not need to be technical to see the warning signs. Look for patterns, not single incidents:",[120,195,196,202,208,214,220,226,232],{},[123,197,198,201],{},[74,199,200],{},"Estimates are missed by multiples, not percentages."," Every team misses estimates. Consistently missing them by 3–5× suggests the system is fighting the team.",[123,203,204,207],{},[74,205,206],{},"Small changes have large blast radiuses."," A change to one feature breaks something apparently unrelated.",[123,209,210,213],{},[74,211,212],{},"Bugs come back."," Fixes do not stick, because the underlying structure keeps producing the same class of problem.",[123,215,216,219],{},[74,217,218],{},"\"We'd need to refactor that first\" is a common answer."," Occasionally, it is normal. As the default answer to new requests, it is a signal.",[123,221,222,225],{},[74,223,224],{},"Upgrades and security patches keep getting postponed."," This is debt accruing in its most dangerous form.",[123,227,228,231],{},[74,229,230],{},"Adding engineers does not increase output."," New people spend months learning the workarounds before they can contribute.",[123,233,234,237],{},[74,235,236],{},"Product decisions are framed around what the system allows."," \"We can't do it that way\" has replaced \"should we do it that way?\"",[51,239,241],{"id":240},"how-to-measure-it","How to measure it",[38,243,244],{},"What gets measured gets managed — and debt that is only felt, never measured, tends to get managed last.",[38,246,247,250,251,254],{},[74,248,249],{},"Track delivery performance."," DORA, the research programme behind the ",[88,252,253],{},"Accelerate State of DevOps"," reports, defines five software delivery metrics that make the cost of debt visible over time:",[120,256,257,263,269,275,281],{},[123,258,259,262],{},[74,260,261],{},"Change lead time"," — how long it takes a committed change to reach production.",[123,264,265,268],{},[74,266,267],{},"Deployment frequency"," — how often you deploy.",[123,270,271,274],{},[74,272,273],{},"Failed deployment recovery time"," — how long it takes to recover when a deployment fails.",[123,276,277,280],{},[74,278,279],{},"Change fail rate"," — the share of deployments that need immediate intervention, such as a rollback or hotfix.",[123,282,283,286],{},[74,284,285],{},"Deployment rework rate"," — the share of deployments that are unplanned and caused by a production incident.",[38,288,289],{},"Rising lead times and fail rates with a stable team are one of the clearest quantitative signals that debt is accumulating faster than it is being paid down.",[38,291,292,295,296,301],{},[74,293,294],{},"Build a debt inventory."," Ask the team to list known debt items, where they live, what they slow down and roughly what it would take to address each one. An inventory turns a vague complaint into a backlog that can be prioritised alongside features — and it is one of the first things we look for in a technical review, as covered in our ",[297,298,300],"a",{"href":299},"\u002Fblog\u002Ftechnical-due-diligence-checklist","technical due diligence checklist",".",[38,303,304,307,308,311],{},[74,305,306],{},"Find the hotspots."," Not all debt is equally expensive. In ",[88,309,310],{},"Your Code as a Crime Scene",", Adam Tornhill describes using version-control history to find development hotspots and prioritise technical debt — intersecting how complex a piece of code is with how often the team actually changes it. Complex code that nobody touches can wait. Complex code that changes every sprint is where the interest is being paid.",[51,313,315],{"id":314},"how-to-pay-it-down-without-stopping-the-roadmap","How to pay it down without stopping the roadmap",[38,317,318],{},"The instinct, once the cost becomes visible, is a dramatic fix: a feature freeze, or a rewrite from scratch. Both are usually the most expensive option available.",[38,320,321],{},"Joel Spolsky called rewriting from scratch \"the single worst strategic mistake that any software company can make,\" using Netscape as his example — a company whose last major release had shipped almost three years before he wrote his essay in 2000. As he put it, when you throw away working code, \"you are throwing away all that knowledge. All those collected bug fixes.\"",[38,323,324],{},"What works instead is continuous, targeted repayment:",[326,327,328,334,340,346,352],"ol",{},[123,329,330,333],{},[74,331,332],{},"Stop adding reckless debt."," Agree on a definition of done that includes tests for new code, code review, and no new shortcuts without a recorded reason and a plan to repay. This halts the compounding.",[123,335,336,339],{},[74,337,338],{},"Reserve capacity every cycle."," Treat debt repayment as a standing allocation in every sprint, not a project that competes with features once a year. The right share depends on how much debt you have; the important part is that it is consistent and protected.",[123,341,342,345],{},[74,343,344],{},"Spend that capacity on hotspots first."," Pay down debt where the team works most, because that is where each hour of repayment saves the most future hours.",[123,347,348,351],{},[74,349,350],{},"Refactor on the way through."," When a feature touches an area with known debt, include improving that area in the feature's scope. The roadmap keeps moving and the most-used code improves first.",[123,353,354,357],{},[74,355,356],{},"Track the metrics."," If lead time and fail rate improve over a few months, the repayment is working. If they do not, the debt is in places the plan is not reaching.",[51,359,361],{"id":360},"a-short-checklist-for-founders","A short checklist for founders",[38,363,364],{},"If your team's velocity has dropped without an obvious reason, these five questions will tell you a lot:",[120,366,367,370,373,376,379],{},[123,368,369],{},"Do we have a written inventory of known technical debt — and who owns it?",[123,371,372],{},"Do we track change lead time and change fail rate, and are they getting better or worse?",[123,374,375],{},"What share of each sprint is explicitly reserved for paying down debt?",[123,377,378],{},"Which parts of the codebase change most often, and how healthy are they?",[123,380,381],{},"Which business decisions in the last six months were shaped by \"the system can't do that\"?",[38,383,384],{},"If the honest answers are \"no,\" \"no,\" \"none,\" \"not sure\" and \"several,\" your technical debt is not a maintenance cost. It is a growth ceiling — and it is already making decisions for you.",[51,386,388],{"id":387},"sources","Sources",[120,390,391,401,416,424,435,443,454],{},[123,392,393,394,400],{},"Ward Cunningham, ",[297,395,399],{"href":396,"rel":397},"http:\u002F\u002Fc2.com\u002Fdoc\u002Foopsla92.html",[398],"nofollow","\"The WyCash Portfolio Management System\"",", OOPSLA 1992 experience report",[123,402,403,404,409,410,415],{},"Martin Fowler, ",[297,405,408],{"href":406,"rel":407},"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebt.html",[398],"\"Technical Debt\""," and ",[297,411,414],{"href":412,"rel":413},"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebtQuadrant.html",[398],"\"Technical Debt Quadrant\""," (2009)",[123,417,403,418,423],{},[297,419,422],{"href":420,"rel":421},"https:\u002F\u002Fmartinfowler.com\u002Farticles\u002Fis-quality-worth-cost.html",[398],"\"Is High Quality Software Worth the Cost?\"",", 2019",[123,425,426,427,434],{},"Stripe, ",[297,428,431],{"href":429,"rel":430},"https:\u002F\u002Fstripe.com\u002Ffiles\u002Freports\u002Fthe-developer-coefficient.pdf",[398],[88,432,433],{},"The Developer Coefficient",", September 2018",[123,436,437,438],{},"DORA, ",[297,439,442],{"href":440,"rel":441},"https:\u002F\u002Fdora.dev\u002Fguides\u002Fdora-metrics\u002F",[398],"Software delivery performance metrics guide",[123,444,445,446,453],{},"Adam Tornhill, ",[297,447,450,452],{"href":448,"rel":449},"https:\u002F\u002Fpragprog.com\u002Ftitles\u002Fatcrime2\u002Fyour-code-as-a-crime-scene-second-edition\u002F",[398],[88,451,310],{},", Second Edition",", Pragmatic Bookshelf, 2024",[123,455,456,457,462],{},"Joel Spolsky, ",[297,458,461],{"href":459,"rel":460},"https:\u002F\u002Fwww.joelonsoftware.com\u002F2000\u002F04\u002F06\u002Fthings-you-should-never-do-part-i\u002F",[398],"\"Things You Should Never Do, Part I\"",", 2000",[38,464,465],{},[88,466,467,468],{},"business2point helps founders turn technical debt from a hidden constraint into a managed backlog — senior, CTO-level assessment of where the debt is, what it costs and what to pay down first. ",[297,469,471],{"href":470},"\u002F#contact","Start the conversation →",{"title":473,"searchDepth":6,"depth":6,"links":474},"",[475,476,477,478,479,480,481,482,483],{"id":53,"depth":6,"text":54},{"id":79,"depth":6,"text":80},{"id":111,"depth":6,"text":112},{"id":158,"depth":6,"text":159},{"id":189,"depth":6,"text":190},{"id":240,"depth":6,"text":241},{"id":314,"depth":6,"text":315},{"id":360,"depth":6,"text":361},{"id":387,"depth":6,"text":388},"Technical debt isn't messy code — it's a growth constraint that quietly consumes a large share of your engineering capacity and starts making technical decisions for you. Here is how to recognise it, measure it and pay it down without stopping the roadmap.","md",{"date":5,"authorId":6,"category":7,"tags":8,"image":14,"readingTime":15,"published":16,"cluster":17,"post_type":18,"faq":19},"\u002Fblog\u002Fhidden-cost-of-technical-debt",{"title":33,"description":484},"blog\u002Fhidden-cost-of-technical-debt","1wlpnGPlAUQZ2AKrtr2ZzhBJPl-eB0rzHsB4W7gISqE",{"date":492,"authorId":6,"category":7,"tags":493,"image":496,"readingTime":497,"published":16,"cluster":17,"post_type":18,"faq":498,"id":511,"title":512,"body":513,"description":1124,"extension":485,"meta":1125,"navigation":16,"path":1126,"seo":1127,"stem":1128,"__hash__":1129},"2026-10-07",[494,495,9,12,13],"mvp development","scalable architecture","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1531403009284-440f080d1e12?w=1200&q=80",14,[499,502,505,508],{"question":500,"answer":501},"Should an MVP be built to scale?","An MVP should not be built for scale it does not have yet — no microservices, no multi-region infrastructure, no premature optimisation. But it should be built so that scaling is possible without starting over. That means a sound data model, a deliberate API contract, proper authentication and access control, and stateless application servers. Those decisions cost little on day one and are very expensive to change later.",{"question":503,"answer":504},"What can you safely cut from an MVP?","Anything that is cheap to add or change later: secondary features, visual polish, admin tooling, most third-party integrations, and infrastructure built for load you do not have. The test is reversibility. If a decision can be changed with an ordinary code change, it is a safe cut.",{"question":506,"answer":507},"What should never be cut from an MVP?","The decisions that are expensive to reverse once real users and real data exist: the database schema and core data model, the API contract that clients depend on, authentication and authorisation, and the basic operational foundations — automated deployments, migrations in version control, error tracking, and tested backups.",{"question":509,"answer":510},"Is it better to rewrite an MVP or refactor it?","In most cases, refactor. A full rewrite discards the bug fixes and edge-case knowledge accumulated in production and freezes product progress while the new system catches up. Rewrites become unavoidable when the foundations — usually the data model, tenancy or security model — cannot support the business. That is exactly why those foundations are the part of an MVP you should not cut.","content\u002Fblog\u002Fmvp-vs-scalable-architecture-what-to-cut-what-to-keep.md","MVP vs. Scalable Architecture: What to Cut and What to Keep",{"type":35,"value":514,"toc":1102},[515,525,528,531,535,538,543,550,553,556,561,565,568,571,578,584,587,591,598,603,609,612,619,623,628,631,634,638,643,646,649,653,658,661,668,675,679,684,687,691,694,698,703,706,709,756,760,765,768,770,806,810,815,818,829,831,857,861,866,869,901,904,908,911,914,920,927,930,934,937,940,954,961,965,968,994,1000,1002,1095],[38,516,517,518,521,522,301],{},"An MVP gives you permission to build ",[74,519,520],{},"narrowly",". It does not give you permission to build ",[74,523,524],{},"badly",[38,526,527],{},"Those two ideas get confused constantly — and the confusion is expensive. Founders hear \"minimum viable product\" and conclude that everything about the first version should be minimal: minimal features, minimal design, minimal engineering. The first two are often right. The third is how a startup ends up with a product that works for its first few hundred users and then needs to be rebuilt at the exact moment it has traction, funding pressure, and no time to stop.",[38,529,530],{},"This post is about drawing that line precisely: which corners are safe to cut in your first version, and which architecture decisions you need to get right before the first real user signs up.",[51,532,534],{"id":533},"what-an-mvp-is-actually-for","What an MVP is actually for",[38,536,537],{},"The term \"minimum viable product\" was coined by Frank Robinson in 2001 and popularised by Steve Blank and Eric Ries. Ries's definition, from 2009, is the one most founders work from:",[59,539,540],{},[38,541,542],{},"\"The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.\"",[38,544,545,546,549],{},"Notice what the definition optimises for: ",[74,547,548],{},"learning",", not cheapness. Ries is explicit about this in the same piece — \"MVP, despite the name, is not about creating minimal products.\"",[38,551,552],{},"The learning an MVP is meant to produce is overwhelmingly about the market. CB Insights' March 2026 analysis of 431 VC-backed startups that shut down since 2023 found poor product-market fit cited in 43% of the closures where the reasons could be identified. Running out of capital was cited even more often (70%), but as CB Insights points out, that is usually how a startup dies rather than why. The risk an MVP exists to retire is \"will anyone want this?\" — not \"can our database handle a million rows?\"",[38,554,555],{},"That gives you the first principle of MVP scoping:",[38,557,558],{},[74,559,560],{},"Cut aggressively wherever the cut only delays learning about the market. Do not cut where the cut creates a cost you will pay after the market has said yes.",[51,562,564],{"id":563},"two-kinds-of-shortcuts-prudent-debt-and-reckless-debt","Two kinds of shortcuts: prudent debt and reckless debt",[38,566,567],{},"Ward Cunningham introduced the technical debt metaphor at the OOPSLA conference in 1992. The idea is simple: a shortcut in the code is like borrowing money. You ship sooner, but you pay interest every time you work in that part of the system afterwards. Martin Fowler describes the interest precisely: \"The extra effort that it takes to add new features is the interest paid on the debt.\"",[38,569,570],{},"Fowler also points out where the metaphor diverges from real debt, and it matters for MVPs: you only pay the interest when you touch the code. A messy admin screen that nobody changes costs you almost nothing. A messy data model that every feature depends on charges interest on every single feature you build.",[38,572,573,574,577],{},"In 2009, Fowler classified technical debt along two axes: deliberate vs. inadvertent, and prudent vs. reckless. The quadrant that matters here is ",[74,575,576],{},"prudent and deliberate"," debt — a team knowingly taking a shortcut to ship sooner, with an understanding of what it will cost to repay. That is what a well-run MVP is made of.",[38,579,580,581,583],{},"The trap is ",[74,582,182],{}," debt: shortcuts taken without understanding their cost, or messes created because nobody knew better. Fowler is blunt about the latter: \"a mess is not a debt.\" It does not have a repayment plan. It just compounds.",[38,585,586],{},"The rest of this post is a practical sorting of MVP shortcuts into those two buckets.",[51,588,590],{"id":589},"what-to-cut","What to cut",[38,592,593,594,597],{},"The test for every item below is the same: ",[74,595,596],{},"if you get it wrong or leave it out, can you fix it later with an ordinary code change?"," If yes, it is a safe cut.",[599,600,602],"h3",{"id":601},"_1-feature-scope","1. Feature scope",[38,604,605,608],{},[74,606,607],{},"The core question:"," What is the one workflow that proves the product is worth paying for?",[38,610,611],{},"Build that workflow end to end and cut nearly everything around it. Secondary user roles, settings pages, notification preferences, bulk actions, reporting dashboards, edge-case flows that affect a handful of users — all of it can wait for evidence that the core workflow matters.",[38,613,614,615,618],{},"Feature scope is the safest thing to cut precisely because features are additive. Adding a feature in month four rarely requires changing what you built in month one — ",[88,616,617],{},"if"," the foundations underneath were designed properly. That \"if\" is the subject of the second half of this post.",[599,620,622],{"id":621},"_2-nice-to-have-ui","2. Nice-to-have UI",[38,624,625,627],{},[74,626,607],{}," Does this polish change whether a user can complete the core workflow and understand its value?",[38,629,630],{},"If not, cut it. Custom illustrations, animations, dark mode, a bespoke design system, pixel-perfect responsive behaviour on every breakpoint — these are expensive to build and cheap to add later. Use a well-maintained component library, keep the interface clean and consistent, and invest in clarity rather than decoration.",[38,632,633],{},"This is not the same as shipping something confusing. An interface that users cannot understand corrupts the learning the MVP exists to produce: you cannot tell whether people rejected the product or rejected the interface.",[599,635,637],{"id":636},"_3-excess-integrations","3. Excess integrations",[38,639,640,642],{},[74,641,607],{}," Does this integration need to be automated before you have proven anyone wants the result?",[38,644,645],{},"Every third-party integration adds a dependency, an authentication flow, an error surface, and ongoing maintenance as the third party changes its API. Early on, many of them can be replaced with something manual: a CSV export instead of a sync with the customer's CRM, an email notification instead of a Slack app, a person on your team doing a step by hand instead of an automated pipeline.",[38,647,648],{},"Where an integration genuinely is core — payments, for example — integrate it properly, but wrap it behind your own internal interface rather than calling the provider's SDK from everywhere in the codebase. That one decision keeps a future provider switch a contained change rather than a hunt through dozens of files.",[599,650,652],{"id":651},"_4-infrastructure-built-for-load-you-do-not-have","4. Infrastructure built for load you do not have",[38,654,655,657],{},[74,656,607],{}," Are you solving a scaling problem you have, or one you hope to have?",[38,659,660],{},"Microservices, Kubernetes clusters, multi-region deployments, event-sourcing frameworks and elaborate caching layers all solve real problems — at a scale an MVP does not have. Before that scale, they add operational overhead and slow down the one thing an MVP needs most: fast iteration.",[38,662,663,664,667],{},"Martin Fowler's advice in ",[88,665,666],{},"MonolithFirst"," (2015) is direct: \"you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.\" His reasoning is that you do not yet know where the right service boundaries are, and building a monolith first lets you discover them.",[38,669,670,671,674],{},"This is also where Donald Knuth's most quoted line belongs. In his 1974 paper ",[88,672,673],{},"Structured Programming with go to Statements",", he wrote: \"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.\" The sentence that follows is quoted far less often: \"Yet we should not pass up our opportunities in that critical 3%.\" The second half of this post is about that 3%.",[599,676,678],{"id":677},"_5-internal-tooling","5. Internal tooling",[38,680,681,683],{},[74,682,607],{}," Could a founder handle this task by hand for the first few months?",[38,685,686],{},"Admin panels, internal analytics dashboards, customer-support tooling and content-management screens can usually be replaced in the early days with direct database access by a trusted engineer, a few well-tested scripts, or an off-the-shelf tool. Build them when the manual version starts costing real time.",[51,688,690],{"id":689},"what-to-keep","What to keep",[38,692,693],{},"These are the decisions that are cheap on day one and expensive later. They have one thing in common: once real users and real data depend on them, changing them stops being a code change and becomes a migration, a breaking change for clients, or a security incident.",[599,695,697],{"id":696},"_1-the-data-model-and-database-schema","1. The data model and database schema",[38,699,700,702],{},[74,701,607],{}," Will this data model still be correct when you have a hundred times the users, customers who are organisations rather than individuals, and three features you have not imagined yet?",[38,704,705],{},"Code can be refactored in an afternoon. Data that has been written in the wrong shape for eighteen months has to be migrated — carefully, often while the system is live, and sometimes with information that was never captured and cannot be recovered.",[38,707,708],{},"What to get right from the start:",[120,710,711,717,723,729,744,750],{},[123,712,713,716],{},[74,714,715],{},"Model the core entities deliberately."," Decide what a user, an account, an organisation and the central object of your product actually are, and how they relate. Most painful rewrites trace back to a relationship modelled as one-to-one that turned out to be one-to-many.",[123,718,719,722],{},[74,720,721],{},"Decide on tenancy early."," If you will ever sell to teams or companies, every relevant row needs to know which tenant it belongs to. Adding a tenant identifier to every table and query after the fact is one of the most expensive retrofits there is.",[123,724,725,728],{},[74,726,727],{},"Choose identifiers on purpose."," In 2012, Instagram — then a small engineering team with more than 30 million users in under two years — presented how it designed 64-bit IDs combining a timestamp, a logical shard ID and a sequence number, generated inside PostgreSQL. Those IDs were time-sortable and could be spread across thousands of logical shards mapped onto far fewer physical servers. You do not need sharding on day one. You do need identifiers that will not force a migration of every foreign key when you outgrow a single database.",[123,730,731,734,735,739,740,743],{},[74,732,733],{},"Store money and time correctly."," Use integer minor units (cents) or a fixed-precision decimal type for money, never floating point: in standard binary floating point, ",[736,737,738],"code",{},"0.1 + 0.2"," is ",[736,741,742],{},"0.30000000000000004",". Store timestamps in UTC with time-zone information and convert only for display.",[123,745,746,749],{},[74,747,748],{},"Let the database enforce integrity."," Foreign keys, unique constraints and NOT NULL constraints cost nothing to declare at the start and catch whole classes of bugs before they corrupt your data.",[123,751,752,755],{},[74,753,754],{},"Keep schema migrations in version control."," Every change to the schema should be a reviewed, repeatable migration — never a manual edit on the production database.",[599,757,759],{"id":758},"_2-the-api-contract","2. The API contract",[38,761,762,764],{},[74,763,607],{}," If a client you do not control depends on this API, can you change it without breaking them?",[38,766,767],{},"The moment a mobile app ships to an app store, a partner integrates, or a customer writes a script against your API, the API stops being an implementation detail. Old app versions stay in the wild for months, and you cannot force partners to update on your schedule.",[38,769,708],{},[120,771,772,782,788,794,800],{},[123,773,774,777,778,781],{},[74,775,776],{},"Version the API from day one",", even if ",[736,779,780],{},"v1"," is the only version for a long time.",[123,783,784,787],{},[74,785,786],{},"Design resources around your domain, not your database tables."," An API that mirrors the schema directly means every schema change becomes a breaking API change.",[123,789,790,793],{},[74,791,792],{},"Paginate list endpoints from the start."," Every list is small in the MVP, and some of them will not stay small. Adding pagination later changes the response shape that clients already depend on.",[123,795,796,799],{},[74,797,798],{},"Use one consistent error format"," with machine-readable codes.",[123,801,802,805],{},[74,803,804],{},"Make operations that move money or create important records safely retryable."," Stripe's API, for example, supports idempotency keys so that a client can retry a request after a network error \"without risk of creating a second object or performing the update twice.\" Networks fail; your API should assume they will.",[599,807,809],{"id":808},"_3-authentication-authorisation-and-security-foundations","3. Authentication, authorisation and security foundations",[38,811,812,814],{},[74,813,607],{}," If this system were breached tomorrow, what would be exposed — and would you know?",[38,816,817],{},"Security is the clearest case of a decision that cannot be retrofitted cheaply, because the cost of getting it wrong is not engineering time. It is customer data, trust and, depending on your market, regulatory exposure.",[38,819,820,821,824,825,828],{},"In the OWASP Top 10:2025, the most widely referenced ranking of web application security risks, ",[74,822,823],{},"Broken Access Control is ranked first",", and ",[74,826,827],{},"Authentication Failures"," are ranked seventh. These are not exotic attacks. They are the everyday consequences of security decisions made casually.",[38,830,708],{},[120,832,833,839,845,851],{},[123,834,835,838],{},[74,836,837],{},"Do not build authentication from scratch."," Use a proven identity provider or a mature, well-maintained library. Password storage, session handling, token expiry, account recovery and multi-factor authentication are solved problems that are easy to get subtly wrong.",[123,840,841,844],{},[74,842,843],{},"Enforce authorisation centrally."," Every request should pass through one consistent check of who the user is, which tenant they belong to and what they are allowed to do — not ad-hoc checks scattered through individual endpoints, where one forgotten check becomes a data leak.",[123,846,847,850],{},[74,848,849],{},"Keep secrets out of the code."," API keys and credentials belong in a secrets manager or environment configuration, never in the repository.",[123,852,853,856],{},[74,854,855],{},"Know what personal data you store and why."," If you have users in the EU, GDPR applies from your first user, not your ten-thousandth.",[599,858,860],{"id":859},"_4-the-foundations-that-make-scaling-possible","4. The foundations that make scaling possible",[38,862,863,865],{},[74,864,607],{}," When growth arrives, can you add capacity — or do you have to rebuild first?",[38,867,868],{},"An MVP should not be built for scale it does not have. It should be built so that scaling is an operational task rather than an architectural one. The difference is a small set of habits that cost little at the start:",[120,870,871,877,883,889,895],{},[123,872,873,876],{},[74,874,875],{},"Stateless application servers."," Keep session state and uploaded files out of the application server's memory and local disk, so that handling more traffic means running more instances.",[123,878,879,882],{},[74,880,881],{},"A background job queue."," Emails, exports, imports, and calls to slow third-party APIs should run outside the request cycle. Retrofitting this means touching every slow code path.",[123,884,885,888],{},[74,886,887],{},"Automated deployment."," A repeatable pipeline from commit to production, so that shipping a fix is routine rather than an event.",[123,890,891,894],{},[74,892,893],{},"Error tracking and basic monitoring."," You cannot fix what you cannot see. Users who hit errors in an MVP rarely report them — they leave.",[123,896,897,900],{},[74,898,899],{},"Backups that have actually been restored."," A backup that has never been tested is a hope, not a backup.",[38,902,903],{},"None of this is enterprise infrastructure. It is a few days of deliberate setup that keeps the system in Fowler's \"prudent debt\" quadrant instead of drifting into the reckless one.",[51,905,907],{"id":906},"the-cost-of-getting-it-backwards","The cost of getting it backwards",[38,909,910],{},"The failure pattern is consistent. An MVP is built with the wrong things cut: the features are polished, but the data model was improvised, authorisation was bolted on per endpoint, and nothing runs outside the request cycle. It works — for the first few hundred users. Then traction arrives, and with it the problems the shortcuts were hiding: tenants who can see each other's data, queries that slow to a crawl, a schema that cannot represent what the biggest new customer needs.",[38,912,913],{},"The exact number of users where this happens varies — 2,000 is a common enough point for the cracks to show, but the number matters less than the timing. It almost always arrives when the company can least afford to stop: right after a launch, a fundraise or a large customer win.",[38,915,916,917,919],{},"The ongoing cost of carrying that debt is well documented. In Stripe's 2018 ",[88,918,90],{}," study, conducted with Harris Poll among more than 1,000 developers and more than 1,000 C-level executives, developers estimated they spent an average of 13.5 hours a week on technical debt and a further 3.8 hours on bad code — 17.3 hours out of a 41.1-hour working week, or over 40% of their time.",[38,921,922,923,926],{},"The cost of escaping that debt through a full rewrite can be worse. In his 2000 essay ",[88,924,925],{},"Things You Should Never Do, Part I",", Joel Spolsky described Netscape's decision to rewrite its browser from scratch as \"the single worst strategic mistake that any software company can make.\" When he wrote it, Netscape's last major release had shipped almost three years earlier. As Spolsky put it, when you throw away working code, \"you are throwing away all that knowledge. All those collected bug fixes.\"",[38,928,929],{},"Getting the foundations right in the MVP is how you avoid having to choose between those two costs.",[51,931,933],{"id":932},"a-decision-test-you-can-use-in-every-planning-meeting","A decision test you can use in every planning meeting",[38,935,936],{},"In his 2015 letter to shareholders, Jeff Bezos distinguished between two types of decisions. Some are \"consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation.\" But most \"are changeable, reversible – they're two-way doors.\"",[38,938,939],{},"MVP scoping is the same distinction applied to software:",[120,941,942,948],{},[123,943,944,947],{},[74,945,946],{},"Two-way doors — cut freely:"," features, UI polish, internal tooling, most integrations, infrastructure capacity. Move fast and revisit with evidence.",[123,949,950,953],{},[74,951,952],{},"One-way doors — decide deliberately:"," the data model, tenancy, identifiers, the public API contract, authentication and authorisation, and how data is stored and protected. Slow down here, even in an MVP.",[38,955,956,957,960],{},"When a shortcut is proposed, ask one question: ",[88,958,959],{},"if this turns out to be wrong, is fixing it a code change — or a data migration, a breaking change for clients, or a security incident?"," The answer tells you which bucket it belongs in.",[51,962,964],{"id":963},"the-mvp-foundations-checklist","The MVP foundations checklist",[38,966,967],{},"Before your MVP takes its first real user, you should be able to tick every item on this list. Everything else can wait.",[120,969,970,973,976,979,982,985,988,991],{},[123,971,972],{},"The core entities and their relationships are modelled deliberately, including tenancy if you will ever sell to teams.",[123,974,975],{},"Identifiers are chosen with growth in mind, and money and timestamps are stored in precise, unambiguous types.",[123,977,978],{},"Database constraints enforce integrity, and every schema change is a version-controlled migration.",[123,980,981],{},"The API is versioned, paginated where it returns lists, consistent in its errors and independent of the database schema.",[123,983,984],{},"Operations that move money or create critical records are safely retryable.",[123,986,987],{},"Authentication uses a proven provider or library, and authorisation is enforced in one central place.",[123,989,990],{},"Secrets are outside the codebase, and you know what personal data you store.",[123,992,993],{},"Application servers are stateless, slow work runs in background jobs, deployments are automated, errors are tracked, and backups have been restored at least once.",[38,995,996,997,999],{},"If your MVP is already live and you are not sure how many of these boxes it ticks, that is a question a structured technical review answers quickly — the same domains we examine in our ",[297,998,300],{"href":299},", applied to your own product before an investor applies them for you.",[51,1001,388],{"id":387},[120,1003,1004,1017,1026,1034,1042,1049,1058,1066,1074,1081,1086],{},[123,1005,1006,1007,1012,1013,1016],{},"Eric Ries, ",[297,1008,1011],{"href":1009,"rel":1010},"https:\u002F\u002Fwww.startuplessonslearned.com\u002F2009\u002F08\u002Fminimum-viable-product-guide.html",[398],"\"Minimum Viable Product: a guide\"",", ",[88,1014,1015],{},"Startup Lessons Learned",", 2009",[123,1018,1019,1020,1025],{},"CB Insights, ",[297,1021,1024],{"href":1022,"rel":1023},"https:\u002F\u002Fwww.cbinsights.com\u002Fresearch\u002Freport\u002Fstartup-failure-reasons-top\u002F",[398],"\"Why startups fail: Top reasons\"",", March 2026",[123,1027,403,1028,409,1031,415],{},[297,1029,408],{"href":406,"rel":1030},[398],[297,1032,414],{"href":412,"rel":1033},[398],[123,1035,403,1036,1041],{},[297,1037,1040],{"href":1038,"rel":1039},"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FMonolithFirst.html",[398],"\"MonolithFirst\"",", 2015",[123,1043,1044,1045,1048],{},"Donald E. Knuth, \"Structured Programming with go to Statements\", ",[88,1046,1047],{},"Computing Surveys",", 1974",[123,1050,1051,1052,1057],{},"Mike Krieger, ",[297,1053,1056],{"href":1054,"rel":1055},"https:\u002F\u002Fmedia.postgresql.org\u002Fsfpug\u002Finstagram_sfpug.pdf",[398],"\"Sharding @ Instagram\"",", SFPUG, April 2012",[123,1059,1060,1061],{},"OWASP Foundation, ",[297,1062,1065],{"href":1063,"rel":1064},"https:\u002F\u002Ftop10.owasp.org\u002F2025\u002F",[398],"OWASP Top 10:2025",[123,1067,426,1068,1073],{},[297,1069,1072],{"href":1070,"rel":1071},"https:\u002F\u002Fdocs.stripe.com\u002Fapi\u002Fidempotent_requests",[398],"\"Idempotent requests\"",", API reference",[123,1075,426,1076,434],{},[297,1077,1079],{"href":429,"rel":1078},[398],[88,1080,433],{},[123,1082,456,1083,462],{},[297,1084,461],{"href":459,"rel":1085},[398],[123,1087,1088,1089,1094],{},"Jeff Bezos, ",[297,1090,1093],{"href":1091,"rel":1092},"https:\u002F\u002Fwww.sec.gov\u002FArchives\u002Fedgar\u002Fdata\u002F1018724\u002F000119312516530910\u002Fd168744dex991.htm",[398],"2015 Letter to Shareholders",", Amazon.com, Inc.",[38,1096,1097],{},[88,1098,1099,1100],{},"business2point builds MVPs that are narrow by design and sound by default — CTO-level architecture decisions from day one, so your first version can become your scaling version. ",[297,1101,471],{"href":470},{"title":473,"searchDepth":6,"depth":6,"links":1103},[1104,1105,1106,1114,1120,1121,1122,1123],{"id":533,"depth":6,"text":534},{"id":563,"depth":6,"text":564},{"id":589,"depth":6,"text":590,"children":1107},[1108,1110,1111,1112,1113],{"id":601,"depth":1109,"text":602},3,{"id":621,"depth":1109,"text":622},{"id":636,"depth":1109,"text":637},{"id":651,"depth":1109,"text":652},{"id":677,"depth":1109,"text":678},{"id":689,"depth":6,"text":690,"children":1115},[1116,1117,1118,1119],{"id":696,"depth":1109,"text":697},{"id":758,"depth":1109,"text":759},{"id":808,"depth":1109,"text":809},{"id":859,"depth":1109,"text":860},{"id":906,"depth":6,"text":907},{"id":932,"depth":6,"text":933},{"id":963,"depth":6,"text":964},{"id":387,"depth":6,"text":388},"An MVP gives you permission to build narrowly, not badly. Here is exactly which corners are safe to cut in your first version — and which architecture decisions you must get right before your first users arrive.",{"date":492,"authorId":6,"category":7,"tags":493,"image":496,"readingTime":497,"published":16,"cluster":17,"post_type":18,"faq":498},"\u002Fblog\u002Fmvp-vs-scalable-architecture-what-to-cut-what-to-keep",{"title":512,"description":1124},"blog\u002Fmvp-vs-scalable-architecture-what-to-cut-what-to-keep","uu7dsv8hgQMabRzSQ0DGhPT_nRomLM6WS9aF5iMtsoU",{"date":1131,"authorId":6,"category":1132,"tags":1133,"image":1138,"readingTime":1139,"published":16,"cluster":1140,"post_type":18,"faq":1141,"id":1154,"title":1155,"body":1156,"description":1480,"extension":485,"meta":1481,"navigation":16,"path":299,"seo":1482,"stem":1483,"__hash__":1484},"2025-01-20","due-diligence",[300,1134,1135,1136,1137],"tech stack assessment","software architecture review","due diligence","investors","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1551288049-bebda4e38f71?w=1200&q=80",11,"C — Technical Due Diligence",[1142,1145,1148,1151],{"question":1143,"answer":1144},"What is the difference between a technical due diligence checklist and a full technical assessment?","A checklist is the framework for what to examine. A full technical assessment is the work of actually examining it — reading the code, interviewing the team, reviewing the infrastructure, and producing a written report with risk ratings and recommendations. The checklist tells you what questions to ask. The assessment answers them.",{"question":1146,"answer":1147},"How long does a technical due diligence take?","A properly scoped technical assessment takes three to seven business days. Longer engagements are not necessarily more thorough — they are often less focused.",{"question":1149,"answer":1150},"Can a non-technical person run a technical due diligence?","A non-technical person can conduct the business and process portions of an assessment. The technical domains — architecture, code quality, security, IP — require someone who can read code, review infrastructure, and ask questions that a well-prepared team cannot deflect with jargon.",{"question":1152,"answer":1153},"What does technical due diligence cost?","Costs vary by scope, timeline, and the complexity of the system being assessed. A three-to-seven-day engagement with a senior technical team typically runs significantly less than the cost of discovering a material technical risk six months after a deal closes.","content\u002Fblog\u002Ftechnical-due-diligence-checklist.md","The Technical Due Diligence Checklist: What a Senior Assessment Actually Covers",{"type":35,"value":1157,"toc":1468},[1158,1161,1164,1167,1171,1174,1177,1180,1184,1189,1192,1209,1215,1219,1224,1226,1251,1256,1260,1265,1267,1287,1292,1296,1301,1303,1323,1328,1332,1337,1339,1353,1358,1362,1367,1369,1383,1388,1392,1397,1399,1416,1421,1425,1430,1432,1446,1451,1455,1458,1461],[38,1159,1160],{},"A checklist only works if it asks the right questions.",[38,1162,1163],{},"Most technical due diligence checklists available online were written by people who have never actually opened a codebase under acquisition pressure — they cover the obvious surface areas (does the company use version control? is there documentation?) and miss the things that actually determine whether the technology can support the business thesis.",[38,1165,1166],{},"This is the checklist we use. It covers eight domains: software architecture and scalability headroom, code quality and maintainability, infrastructure and operational maturity, security posture and compliance exposure, intellectual property and licensing risk, third-party dependencies and vendor lock-in, team structure and knowledge concentration, and technical debt — quantified, not estimated.",[51,1168,1170],{"id":1169},"what-makes-a-technical-due-diligence-checklist-actually-useful","What makes a technical due diligence checklist actually useful",[38,1172,1173],{},"A useful checklist does one thing a generic one does not: it separates the questions that reveal the condition of the technology from the questions that reveal the condition of the team that built it.",[38,1175,1176],{},"Both matter. But they tell different stories, and they require different assessment methods. You can have a technically sound codebase built by a team that has already left. You can have a fragile codebase built by a team that fully understands it and has a credible plan to address it. The risk profile of those two situations is completely different — and a checklist that only looks at the code misses half the picture.",[38,1178,1179],{},"The eight domains below are structured to surface both.",[51,1181,1183],{"id":1182},"domain-1-software-architecture-and-scalability-headroom","Domain 1: Software architecture and scalability headroom",[38,1185,1186,1188],{},[74,1187,607],{}," Can the architecture support the business thesis — not just current load, but the load that justifies the investment?",[38,1190,1191],{},"What to assess:",[120,1193,1194,1197,1200,1203,1206],{},[123,1195,1196],{},"Is the architecture monolithic, service-oriented, or microservices? There is no universally correct answer — the right architecture depends on team size, scale requirements, and operational maturity. The wrong answer is one that does not match any of those.",[123,1198,1199],{},"Is the system stateless where it needs to be to scale horizontally?",[123,1201,1202],{},"Where are the bottlenecks? Every system has them. A team that cannot tell you where theirs are has not looked — or has looked and is not telling you.",[123,1204,1205],{},"What is the database architecture? Read\u002Fwrite split? Sharding strategy? Connection pooling? For systems that need to scale, the database is almost always the first constraint.",[123,1207,1208],{},"What does the architectural decision log look like? Recorded decisions indicate a team that reasons about architecture deliberately. No record indicates a team that makes architectural decisions by default.",[38,1210,1211,1214],{},[74,1212,1213],{},"What a red flag looks like:"," A system described as \"microservices\" that has a single shared database. This is not a microservices architecture — it is a distributed monolith with the operational overhead of microservices and none of the scalability benefits.",[51,1216,1218],{"id":1217},"domain-2-code-quality-and-maintainability","Domain 2: Code quality and maintainability",[38,1220,1221,1223],{},[74,1222,607],{}," Can a new team member get productive in this codebase in a reasonable amount of time?",[38,1225,1191],{},[120,1227,1228,1231,1234,1237,1240],{},[123,1229,1230],{},"Test coverage — and more importantly, the quality of what is being tested. A 90% coverage number means nothing if the tests only verify that functions run without throwing errors.",[123,1232,1233],{},"Code consistency: does the codebase follow a documented style guide, enforced by tooling? Inconsistency signals either a lack of process or a team that has grown faster than its practices.",[123,1235,1236],{},"Cyclomatic complexity on critical paths. Complex code is not bad by definition — but complex code with no tests and no documentation is a liability.",[123,1238,1239],{},"PR review history. Look at the comments. Do they catch real issues? Or are they approvals with no friction? A team that rubber-stamps pull requests is a team whose quality gate does not exist.",[123,1241,1242,1243,1246,1247,1250],{},"Documentation at the right level of abstraction. Code-level comments explaining ",[88,1244,1245],{},"what"," the code does are usually noise. Architecture-level documentation explaining ",[88,1248,1249],{},"why"," decisions were made is rare and valuable.",[38,1252,1253,1255],{},[74,1254,1213],{}," A codebase with near-zero commit history on anything outside of feature branches. Either no one is reviewing code, or the team has been working outside of version control and importing final code. Neither is recoverable without a full reset of engineering practices.",[51,1257,1259],{"id":1258},"domain-3-infrastructure-and-operational-maturity","Domain 3: Infrastructure and operational maturity",[38,1261,1262,1264],{},[74,1263,607],{}," Can this system be operated reliably at the scale the business requires, and can it recover when it fails?",[38,1266,1191],{},[120,1268,1269,1272,1275,1278,1281,1284],{},[123,1270,1271],{},"Deployment pipeline: is there one? Is it automated? Can a change be deployed in minutes or days?",[123,1273,1274],{},"Environment parity: are development, staging, and production environments consistent? Environments that drift from each other produce bugs that only appear in production — the most expensive kind.",[123,1276,1277],{},"Monitoring and alerting: what is being monitored, at what thresholds, and who is alerted? A system with no monitoring is a system where failures go undetected until users complain.",[123,1279,1280],{},"Incident history and post-mortems: how the team responds to failure is more informative than whether they have failed.",[123,1282,1283],{},"Cloud cost structure: is spend optimised, or has the infrastructure been built without attention to unit economics? Unmanaged cloud spend is a reliable indicator that operational discipline has not been established.",[123,1285,1286],{},"Backup and disaster recovery: what is the recovery time objective and recovery point objective? Has it been tested?",[38,1288,1289,1291],{},[74,1290,1213],{}," No staging environment. Production is the first place any change is tested. This is not just a technical risk — it is a signal about how the engineering culture treats quality.",[51,1293,1295],{"id":1294},"domain-4-security-posture-and-compliance-exposure","Domain 4: Security posture and compliance exposure",[38,1297,1298,1300],{},[74,1299,607],{}," What is the realistic exposure — regulatory, reputational, and operational — if this system is breached or found to be non-compliant?",[38,1302,1191],{},[120,1304,1305,1308,1311,1314,1317,1320],{},[123,1306,1307],{},"Authentication and authorisation architecture. Is MFA enforced? Are permissions scoped by role?",[123,1309,1310],{},"Secret management: are API keys, credentials, and environment secrets stored securely (secrets manager) or in code or configuration files?",[123,1312,1313],{},"Data handling: what personal or sensitive data is stored, where, in what form, and under what retention policy?",[123,1315,1316],{},"Dependency vulnerability scanning: are known CVEs in third-party libraries being tracked and patched?",[123,1318,1319],{},"Penetration testing history: has the system been tested by an external party? When? What was found and remediated?",[123,1321,1322],{},"Regulatory landscape: GDPR, HIPAA, SOC 2, PCI-DSS — which apply, and what is the current compliance posture?",[38,1324,1325,1327],{},[74,1326,1213],{}," Credentials committed to a git repository at any point in the project's history. If unrotated, those credentials remain actively exploitable by anyone with access to the repository or any of its clones. If rotated, the immediate risk is neutralised — but the exposure window between commit and rotation is unknown and unverifiable. More importantly, the commit is evidence of a process failure: the team did not have secret scanning, pre-commit hooks, or a secrets management policy in place at the time. Without explicit evidence those controls now exist, there is no basis to assume the pattern will not repeat.",[51,1329,1331],{"id":1330},"domain-5-intellectual-property-and-licensing-risk","Domain 5: Intellectual property and licensing risk",[38,1333,1334,1336],{},[74,1335,607],{}," Does the company actually own what it is selling?",[38,1338,1191],{},[120,1340,1341,1344,1347,1350],{},[123,1342,1343],{},"Employment and contractor agreements: do all individuals who have contributed to the codebase have proper IP assignment clauses? A contractor who contributed significant code without an IP assignment agreement is a potential ownership dispute waiting to surface.",[123,1345,1346],{},"Open source licence compliance: what open source libraries does the system use, and under what licences? GPL licences in a commercial product can create significant exposure.",[123,1348,1349],{},"Third-party IP: does the system incorporate any code, algorithms, or assets that were not created internally? Is there documentation of the right to use them?",[123,1351,1352],{},"Patent risk: for genuinely novel technical approaches, has any FTO (freedom to operate) analysis been done?",[38,1354,1355,1357],{},[74,1356,1213],{}," Key early development done by a third-party agency with no IP assignment clause in the engagement contract. This is surprisingly common and can represent a material undisclosed risk.",[51,1359,1361],{"id":1360},"domain-6-third-party-dependencies-and-vendor-lock-in","Domain 6: Third-party dependencies and vendor lock-in",[38,1363,1364,1366],{},[74,1365,607],{}," What happens to the system if a key third-party changes its pricing, deprecates its API, or goes out of business?",[38,1368,1191],{},[120,1370,1371,1374,1377,1380],{},[123,1372,1373],{},"Dependency inventory: what services, APIs, and libraries does the system depend on? Is there a maintained inventory, or does this need to be reconstructed from the codebase?",[123,1375,1376],{},"Concentration risk: are there single-vendor dependencies for critical functions (payment, authentication, data storage, communication)?",[123,1378,1379],{},"Abstraction layers: are third-party integrations wrapped in internal interfaces that would allow a replacement to be swapped in? Or is the third-party API called directly throughout the codebase?",[123,1381,1382],{},"Contractual dependencies: what are the terms of key vendor agreements? Minimum commitments, data portability clauses, termination provisions?",[38,1384,1385,1387],{},[74,1386,1213],{}," Direct integration with a single payment provider's SDK throughout the codebase, with no abstraction layer. Switching providers — whether due to pricing, a provider shutdown, regulatory requirements in a new market, or reliability failures — would require changes in dozens of places. The cost of switching is not visible in the business metrics until a forcing function makes it unavoidable, at which point it becomes urgent and expensive simultaneously.",[51,1389,1391],{"id":1390},"domain-7-team-structure-and-knowledge-concentration","Domain 7: Team structure and knowledge concentration",[38,1393,1394,1396],{},[74,1395,607],{}," Is the technical capability of this business concentrated in one or two people who could leave — and what happens to the system if they do?",[38,1398,1191],{},[120,1400,1401,1404,1407,1410,1413],{},[123,1402,1403],{},"Bus factor: how many people would need to leave for critical technical knowledge to be lost? A bus factor of one is a risk that needs to be quantified and disclosed.",[123,1405,1406],{},"Documentation as knowledge distribution: is architectural knowledge in one person's head or in documentation that can onboard a replacement?",[123,1408,1409],{},"Succession readiness: is there a second-in-command who understands the system at the same depth as the lead engineer?",[123,1411,1412],{},"Retention risk: what are the current compensation, equity, and contract structures for key technical personnel? Are they likely to stay post-acquisition?",[123,1414,1415],{},"Hiring pipeline: does the team have a repeatable process for evaluating and onboarding technical hires, or has the team grown primarily through personal networks?",[38,1417,1418,1420],{},[74,1419,1213],{}," The lead engineer who built the system has already left. The current team understands enough to keep it running but cannot extend the parts that matter — the core logic, the data model, the integration layer. Those sections are effectively frozen. New capability either gets built around the edges in ways that compound the existing fragility, or the team brings in someone external to rebuild the problematic components from scratch. Neither option is cheap, and neither is visible in the current velocity metrics. The deal terms should reflect that the technical asset has a ceiling the current team cannot raise.",[51,1422,1424],{"id":1423},"domain-8-technical-debt-quantified-not-estimated","Domain 8: Technical debt — quantified, not estimated",[38,1426,1427,1429],{},[74,1428,607],{}," What is the actual cost, in engineering time and velocity, of the technical shortcuts that have been taken?",[38,1431,1191],{},[120,1433,1434,1437,1440,1443],{},[123,1435,1436],{},"Debt inventory: has the team ever done a structured technical debt assessment? Do they have a maintained backlog of known debt items with estimated effort to address them?",[123,1438,1439],{},"Debt concentration: is the debt spread across the system, or concentrated in high-traffic, high-change areas where it will block every new feature?",[123,1441,1442],{},"Debt-to-feature ratio: roughly, what proportion of current engineering capacity goes to maintaining and working around existing debt versus shipping new capability?",[123,1444,1445],{},"Planned remediation: is there a credible plan to address the most impactful debt, with realistic timelines and resource allocation?",[38,1447,1448,1450],{},[74,1449,1213],{}," The answer to \"what does technical debt cost you?\" is \"we handle it as we go.\" This means there is no inventory, no prioritisation, and no measurement — which means the debt is being accumulated faster than it is being addressed. Poorly managed technical debt consumes roughly 30% of a development team's capacity when left unaddressed. That is not a maintenance cost. That is a growth constraint that will show up in the next six months of velocity data.",[51,1452,1454],{"id":1453},"how-to-use-this-checklist","How to use this checklist",[38,1456,1457],{},"Run it in sequence, but not in isolation. Each domain will surface questions that are answered in another — a team that has no incident post-mortems (Domain 3) is likely to also have no technical debt inventory (Domain 8) and no architectural decision log (Domain 1). The pattern of what is absent is as informative as what is present.",[38,1459,1460],{},"For a complete picture of what a technical assessment produces — findings, risk ratings, and the typical timeline for a properly scoped engagement — see our complete guide to technical due diligence.",[38,1462,1463],{},[88,1464,1465,1466],{},"business2point delivers technical due diligence for investors, acquirers, and founders in three to seven business days. ",[297,1467,471],{"href":470},{"title":473,"searchDepth":6,"depth":6,"links":1469},[1470,1471,1472,1473,1474,1475,1476,1477,1478,1479],{"id":1169,"depth":6,"text":1170},{"id":1182,"depth":6,"text":1183},{"id":1217,"depth":6,"text":1218},{"id":1258,"depth":6,"text":1259},{"id":1294,"depth":6,"text":1295},{"id":1330,"depth":6,"text":1331},{"id":1360,"depth":6,"text":1361},{"id":1390,"depth":6,"text":1391},{"id":1423,"depth":6,"text":1424},{"id":1453,"depth":6,"text":1454},"Most technical due diligence checklists cover the obvious surface areas and miss the things that actually determine whether the technology can support the business thesis. This is the checklist we use.",{"date":1131,"authorId":6,"category":1132,"tags":1133,"image":1138,"readingTime":1139,"published":16,"cluster":1140,"post_type":18,"faq":1141},{"title":1155,"description":1480},"blog\u002Ftechnical-due-diligence-checklist","6a1knX8MyhSlI4EiXbVgfSHy6PlDzQraQA3t4SSdRqo",{"id":1486,"title":1487,"body":1488,"description":1518,"extension":485,"meta":1519,"navigation":16,"path":1520,"seo":1521,"stem":1522,"__hash__":1523},"content\u002Fcategories.md","Blog Categories",{"type":35,"value":1489,"toc":1516},[1490,1493],[38,1491,1492],{},"categories:",[120,1494,1495,1498,1501,1504,1507,1510,1513],{},[123,1496,1497],{},"id: strategy\nname: Strategy\ndescription: Technology strategy, CTO insights, and executive decision-making\nslug: strategy",[123,1499,1500],{},"id: engineering\nname: Engineering\ndescription: Software architecture, development practices, and technical deep-dives\nslug: engineering",[123,1502,1503],{},"id: ai\nname: AI & Automation\ndescription: Artificial intelligence, machine learning, and automation solutions\nslug: ai-automation",[123,1505,1506],{},"id: leadership\nname: Leadership\ndescription: Team building, engineering culture, and technical leadership\nslug: leadership",[123,1508,1509],{},"id: product\nname: Product\ndescription: Product development, user experience, and market-fit strategies\nslug: product",[123,1511,1512],{},"id: transformation\nname: Transformation\ndescription: Digital transformation, modernization, and scaling operations\nslug: transformation",[123,1514,1515],{},"id: due-diligence\nname: Due Diligence\ndescription: Technical due diligence, investment assessments, and acquisition readiness\nslug: due-diligence",{"title":473,"searchDepth":6,"depth":6,"links":1517},[],"Categories for organizing blog content",{},"\u002Fcategories",{"title":1487,"description":1518},"categories","PTtAcQU13Is9QzoHEK0lkMj7seW0AClsgsBLpnB7qFs",1791817076619]