When not to build custom software

An engineering shop that always says yes isn't being generous — it's optimising for its own revenue over your outcome. We'd rather lose the occasional brief than build something we don't believe is the right call, so this is the honest version of that filter: the situations where a custom build is the wrong answer, even though we could take the fee.

When an off-the-shelf tool already does the job

The single most common mistake we see operators make isn't choosing the wrong developer — it's choosing to build at all when a configured off-the-shelf platform would have got them 90% of the way there for a fraction of the cost and none of the maintenance burden. Booking systems, CRM, basic e-commerce, standard invoicing: these categories are saturated with mature, well-supported products. If your requirement is genuinely standard, custom is usually the expensive way to reinvent something that already exists and is already debugged.

The tell is simple: if you can describe your requirement using the same words a generic SaaS product's marketing page uses, you probably don't need a custom build for that part. Save the custom spend for the part of the business that's actually distinctive.

When the business model isn't validated yet

Custom software is a bet that the process it encodes is worth encoding. If you're not yet sure the underlying business model works — if you're still testing pricing, still working out which customer segment actually wants this, still iterating on the offer itself — building a bespoke system around that uncertainty locks in assumptions before you've earned the right to lock anything in.

The honest advice here is almost always: validate with something scrappy and manual first, even if it doesn't scale, and come back to us once the process is proven and repeating. A custom build is the right tool for scaling a working process, not for discovering whether one exists.

When the budget doesn't match the ambition

A fixed-scope engagement only works honestly if the scope is realistic for the budget. If a brief describes a full-funnel platform with app layer, CRM integration and an AI content engine, but the budget only really supports an entry-tier website, the honest options are: reduce the brief to match the budget, phase the build across multiple engagements as revenue allows, or wait until the funding is in place. What we won't do is quietly agree to the ambitious brief at the smaller budget and let the corners get cut invisibly during the build — that's how "custom software" earns its bad reputation.

• Phase it. Build the entry tier first, prove it earns its keep, fund the next tier from what it generates.
• Cut the brief, not the quality. A smaller, properly-built scope beats a larger, corner-cut one every time.
• Wait if you have to. A brief that isn't fundable yet is better postponed than half-built.

When you need speed more than you need ownership

Hand-coded builds trade a longer lead time for code you own outright and no theme-tax down the line. If you genuinely need something live next week — a landing page for an event, a stopgap while a bigger build is in progress — a page-builder or template is the honest answer, not a rushed custom build that inherits none of the quality benefits custom is supposed to deliver in exchange for the extra time it takes.

When the relationship doesn't feel right

The clearest signal we're the wrong fit is usually mutual, and usually obvious in the first proper conversation, before any money changes hands.

If a prospective client wants us to commit to a timeline before the brief is properly scoped, or wants pricing before either side understands the problem, that's not always bad faith — but it is a mismatch with how we work, and it's better surfaced on the first call than discovered at milestone two. Equally, if we don't think we're the right specialists for a given sector or technical problem, we'll say so and, where we can, point toward someone who is.

What it looks like when we say this out loud on a call

In practice, this checklist shows up as a short, slightly uncomfortable moment early in a scoping conversation, before either side has invested much time. We ask what's already been tried, what's already running, and how confident the operator is that the underlying offer is one customers actually want at the price being tested. If the honest answers point toward "this isn't ready for custom yet," we say so directly, even though the easier commercial move would be to nod along and start scoping.

We'd rather have that conversation once, plainly, than take a deposit for a build that was always going to be the wrong tool for the stage the business was actually at. Prospects occasionally push back on this — understandably, since a "no, not yet" isn't what they came to the call hoping to hear — but the ones who come back once the underlying question is resolved tend to be exactly the clients a fixed-scope, premium engagement works best for.

Why we publish this

A checklist that occasionally loses us a brief is a strange thing to put on our own site. We publish it because the alternative — implying every brief is a good fit for a bespoke build — is exactly the kind of overselling this whole journal has been arguing against. If your situation matches one of the categories above, the honest recommendation is to solve it a different way first, and come back to us when a custom build is genuinely the right tool for what you're trying to do.