Off-the-shelf or custom: how to decide without guessing

Not every software decision deserves a custom build. This is a guide to recognising the ones that do — and to the middle path that gets you there without betting the business on a rewrite.

Owner-operators usually ask us the buy-versus-build question in a form that already contains the answer they are hoping for: "everyone says we should just use the platform — is that mad?" Often it is not mad, and we say so. The shelf product is the right call more often than a studio that sells builds would like to admit.

But there is a recognisable set of conditions where the shelf product quietly becomes the more expensive option, and you can spot them before you spend anything. This piece is about what those conditions are, what the middle path looks like when only one part of your stack is wrong, and how to make the call without building a spreadsheet full of numbers you made up.

Start from "buy"

The default should be to buy. Payroll, card processing, email delivery, tax filing, telephony, hosting — these are the same problem for everyone, they are heavily regulated or heavily commoditised, and someone else's roadmap is doing work you would otherwise have to fund. The cost of being wrong about a subscription is a cancellation.

The honest test is a language test. If you can describe what you need without using a noun specific to your trade, buy it. "Send transactional email" is a bought problem. "Turn a room measurement into boxes, then into a price with waste applied" is not, because "waste factor" is a flooring noun and no general ecommerce platform has a field for it.

Worth saying plainly: custom does not mean from scratch. Nearly every system we have built sits on bought parts. Stripe takes the card, Twilio carries the call, Postgres holds the rows, Railway runs the containers. What gets built is the part in the middle that nobody sells — and that is the only part you are paying to have specified from nothing.

The four conditions that flip the arithmetic

1. Your price is a calculation, not a field

Flooring does not price like retail. Customers buy area, suppliers sell boxes, and the two only meet after coverage, waste factor and product type have all had a say. On the legacy WooCommerce store behind Shopflooring, that arithmetic lived in thousands of lines of bespoke theme code bolted onto the storefront — which is what a price field looks like once reality has finished with it.

The rebuild made the calculation the product: room dimensions resolve to linear feet, to boxes, to square footage, to a priced estimate, with the waste factor applied before the box rollup rather than bolted on at checkout. Twenty-plus supplier price lists were normalised into one schema, with density and weight calibrated per category so freight quotes stopped being guesses.

Distributor OS has the same shape one layer up: trade tiers with markup and margin held apart in the pricing model rather than conflated, which is a distinction most catalogue tools do not make because they were never asked to.

The tell is easy to check. If someone in your business keeps a spreadsheet that corrects the software's number before it reaches the customer, that spreadsheet is your real pricing engine, and you are paying a subscription to a system that cannot hold it.

2. A data model the vendor will not support

Contractor OS has forty-five tables in its domain model: leads, estimates, jobs, change orders, purchase orders, bills, expenses, timesheets, invoices. Every financial document — one hundred per cent of them — posts a balanced journal entry to a real general ledger, and there are zero floating-point money values anywhere in it, because money is held in integer cents.

No vendor ships that, and the reason is structural rather than lazy. The noun "job" sits between CRM and accounting, and neither category wants to own it. So contractors end up running their money across four tools that disagree: a CRM for leads, a spreadsheet for estimates, a job folder for costs, and an accountant who finds out in March.

The tell here is a join maintained by hand. A job number typed into three systems. A month-end where somebody reconciles two reports that should have been one query. Distributors hit the identical wall from the other side — a public store, a trade portal, a warehouse tool and a CRM bought separately, each with its own idea of what a customer and a price are, and reconciling them becomes a full-time job that produces no revenue.

3. Per-seat cost at your headcount

We are not going to hand you an industry benchmark for where per-seat pricing crosses over, because we do not have one and the figure you would find online is somebody's marketing. The shape is what matters, and both numbers you need are on documents you already own. Subscription cost scales with people; build cost scales with scope. Two lines, different slopes, and where they cross depends on your headcount and your vendor's price list.

The version that catches operators out is the cheap seats. Field crews, seasonal staff, the dealer who logs in twice a year, the person who reads one screen a month. Contractor OS names seven organisation roles in its schema — owner, admin, project manager, estimator, accountant, field and viewer — and it is worth checking what your vendor charges for the last two.

The multi-entity version is worse again. Business OS exists because eleven businesses on eleven stacks meant eleven logins, eleven bills and no consolidated view. It now runs one hundred and seventeen workflows across those eleven businesses behind a single identity provider, with nine thousand-plus subscribers on infrastructure we own rather than rent.

4. The integration tax

Integrations get quoted as one-off work and then behave as an ongoing liability. Every connector is a promise to keep up with somebody else's API.

