Off the shelf, in-house, or built for you: what the evidence says about how companies should acquire their systems

A company of five to fifty people that needs software has three ways to get it. It can buy a product built for the average company. It can hire developers and build internally. Or it can commission a custom system from a specialized external builder. Each path carries a structural trade-off, and most of the writing about this choice is produced by someone selling one of the three options.

This article is our attempt to do it properly. We traced the famous statistics to their original studies, threw out the ones that did not survive contact with their sources, and labeled the evidence by where it comes from, including the places where the only available data is published by vendors with something to sell. Where the evidence is thin, we say so. Where it contradicts our own commercial interest, we report it anyway, because the conclusion only matters if the path to it is honest.

The short version of the argument: off-the-shelf software is the right answer more often than custom builders like to admit, internal builds fail for small companies for reasons that have little to do with the famous failure statistics, and the third path, custom systems from specialized external builders, has moved from an enterprise luxury to an option worth pricing for small companies, because the economics of building software changed materially in the last three years. The long version follows, evidence first.

	Off the shelf	In-house build	External specialist
Time to start	Days	Months+	Weeks
Initial cost	Low, per seat	Highest+	Mid, project-based
Cost trajectory	Rising+	Fixed payroll plus maintenance	Build, then standing maintenance
Fit to your workflows	Built for the average company+	Highest in theory	High, contractually defined
Key-person risk	Low+	Highest+	Present+
Differentiation potential	None by construction+	High if sustained	High if process is genuinely differentiating

Off the shelfx

Time to start

Days

Initial cost

Low, per seat

Cost trajectory

Rising13.2% SaaS inflation in March 2026 (Vertice, vendor-reported). Vertice 2026

Fit to your workflows

Built for the average companyThe misfit literature documents companies bending processes to fit packaged tools (Soh et al. 2000; Strong and Volkoff 2010). Soh et al. 2000

Key-person risk

LowThe vendor maintains the product.

Differentiation potential

None by constructionA resource available to every competitor on equal terms cannot sustain advantage (Barney 1991; Mata et al. 1995). Barney 1991

In-house build+

External specialist+

Path one: off the shelf

What buying software for the average company actually costs

Start with what is known about SaaS portfolios, and with an honesty note that frames everything in this section: there is no independent, non-vendor measurement of how many SaaS tools companies buy or how much of what they buy goes unused. The entire quantitative evidence base comes from SaaS management vendors, companies whose product is sold on the premise that you are wasting money on software. Their data is real telemetry and real surveys, but the conflict of interest is structural, so every number below is labeled vendor-reported and should be read as describing the market those vendors serve, which skews toward companies far larger than fifty people.

With that framing: the telemetry vendor Zylo, analyzing more than 40 million licenses across its customer base, reports an average portfolio of 305 SaaS applications per company and license utilization of 54 percent, meaning roughly half of paid licenses went unused in the prior measurement year Zylo, 2026. Productiv, measuring actual usage events, reported that 47 percent of licenses were used within a 90-day window Productiv, 2023. Survey data from BetterCloud, which asks IT professionals rather than reading telemetry, puts the average at 106 apps in 2024, down from a peak of 130 in 2022, the first decline in over a decade BetterCloud, 2025. The 3x gap between the survey number and the telemetry number is itself informative: telemetry counts every expensed app including the ones IT does not know about.

None of these portfolio counts describes a twenty-person company. The smallest credible measurement bands start at 75 employees, and the vendors' customer bases are enterprises. What transfers down-market is the per-employee figure and the direction of travel: vendor-reported SaaS spend per employee ran roughly $5,000 to $9,500 per year across 2023 to 2025 data Zylo, 2025; Zylo, 2026, and Productiv reported small businesses spending 49 percent more per employee than large enterprises, because small companies get no volume discounts Productiv, 2023. For a thirty-person company, the vendor-reported range implies a SaaS bill somewhere between $150,000 and $285,000 a year, before anyone has built anything specific to how that company works.

The famous feature-waste statistic deserves its correction here, because it is usually quoted wrong. "80 percent of software features are rarely or never used" comes from a 2019 analysis by the product analytics vendor Pendo, and the original report says something more precise: across 615 products instrumented by Pendo over a three-month window, 24 percent of features were never used at all, and a further 56 percent were used so rarely that together they accounted for only the last 5 percent of usage volume Pendo, 2019. It is a concentration finding, not an abandonment rate, and it is vendor-reported. Read accurately, it still says what matters for a buyer: you pay for the whole product and use a thin slice of it, because the product was built for everyone.

