Bespoke or off-the-shelf — and when bespoke is the wrong answer

Here is the test. Would a customer ever switch to a competitor because of this component? If not, buy it — authentication, billing, transactional email, product analytics, error tracking, the CRM, the support desk, the data warehouse, the queue. Nobody has ever churned because a login form was insufficiently distinctive. If the answer is yes, build it properly: the workflow that is the actual product, the data model nobody else has, the integration into a system of record you do not control. Everything genuinely difficult about this decision lives in a third category, where the honest answer is that you are choosing which migration to pay for later.

The market has already settled the commodity half, and there is public data on which parts. Eurostat reports that 52.74% of EU enterprises used paid cloud computing services in 2025, and that among the enterprises which reported using paid cloud computing, 85.15% relied on a cloud solution for e-mail, 71.69% for office software, 65.49% for security software, 58.16% for finance or accounting applications, 45.52% for hosting databases, 30.12% for ERP software and 27.91% for CRM software (Eurostat, Cloud computing — statistics on the use by enterprises, 2025 data). Notice the ordering. The closer a category sits to a company's specific way of working, the less of it gets bought ready-made: e-mail is near-universal, ERP and CRM are not. That gradient is the build-versus-buy line, drawn by several hundred thousand enterprises rather than by an opinion.

Payments and billing is the clearest buy case that founders still argue about, so it is worth showing the surface area rather than asserting it. Stripe states that a PCI-certified auditor evaluated and certified it to "PCI Service Provider Level 1," described as "the most stringent level of certification available in the payments industry," and describes infrastructure for storing, decrypting and transmitting card numbers that "runs in a separate hosting infrastructure and doesn't share any credentials with the rest of our services," with card numbers encrypted at rest with AES-256, decryption keys held on separate machines, and access "restricted to a small number of specially trained engineers" reviewed quarterly (Stripe, Security at Stripe, Stripe documentation). You are not going to build that. More to the point, you are not going to want to be audited against it.

The billing logic on top is the underestimated half. The published Stripe Billing feature list names pricing models "for flat-rate, per-seat, usage-based, tiered, variable, and multi-currency pricing," usage-based billing across "daily, weekly, monthly, quarterly, or annual billing periods," automated and customised invoicing, a self-service customer portal, and smart retries — "Schedule payment retries to maximize recovery" (Stripe, Billing, Stripe documentation). Dunning alone, retrying a failed card on a schedule tuned to recovery rates, is a product with a team behind it. Build subscriptions in-house and you ship the happy path in a fortnight, then spend a year discovering proration on mid-cycle plan changes, tax, refunds against partly consumed periods, and the invoice a finance team can actually reconcile.

Authentication is the same shape, and the mistake is subtler, because the happy path really is a weekend of work. The surface area is not the login form. Take the same Stripe documentation as an inventory of what a mature access layer contains: multi-factor authentication including passkeys, hardware security keys and TOTP, single sign-on through SAML 2.0, SCIM provisioning, just-in-time account creation, granular roles for least-privilege access, restricted API keys, access policies that block use from unauthorised locations, and an exportable security history of sensitive account changes. Your first enterprise customer will ask for SAML and SCIM in a security questionnaire, and on that day the gap between a bought identity layer and a hand-rolled one is a quarter of engineering time.

The commoditisation is measurable, and it moves one way. The Stack Overflow 2025 Developer Survey reports 71.1% of respondents using Docker, up 17 points from 2024 — the survey describes it as having "moved from a popular tool to a near-universal one" — alongside 55.6% using PostgreSQL, 43.3% on Amazon Web Services and 75.9% on Visual Studio Code (Stack Overflow, 2025 Developer Survey: Technology). Nobody in that population is writing a container runtime, a relational database or an editor, and every one of those was a bespoke build inside serious engineering organisations twenty years ago. The lesson is not that building is bad. It is that the boundary moves, and this year's differentiator is next year's dependency you should have rented.

Where bespoke genuinely earns its cost, first: the workflow that is your product. If your company exists because a specific sequence of steps is faster, cheaper or more accurate in your hands than anywhere else, that sequence cannot be configured into a generic tool without becoming generic. This is the quiet failure of the well-meaning no-code build — it works, it is cheap, and it produces a business whose core operation is identical to anyone else who bought the same template. Ask what a competitor would have to copy to hurt you. If the answer is a spreadsheet and a subscription, there is nothing there to defend.

Second: the data model nobody else has. Off-the-shelf software imposes a schema, and a schema encodes assumptions about what your entities are. A generic CRM believes in contacts, companies and deals. If your business actually runs on per-branch royalty rules, a claim moving through eleven states with different evidence requirements at each, or an inventory unit that is simultaneously a batch, a location and a compliance record, then every day on the generic schema is a day of translation logic living in people's heads and in spreadsheets. That cost is invisible in a procurement comparison and dominant in operation. Building here is not indulgence; it is refusing to pay a translation tax forever.