The tax shows up as middleware subscriptions, an automation bill that grows with task count, and a person whose morning starts by checking that last night's sync ran. It is real work either way: Asisly reaches eighteen third-party connectors spanning calendar, payments, point of sale, accounting, CRM, field service and ecommerce, which is what meeting small businesses where they already are actually costs. Norpex runs five always-on automations. Trend-POD runs fourteen production workflows with exactly one human approval gate among them.

The point is not that automation is free. It is that when the integrations are the system, buying them one connector at a time from three vendors is the expensive way to own something you have already decided to depend on.

Choosing the horizon you compare over

Long enough that the second round of renewals, the second round of seats and the second API migration have all shown up. Short enough that you can still remember what you assumed when you wrote it down. Stretch it further and you are writing fiction; cut it shorter and you are flattering the build.

The middle path: replace one piece at a time

You rarely have to answer the whole platform question at once. The more useful move is to strangle the incumbent: leave it running, build one well-bounded piece beside it, route that piece's traffic away, and repeat only if the next piece earns it.

Atelier is the clearest wedge we have built. It embeds with one iframe tag and auto-ingests a catalogue from any Shopify, WooCommerce or plain JSON feed. The storefront stays exactly where it is; the only thing replaced is the part that was losing the sale at the sample chip. Behind that one tag: six independently refinishable surfaces, sixteen procedural floor materials, one hundred per cent of the segmentation running in the visitor's own browser, and real area derived from a perspective homography, so the estimate carries a ten per cent waste factor rather than a shrug.

Two rules keep this from being mere postponement.

Pick the piece with the sharpest edge. Not the biggest, not the oldest. The one where the manual spreadsheet lives, or where the same record gets typed a second time. Those boundaries have already been drawn by your staff; you are only making them official.

Make the eventual cutover a work item, not a leap of faith. When Shopflooring finally moved off WordPress, thirty-six thousand seven hundred and eighty-six legacy URLs had been mapped to live destinations before the DNS changed — over twenty-three thousand of them redirecting straight to the same product, the rest to a search or brand landing that had been checked to answer, three hundred for three hundred against production. That is what makes a replatform boring, which is the correct ambition for a replatform.

The middle path compounds, too. Norpex reused the storefront architecture proven on Shopflooring, so the second marketplace cost a fraction of the first. The Growth Engine build kept its Next.js application as the source of truth and demoted the workflow engine to a stateless task runner called by webhook — cheap tooling doing what it is good at, with the state living where it is owned.

What you actually own

The last row is the one to read twice, because it is the row people skip when they get excited about the other four. Asisly carries seventy versioned migrations, six hundred and forty-three backend tests and thirteen scheduled jobs on a quarter-hour cadence. That is not a warning; it is what "you own it" looks like written out honestly.

Ownership matters most for the things that are expensive to rebuild, not the things that are expensive to buy. Business OS deliberately keeps the subscriber list and the conversation history on owned infrastructure, because those are the two assets a vendor change makes you rebuild from nothing. Toolkit binds to loopback by default and deletes everything an hour after processing — ownership as a compliance position. Alam runs one agent loop across eight-plus model providers at a floor cost of zero on local hardware — ownership as a refusal to accept one vendor's model as a dependency.

How to decide without a spreadsheet full of guesses

Four questions. Every answer already exists inside your business, and none of them ask you to forecast anything.

1. Can you write your price as a formula? Count the inputs. One input fits in a field. Two or more does not, and the gap is being closed by a person.
2. Name the nouns your business runs on. Job. Dealer tier. Box. Load. Which of them has no table in the software you are already paying for?
3. Does your bill scale with people or with work done? Put last year's invoice next to last year's headcount. You do not need a model; you need two numbers you already have.
4. Where does a record get typed twice? Every one of those places is an integration you are already paying for, in salary, at the worst possible exchange rate.

One or two yeses: buy, and spend the saved money wiring it up properly. Three or four: at minimum take the middle path, starting with whichever question produced the loudest yes.

Then stop forecasting and price one slice. Build the smallest piece that carries the whole mechanic — the calculation, the ledger posting, one portal for one role — and look at it. Our Build engagements run in weekly increments against a proven slice for exactly this reason: the estimate for the remaining work gets better once the first piece exists, and it never gets better on paper.

The question we ask on the first call

Not "what do you want to build". It is "what does somebody in your business correct by hand every week?" The answer is usually a spreadsheet, and the spreadsheet is usually the brief.

If you would rather have a second opinion than a pitch, the brief walks through the shape of what you are running and then names which of the systems we have already built resemble it — including, fairly often, the answer that you are early and should buy something for now. What those systems actually do is on the systems index; what an engagement costs is on engage.