The price only moves one direction

The defining economics of subscription software is that it is cheap to enter and expensive to stay. The canonical economics of switching costs explains why: once a customer's data, integrations, and habits are inside a product, the vendor holds market power at renewal that it did not hold at signup, and vendors rationally price low to acquire and high to retain Farrell and Klemperer, 2007. The observable result, again from vendor purchasing data: SaaS prices rose 12 percent in the twelve months to August 2023, double the pace of 2019, with 73 percent of providers raising prices Vertice via CFO Dive, 2023, and Vertice's live index, computed from over $30 billion in processed spend, showed SaaS inflation of 13.2 percent in March 2026 Vertice, 2026. In Zylo's 2026 survey, 79 percent of IT leaders had encountered price increases at renewal in the past year, and 78 percent reported unanticipated charges from consumption-based or AI pricing Zylo, 2026. All vendor-reported; all pointing the same way. Gartner's published planning assumption, framed explicitly as a prediction rather than a measurement, is that organizations without centralized visibility into their SaaS lifecycles will overspend by at least 25 percent through 2027 Gartner, 2024.

Peer-reviewed work confirms that lock-in is not just a pricing anecdote: survey research on cloud migration finds that data migration costs and provider heterogeneity materially constrain companies' ability to leave Opara-Martins, Sahandi and Tian, 2016.

Seats: 20

Annual cost per seat (your number here)

$

Assumed annual price increase: 12%

2019 pace: about 6%2023 pace: 12%

Horizon3 yr5 yr7 yr

Total spend, 5 years

$152,468

21% of that is price increases on top of the year-one baseline ($120,000, dashed line).

79% of IT leaders encountered renewal price increases in the past 12 months Zylo 2026.

Price-trend data is vendor-reported, from SaaS purchasing platforms Vertice and Zylo. No independent index of SaaS pricing exists. Live index context: 13.2% in March 2026, peak 14.7% November 2025 Vertice.

The deeper cost: your workflows bend to the tool

The most studied cost of packaged software is not financial. Information systems researchers have spent twenty-five years documenting what they call misfit: the gap between what a packaged system assumes about how work happens and how work actually happens in a given company. The founding study showed that enterprise packages embed their vendors' assumptions about process, so that adopting organizations encounter structural mismatches in data, functions, and outputs Soh, Kien and Tay-Yap, 2000. The most cited modern treatment goes further, classifying misfits across six domains including roles, control, and organizational culture, and distinguishing deficiencies, where the system lacks something, from impositions, where the system forces something on the organization Strong and Volkoff, 2010. Thomas Davenport made the managerial version of the argument in 1998: packaged enterprise systems carry their own logic, and companies frequently end up changing their processes to fit the system rather than the reverse Davenport, 1998.

This is not an antique ERP problem. The modern cloud implementation methodology makes adaptation official: SAP's fit-to-standard process for cloud ERP teaches customers the standard processes and has them configure within those constraints, replacing the old practice of analyzing gaps and customizing to close them SAP, fit-to-standard documentation. The forced change is measurable in people, not just process: a twelve-month field study of 2,794 employees found that an enterprise system implementation altered the basic relationships between job characteristics and job satisfaction Morris and Venkatesh, 2010.

Two findings discipline this critique, and we will return to both. First, adaptation is sometimes the right answer: in a study of 111 manufacturing plants, packaged systems delivered more benefit where processes were interdependent and standard, and less where local processes were genuinely differentiated Gattiker and Goodhue, 2005. That conditional is the hinge of this entire article. Second, small companies are not innocent victims of misfit: case research on SMEs found they often customize against perceived misfits that turn out not to be real requirements at all van Beijsterveld and van Groenendaal, 2016.

Vertical axis: how much the process drives what customers pay you

Buy the best product, invest in how you use it

CRM

Custom system territory: misfit costs land exactly here Gattiker and Goodhue 2005

Pricing engineProduction planning

Buy and adapt: the package's assumptions are accumulated industry experience

PayrollInvoicing

Configure, do not customize: uniqueness here is usually perceived, not real van Beijsterveld and van Groenendaal 2016

Customer onboarding

Horizontal axis: how standard the process is across your industry (standard at left, unique at right)

Example processes are placed in their typical zones. ERP benefits run higher where interdependence is high and differentiation low Gattiker and Goodhue 2005.

And it cannot differentiate you, by construction