Third: integration into a system of record you do not control — the ERP, the ledger, the practice management system, the state-run registry. Prebuilt integrations exist for the popular pairs and stop existing exactly where your business is unusual, which is usually where the value is. This work is consistently underestimated because connecting is easy and the semantics are hard: identity, freshness, idempotent writes and reconciliation, which is the subject of what breaks when AI meets a system of record. Nobody sells you that integration, because nobody else has your particular combination.

The hard middle, case one: buying something you then customise past the point of recognition. This is the most expensive outcome available and it gets chosen by accident. A platform fits eighty percent; the remaining twenty is addressed with configuration; the configuration becomes scripts; the scripts become a codebase — and you now maintain a bespoke system that also carries someone else's upgrade path, version constraints and support boundary. The warning sign is early and specific: when your first serious requirement can only be met by a workaround the vendor documents as unsupported, you are already building, just without the freedom of building. The Government Accountability Office observes in its Agile Assessment Guide that "all too frequently, agency IT programs have incurred cost overruns and schedule slippages while contributing little to mission-related outcomes," against federal IT spending of more than $90 billion a year (US Government Accountability Office, Agile Assessment Guide, GAO-20-590G, September 2020). A large share of that is not greenfield construction. It is enterprise software bent toward a shape it was never built for.

Case two: buy the primitives, own the policy. Multi-tenancy and permissions are the standard example. Buy the identity provider, the session handling and the token infrastructure; do not buy your authorisation model, because who may see which record is a statement about your customers and your contracts rather than a product feature. The same split governs reporting. Buy the warehouse and the dashboard tool for the questions everybody asks; build only the analytics that *is* the product — the metric your customers log in to see, which has to be correct, explainable and yours.

Case three, which resolves most arguments: buy now, and make replacing it cheap. The question is usually posed as permanent when it is really about sequencing. Buying first is nearly always right while a hypothesis is unproven, because the cost of being wrong is a subscription rather than a quarter. Two decisions determine whether you can leave later: own your data model rather than adopting the vendor's, and put the vendor behind an interface you wrote, so swapping it is a new implementation of your own contract rather than an excavation. Teams that do both replace tools routinely. Teams that do neither describe themselves as locked in, which is not something the vendor did to them.

It would be dishonest to publish this without naming the conflict. We are a bespoke MVP development company. We are paid to build, so every buy recommendation above costs us revenue — weigh advice from a builder accordingly, including this advice. The structural check we can point at rather than promise is the shape of our own first engagement: a two-week readiness assessment at one fee agreed before it starts, which hands back a prioritised roadmap that is yours to keep whether or not you build anything with us. A firm that only earns by building has no mechanism for telling you not to. A firm whose first deliverable is a document does. We also publish no rate card on pricing, precisely because a rate multiplied by an unscoped guess is how a build nobody needed gets approved.

Two real shapes from our own work show where the line usually falls, and neither is a pure answer. An agency operating system we built bought its subscription billing from Stripe and its scheduling from Google Meet and Calendar, then built the multi-tenant workflow that was the actual product: projects tied to clients and teams, per-service pricing, digital contracts, invoicing and an admin-trained knowledge assistant (Gigbase). A retail point-of-sale system bought its storefront connections from the Shopify, WooCommerce and Magento APIs and its shipping from logistics APIs, then built barcode-accurate stock across multiple warehouses with linked customer and supplier ledgers (Orbix 365). In both, the bought parts are the ones a competitor also buys, and the built parts are the ones a competitor would have to reproduce.

The practical version is three questions. For every component: would a customer switch vendors over it? No means buy, and the burden of proof for overriding that sits with whoever wants to build. If you are buying: what does the exit look like? Name the data you would extract and the interface you would re-implement; if you can describe neither, the real cost of the subscription is not the subscription. If you are building: what is the one sentence that says why nobody sells this? Our data model, our workflow, our integration is a build case. Wanting control is how a team ends up maintaining a worse version of something they could have rented.

One closing correction to a common instinct. The cheapest first version is not the one with the least bespoke code; it is the one with the least code of any kind, bought or written, that still tests the commercial question. Those are different targets and the second is the useful one. What an MVP build actually costs does the labour arithmetic that makes the trade concrete, enterprise AI: build, buy, or assemble works the same boundary for AI systems, and the criteria for judging any top saas development company include a direct test for this: ask what they would remove from your scope, and see whether the answer includes something they would otherwise have billed you to build.