The last cost of off-the-shelf software is strategic, and it follows from first principles that have held up for thirty-five years. The resource-based view of strategy, the dominant academic account of why some firms outperform others, holds that a resource can only sustain competitive advantage if it is valuable, rare, hard to imitate, and hard to substitute. A resource available to every competitor on equal commercial terms fails that test by definition Barney, 1991; Peteraf, 1993. Applied directly to IT in a classic analysis: of the things a company can have, the technology itself and the technical skills to run it are imitable and purchasable; only the firm-specific ability to deploy technology against its own business can sustain advantage Mata, Fuerst and Barney, 1995.

Nicholas Carr made the strongest popular version of this point in 2003: as IT commoditizes, it stops mattering strategically, so spend less and follow the market Carr, 2003. The empirical answer to Carr matters more for our purposes than Carr himself. When researchers examined all publicly traded US companies, they found that the IT-heavy period since the mid-1990s did not flatten competition; it sharpened it. Performance gaps between leaders and laggards widened most in the most IT-intensive industries, because the advantage was never the software, it was the firm-specific processes deployed on top of it McAfee and Brynjolfsson, 2008. The same research program found that a dollar of computer capital was associated with over ten dollars of market value in large firms, against roughly one dollar for other tangible assets, which the authors read as the market pricing the organizational system built around the technology, not the technology Brynjolfsson, Hitt and Yang, 2002. And the cleanest natural experiment on the question found that US multinationals operating in Europe extracted significantly more productivity from the same IT than their non-US peers, with the difference traced to management practices Bloom, Sadun and Van Reenen, 2012.

The pattern extends into the AI era, with the original architect of the resource-based view as a co-author: ubiquitous AI tools homogenize rather than differentiate, and the fundamentals of advantage remain rare, firm-specific capabilities Wingate, Burns and Barney, 2025.

So the off-the-shelf path, summarized fairly: fastest to start, lowest initial cost, professionally maintained, and the correct choice for any process where you are like everyone else. The costs arrive later and compound: per-seat prices that rise faster than inflation, paid capacity that goes half unused by the vendors' own measurements, workflows bent toward the average company, and zero contribution to what makes you different, because your competitors can buy the identical thing tomorrow.

---

Path two: building in-house

As commonly quotedOnly 16% of software projects succeed.What the source says +The 1994 Standish figure counted only projects matching their initial estimates, from a survey of 365 IT executives. Researchers later showed the metric measures estimation culture: identical delivery performance scores 6% to 94% depending on how an organization estimates.Rejected as a failure rateStandish 1994Eveleens and Verhoef 2010As commonly quotedIT projects overrun their budgets by 200%.What the source says +Across 1,471 projects the average overrun was 27%. The 200% figure describes the worst one in six projects. The risk is the tail, not the average, and it concentrates in large projects.CorrectedFlyvbjerg and Budzier 2011As commonly quoted80% of software features are never used.What the source says +The original Pendo analysis found 24% never used and 56% rarely used, defined as features collectively producing the last 5% of usage volume, across 615 products on Pendo's own platform. A concentration finding, vendor-reported.Use with caveatsPendo 2019As commonly quotedAI makes developers 19% slower.What the source says +True in one 2025 trial: 16 experts on huge codebases they knew deeply. The same lab's 2026 update found the slowdown largely gone in new cohorts and concluded current tools likely speed developers up. Gains are uneven, not negative.CorrectedMETR 2025METR 2026As commonly quotedA bad hire costs 30% of first-year earnings, says the US Department of Labor.What the source says +No DOL publication contains this figure; the agency's own materials cite academic research instead: median replacement cost 21% of annual salary, far higher for complex roles.Rejected as attributedBoushey and Glynn 2012

The failure statistics, corrected before use

The case against internal builds is usually made with a famous number: most software projects fail. We traced that number, and the article you are reading will not use it, because it does not survive the trip to its source.

The origin is the Standish Group's 1994 CHAOS report, which found that 16.2 percent of surveyed projects were "successful," defined as on time, on budget, and with all specified features Standish Group, 1994. Three things are wrong with how that figure circulates. First, the definition counts only adherence to initial estimates: a project that ships, works, and earns its keep counts as failed if the original guess was optimistic. Second, when researchers applied Standish's definitions to a database of 5,457 real forecasts, they showed the metric mostly measures estimation culture: the same delivery performance scores anywhere from 6 percent to 94 percent "success" depending on whether an organization habitually pads its estimates Eveleens and Verhoef, 2010. Third, the often-quoted 189 percent average overrun applied only to the non-successful subset and is ambiguous even in the original; estimation researchers reviewing the report concluded the figure was far too high to represent typical projects and that comparable surveys placed average overruns at around 30 to 40 percent Jorgensen and Molokken-Ostvold, 2006. A survey of 412 experienced UK project managers, similarly, reported overruns far milder than the crisis narrative, with roughly two thirds of typical projects performing well and only about one in ten abandoned Sauer, Gemino and Reich, 2007.

What does hold up, in peer-reviewed form, is the shape of the risk rather than its average. Across a database of 1,471 IT projects, the average cost overrun was a manageable 27 percent, but one project in six was a statistical outlier averaging 200 percent cost overrun and almost 70 percent schedule overrun Flyvbjerg and Budzier, 2011. The follow-up study of 5,392 IT projects confirmed that IT cost overruns follow a power law: most projects are fine, and the tail is catastrophic, which means planning on averages systematically understates the risk Flyvbjerg et al., 2022.

And one more correction, which cuts in the opposite direction from how this literature is usually deployed: the failure research is about large projects, and size is the dominant variable. Standish's own 2015 data, whatever its definitional problems, shows small projects succeeding at 61 percent against 6 percent for the largest category, and names size the single most important factor in outcomes Standish Group, 2015. A 30-person company building a focused internal tool is not running enterprise-scale project risk, and pretending otherwise would be the kind of statistical sleight this article exists to avoid.

So if the famous failure rates are not the real argument against internal builds for small companies, what is?

Grand6% successful, 43% failed

Large11% successful, 30% failed

Medium12% successful, 26% failed

Moderate24% successful, 12% failed

Small61% successful, 7% failed

SuccessfulChallengedFailed

Source: Standish CHAOS 2015. Standish's success definition counts adherence to estimates and satisfaction, and has documented methodological criticisms (Eveleens and Verhoef 2010); the size gradient, not the absolute rates, is the finding. Standish itself calls size the single most important factor in outcomes.

The real problem is the capability gap

The honest case against the in-house path for a company of five to fifty people is about capacity, cost, and continuity, and here the evidence is government-grade.

Start with whether small companies can field the people at all. In the EU, 78.4 percent of large enterprises employ ICT specialists; among small enterprises of 10 to 49 employees, the figure is 14.0 percent. In 2023, 51.9 percent of large enterprises recruited or tried to recruit ICT specialists; among small enterprises, 6.2 percent even tried Eurostat, 2025. Note what this data does and does not say: Eurostat is explicit that among firms that do try to recruit, difficulty rates are similar regardless of size. The small-firm disadvantage is not that hiring feels harder; it is that the option is structurally absent. Most small companies never enter the market for engineering talent, and the global backdrop is a labor market where 74 percent of employers report difficulty finding skilled talent, with IT skills the hardest category ManpowerGroup, 2025.

Now price the hire. The median US software developer earns $135,980 in base wages, with the mean at $148,100 BLS OEWS, 2025. US private-sector benefits add 29.7 percent of total compensation on top of wages BLS ECEC, 2025, which puts a median developer at roughly $170,000 to $193,000 per year fully loaded, before recruiting, equipment, or management time (our computation from the two BLS series). European wages are lower, with self-reported survey medians around $70,000 to $76,000 in Germany and the UK Stack Overflow, 2024, but European employer loadings average 33 percent on top of gross wages and reach 48 percent in France Eurostat, 2026. Filling the seat takes a median of 56 days in the US and 85 in Europe for tech roles, by the recruiting platform Workable's vendor-reported data Workable, 2023. And the company that does hire is bidding against a market where the self-selected, big-tech-skewed median for total engineering compensation is $226,000 levels.fyi, 2025, vendor-reported and including equity, but indicative of what the strongest candidates are walking away from.

For a fifty-person company, one fully loaded developer is a material share of payroll. For a fifteen-person company, it is one of the largest line items the business has, spent on a single point of failure.

Employ ICT specialists

14%78.4%

Small enterprises, 10 to 49 employees (hollow dot)Large, 250+ (solid dot)

Recruited or tried to recruit ICT specialists (2023)

6.2%51.9%

Small enterprises, 10 to 49 employees (hollow dot)Large, 250+ (solid dot)

Of enterprises that did try to recruit, 57.5% had hard-to-fill ICT vacancies; difficulty was similar regardless of size (Eurostat).

Median US developer: $135,980 base wage (BLS OEWS May 2025); roughly $170K to $193K fully loaded with benefits at the US private-industry average of 29.7% of total compensation (BLS ECEC March 2025; loading computed).

Median time to fill a tech role: 56 days US, 85 days Europe (Workable 2023, vendor-reported ATS data).

Source: Eurostat, ICT specialists statistics, June 2025. Eurostat enterprise data covers firms with 10 or more employees; companies smaller than 10 are not in the sample.

One developer is a single point of failure, and the system outlives the project

Which leads to the two findings that, in our reading, do the real work against the build-and-keep-it-in-house model at small scale.

The first is key-person concentration. In a study of 133 widely used open-source systems, roughly 65 percent had a truck factor of two or fewer, meaning the project effectively depends on one or two people Avelino et al., 2016. Internal tools at small companies are more concentrated, not less: they are usually one person's work. And the cost of that person leaving is quantifiable. Case studies at Google Chrome and Avaya measured turnover-induced knowledge loss, files effectively abandoned when their authors left, and found tail losses more than three times expected levels Rigby et al., 2016. Replacing the person costs real money too: the median across thirty academic case studies is 21 percent of annual salary, rising steeply for complex, highly paid roles Boushey and Glynn, 2012, with the SHRM Foundation's research-based guideline putting total turnover costs for skilled positions at 90 to 200 percent of annual salary Allen, SHRM Foundation, 2008.

The second is that shipping is the cheap part. The classic empirical work on software economics found maintenance consuming 40 to 80 percent of lifecycle cost, 60 percent on average, and, critically, that about 60 percent of so-called maintenance is enhancement, adding capability as the business changes, not fixing bugs Glass, 2001. The foundational survey behind those numbers found maintenance at roughly half of total application effort as far back as 1980 Lientz and Swanson, 1980. A system built by an internal generalist who then returns to their actual job, or by a developer who departs in year two, has paid perhaps a third of its lifetime cost and has nobody assigned to the rest. This is how internal tools rot: not dramatically, but by going unowned while the business changes around them.

So the in-house path, summarized fairly: the best theoretical fit, full control, and the right answer for companies large enough to sustain a real engineering organization. Below roughly fifty people, the evidence says the binding constraints are that the talent is structurally inaccessible, the fully loaded cost is disproportionate, the result concentrates in one or two heads, and the majority of the lifecycle cost arrives after the part anyone budgeted for.

---

Path three: custom systems from a specialized external builder

The third path is the least studied, and we will not pretend otherwise: no credible study directly compares outcomes across off-the-shelf, internal build, and commissioned custom build. What exists is theory with a long empirical track record, component evidence, and a recent, well-documented shift in the underlying economics. We take them in that order.

What the theory says

The make-or-buy question is one of the oldest in economics. Coase's answer was that firms exist because using the market has costs beyond the price, and the boundary of the firm sits where internal organization stops being cheaper than transacting Coase, 1937. Williamson operationalized it: the more specific an asset is to your firm, the worse the market serves you and the stronger the case for making rather than buying; generic needs belong in the market Williamson, Nobel lecture, 2009. Applied honestly, this framework cuts both ways and is not a deterministic predictor: a review of the IT outsourcing literature found only about half of transaction-cost-based predictions supported Lacity, Willcocks and Khan, 2011, and in IT specifically, vendors' production-cost advantages, their scale at doing the work, often outweigh the hold-up concerns the theory emphasizes Ang and Straub, 1998.

But notice what the two theories from the first two sections jointly imply. Transaction cost economics says: buy generic, make specific. The resource-based view says: generic cannot differentiate you, only firm-specific resources can. Both point at the same object, the proprietary workflow, the thing your company does differently that customers pay for. For that object, off-the-shelf is wrong by construction (it is built for the average), and the practical question becomes who does the making. The practitioner versions of this logic say the same thing: Martin Fowler's utility-versus-strategic rule is to buy packages and adapt your process for utility functions, and build only what differentiates, with his estimate that the differentiating share of corporate IT is closer to 5 percent than 20 Fowler, 2010. Wardley's mapping tradition reaches the identical prescription along an evolution axis: build the novel, buy products, consume commodities as utilities Wardley, 2015.

The specialized external builder is the market's answer to a company whose differentiating workflow justifies custom systems but whose size cannot justify an engineering organization. It is Williamson's hybrid governance mode applied to software: more specific than the market, less than the hierarchy. The fit argument of the internal build without the requirement to win a structurally inaccessible talent market.

Why this used to be an enterprise-only option

Custom software historically required a team: multiple engineers for redundancy and review, a manager, months of calendar time, and a budget that only made sense amortized over thousands of users. Every component of the capability-gap section above was a fixed cost. A company of twenty could not buy a tenth of an engineering organization, so the choice collapsed to off-the-shelf or nothing, exactly as the adoption data still shows: small EU enterprises employ ICT specialists at one fifth the rate of large ones Eurostat, 2025, and US firms under 20 employees adopt AI at less than half the rate of firms over 250 US Census Bureau, 2026.

What changed is the subject of the next section. But the structural conclusion is worth stating first: when the cost of building and maintaining a custom system falls, the threshold company size at which custom systems make economic sense falls with it. The question is whether the cost really fell, and for whom.

---

What changed: the economics of building software

The evidence that building got faster

The productivity evidence on AI-assisted development is unusually good by the standards of this article, because it includes randomized controlled trials at scale.

The first controlled experiment assigned 95 professional developers a standardized greenfield task; the group with an AI pair programmer finished 55.8 percent faster Peng et al., 2023. That number needs its caveats attached: one well-specified task, freelance developers, a wide confidence interval, and no measurement of code quality. Treat it as an upper bound for the kind of work AI accelerates most. The stronger evidence is the field experiment: 4,867 professional developers at Microsoft, Accenture, and a Fortune 100 company were randomized into Copilot access, and completed tasks rose 26.1 percent, with the gains concentrated among junior developers (27 to 39 percent) and much smaller for seniors (8 to 13 percent) Cui et al., Management Science, 2025. A randomized trial inside Google found roughly 21 percent time savings on an enterprise-grade task, with the authors stressing the wide interval Paradis et al., 2024.

Two structural signals say the input-cost change is showing up in what gets built. A quarter of Y Combinator's winter 2025 batch had codebases roughly 95 percent AI-generated, per a YC managing partner, technical founders choosing generation over typing TechCrunch, 2025. That is one accelerator and an anecdote, not a statistic, and we found no credible analyst quantification of falling market prices for custom software, so we will not claim a percentage. The defensible claim is narrower: the labor input per unit of working software has fallen, on randomized evidence, by double-digit percentages for exactly the kind of well-scoped, greenfield work that small-company custom systems mostly are.

-30%0%+30%+60%

Peng et al. 2023: +55.8% 95 freelance developers, one standardized HTTP-server task; quality not measured. Upper bound for well-specified greenfield work. Study

Cui et al. 2025: +26.1% 4,867 developers at Microsoft, Accenture, and a Fortune 100 firm; juniors +27 to 39%, seniors +8 to 13%; quality unmeasured. CI not displayed (report as published). Study

Paradis et al. 2024 (Google): +21% 96 Google engineers, one enterprise-grade task; interval wide, per authors, who warn against broad generalization. Effect approximate. Study

METR 2025: -19% 16 experienced maintainers, 246 real issues on familiar 1M+ line codebases; participants believed they were 20% faster. CI approximate. Study

METR 2026 update (new cohort): -4% 47 newly recruited developers; original design had selection problems; METR concludes current tools likely speed developers up. Study

Greenfield or well-scoped tasks (solid blue)Enterprise field work (hollow blue)Complex familiar codebases (solid black)

Five studies, five contexts. The spread is the finding: AI-assisted development gains are largest on well-scoped new systems built by people equipped to review the output, and smallest for experts deep in complex existing code. Effects are study-specific and not directly comparable across designs.

45% of AI-generated code samples failed security tests (Veracode 2025, vendor-reported) Source

66% of developers name 'almost right, but not quite' as their top AI frustration (Stack Overflow 2025 survey) Source

Senior developers report shipping 2.5x more AI-generated code than juniors (Fastly 2025 survey of 791 developers, vendor-reported) Source

The evidence that judgment did not get cheaper

The same literature contains the other half of the story, and it is the half that matters most for who should do the building.

The most discussed negative result: METR ran a randomized trial with 16 experienced open-source maintainers working on large, mature codebases they knew deeply, and found that with AI assistance, tasks took 19 percent longer, while the developers themselves believed they had been 20 percent faster METR, 2025. Quote that result only with its sequel: METR's 2026 update on larger cohorts found the slowdown largely gone (a new cohort measured at minus 4 percent with a confidence interval spanning zero), uncovered selection problems in the original design, and concluded that developers are likely sped up by current tools METR, 2026. The honest reading of the pair is not that AI slows experts down; it is that the gains are uneven, smallest where the work is complex and context-heavy, and that practitioners' perception of their own speedup is unreliable.

The quality evidence points the same direction. In a Stanford security study, participants using an AI assistant wrote significantly less secure code and were more confident it was secure Perry et al., 2023. The security vendor Veracode, testing output from over a hundred models, reported 45 percent of AI-generated code samples failing security tests, with no improvement across newer model generations even as functional correctness improved Veracode, 2025, vendor-reported. The code-analytics vendor GitClear, analyzing 211 million changed lines, reported duplicated code blocks growing fourfold in 2024 while refactoring fell by more than half GitClear, 2025, vendor-reported and correlational. Google's DORA research program, surveying the industry, concluded that AI acts as an amplifier: it raises throughput and it raises instability, and which one you get depends on the engineering discipline around it DORA, 2025. Practitioners agree in surveys: 84 percent of developers use or plan to use AI tools, but the top frustration, named by 66 percent, is solutions that are almost right but not quite, and 45 percent say debugging AI-generated code takes longer than writing it would have Stack Overflow, 2025.

One vendor survey result compresses the whole section into a single contrast: senior developers report shipping more than twice as much AI-generated code as juniors Fastly, 2025. The people extracting the most from these tools are the people who least need them to know what correct looks like. AI collapsed the typing cost of software. The judgment cost, architecture, data modeling, security, knowing which almost-right answer is wrong, did not move, and may now bind tighter because the typing no longer hides it.

What this does to the three paths

Put the two halves together and the implication is specific. The cost of producing custom software fell most for well-scoped new systems built by people with the judgment to direct and review the output. It fell least for non-experts, whose null result exists: a randomized trial that gave 640 small-business owners a GPT-4 advisor found no average effect on revenues or profits, with gains for the strongest operators and losses for the weakest Otis et al., 2023. The same conditionality shows up at the firm level: euro-area evidence finds digital technology adoption alone yields close to nothing, with returns concentrated in the minority of firms that pair tools with skills and complementary investment ECB, 2024, and about half of small US firms that adopt AI make no complementary investment at all SBA Office of Advocacy, 2025.

So the technology did not make the three paths converge. It moved the boundary between them. Off-the-shelf is unchanged: you are still buying the average. The internal build still requires the scarce judgment, now with cheaper typing attached. The path whose economics changed most is the third one: a specialist who already has the judgment can now deliver and maintain a fitted system at a small-company price, because the part of the work that got cheap is the part that used to require the team.

---

The objections, taken seriously

An objections section that only contains easy objections is a tell, so here are the strongest ones we found, with the evidence that supports them.

"Off-the-shelf is cheaper and faster." At month one, unambiguously true, and for many systems, permanently true. The counterargument is not that buying is expensive; it is that the price trajectory and the fit costs compound: vendor-reported renewal inflation above 12 percent annually, half of licenses unused by the vendors' own telemetry, and the misfit literature's documented process distortion. But the honest version of the trade-off keeps the first clause: for any process where your company resembles the average company, the off-the-shelf product amortizes its development cost across thousands of customers and you will not beat it with custom anything.

"A small external builder is a risk: bus factor, vendor lock-in." Legitimate, and the key-person evidence we cited against internal builds applies with full force to a bad external builder. A one-person studio that ships an undocumented system on an exotic stack and disappears is strictly worse than good off-the-shelf, and the lock-in is worse too, because at least the SaaS vendor has other customers keeping the product alive. The discipline that answers this objection is structural, not rhetorical: source code and infrastructure owned by the client from day one, documentation written for a successor, boring and widely known technology choices, and architecture designed for handover. Those practices convert builder failure from existential to inconvenient. A buyer who cannot get them in writing should walk away.

"AI makes building so cheap we can do it ourselves." Partially true, and the partial truth is worth taking seriously: a technical founder or a genuinely strong operator with modern tools can now build working internal software that would have required a contractor five years ago, and the YC cohort data shows exactly that population doing exactly that. The boundary is the judgment evidence above. The randomized gains concentrate among people who already know what they are doing; the security and quality failures concentrate where review is weakest; and the null result for non-expert operators is a randomized trial, not an opinion. The honest framing: AI moved the do-it-yourself frontier outward, and for systems that sit on your revenue path, handle customer data, or must survive three years of change, the gap between a working prototype and a production system is still made of expertise.

"Custom systems become unmaintained legacy." The base rates support the worry: maintenance is roughly 60 percent of lifecycle cost on the classic evidence, and most of it is adaptation to a changing business, not repair. But notice whom the evidence actually indicts: any acquisition model where building and owning are separated, including the internal tool whose author moved on. The conclusion we draw is not that custom systems are safe; it is that a custom system without a standing ownership arrangement is a liability on a delay, whoever built it. Maintenance is not the fine print of the custom path; it is the product.

"Adapting to standard software is good for you." The strongest objection, because it is true more often than the custom industry admits. Plant-level evidence shows packaged systems delivering real benefits where processes are interdependent and genuinely standard Gattiker and Goodhue, 2005; large-sample financial research has reported enterprise system adopters outperforming non-adopters on average Hitt, Wu and Zhou, 2002; and SMEs demonstrably waste money customizing against misfits that are not real van Beijsterveld and van Groenendaal, 2016. Your payroll process is not special, and the research says the field has never even managed a head-to-head test proving customization beats adaptation in general Jegorova and Grabis, 2025. The framework below treats this objection as a design input: the default for any non-differentiating process is to buy and adapt.

"The failure-rate literature you just used is about large projects." Correct, and we have tried to use it accordingly: the catastrophic numbers describe enterprise-scale projects, small projects succeed at much higher rates, and we rested the case against small-company internal builds on capability, cost, concentration, and maintenance instead. Readers should apply the same discount to anyone who quotes them a project failure rate without a size qualifier.

---

A decision framework

The evidence above implies a framework, and it does not point every company to the same door. Three questions do most of the work.

Question one: is the process differentiating? Strip it to the test the strategy literature actually supports: do customers pay you, directly or indirectly, because of how you do this thing, and would it hurt you if your nearest competitor did it identically? If no, the analysis is over: buy off-the-shelf, choose the boring market leader, and adapt your process to the tool, because for standard processes the package's embedded assumptions are accumulated industry experience, not a distortion. This is most processes in most companies; Fowler's estimate puts the differentiating share of corporate IT closer to one in twenty than one in five. A company that custom-builds its accounting is paying fit costs for a process where fit has no value.

Question two: if it is differentiating, what is the cost of the misfit? Differentiating processes forced through average-company software pay the costs documented in the misfit literature: imposed workflows, workarounds, spreadsheet shadow systems, and the slow convergence toward operating like everyone else who bought the same tool. If those costs are small, a configurable off-the-shelf product plus disciplined process design may still win, and an honest builder will tell you so. If they are large, the process is a candidate for a custom system, and the question becomes who builds it.

Question three: can you field and keep the judgment internally? Not the typing: the judgment. A company with real engineering leadership, a hiring channel into the talent market, and enough ongoing software work to keep more than two people busy should consider building internally; at that scale the fit advantages are unbeatable and the key-person risk is diversifiable. The data says that describes a small minority of companies under fifty people: one in seven small EU enterprises employs any ICT specialist at all, and one in sixteen even attempts to recruit one. For the rest, the choice on differentiating processes is between a fitted system from a specialized external builder and the misfit costs of the average tool, and the builder option now prices at small-company scale for the reasons the previous section documented.

The same evidence yields the buyer's checklist for that third path, each item answering a documented failure mode: you own the code and the infrastructure (answers lock-in), the stack is boring and documented (answers bus factor), maintenance is a standing arrangement with named ownership, not an option (answers the 60 percent of lifecycle cost that arrives after launch), and the builder can tell you which of your processes do not deserve custom software (answers the incentive problem; a builder who thinks everything should be custom is selling, not advising).

And a closing calibration for all three paths: the firm-level evidence is consistent that tools alone, bought, built, or commissioned, return approximately nothing without the complementary investment in process, skills, and ownership around them. The euro-area estimate of digitalization's average productivity effect is close to zero in the adoption year; the returns live in the minority of firms that do the organizational work. Whatever path you choose, the system is the start of the investment, not the end of it.

---

How this shapes the way we work

We are a specialized external builder, so we have an interest in the third path, and this article is how we manage that conflict: by showing our evidence and keeping the claims inside it.

The research changed how we operate. We turn down work where question one fails, because custom software for a non-differentiating process is a misallocation we would be charging for. We build on boring, documented stacks and transfer ownership of code and infrastructure to the client, because the bus-factor objection is correct and deserves a structural answer. We price maintenance as a standing relationship rather than an afterthought, because the lifecycle evidence says the majority of a system's cost and most of its value arrive after launch. And we treat the AI productivity evidence as our own operating constraint: the tools make our builders faster, but the value we sell is the judgment layer the studies keep finding undiminished, knowing what to build, what not to build, and what almost-right looks like before it ships.

---