If your product is forms, records, and notifications, use no-code. If your product's value is in logic, scale, real-time behaviour, or deep integration, build it custom. That rule covers most cases, and I'm aware that half of it argues against hiring me.

I'd rather say it clearly, because the alternative — founders spending $30,000 on a custom build of something Airtable and a form builder would have done in a fortnight — is bad for them and eventually bad for me. This is one part of the founder's guide to building an MVP.

What no-code is genuinely good at

Modern no-code and low-code tools are far better than their reputation among developers suggests. They're excellent when your product is fundamentally:

• Data in, data out. Someone submits information, it's stored, someone else reviews it.
• A workflow between people. Requests, approvals, assignments, status changes.
• A directory or catalogue. Listings with search and filters over a few thousand records.
• A booking or scheduling layer. Calendars, slots, confirmations.
• An internal tool. Anything where the users are your own staff and the UI just has to work.

If that's your MVP, no-code will get you live in weeks rather than months, for a fraction of the cost, and — crucially — you can change it yourself. That last point is underrated. Being able to adjust your own product without booking a developer's time is enormously valuable in the first few months, when you're changing your mind constantly.

Where no-code actually breaks

Not "it doesn't scale," which is the lazy version. Specifically:

Complex logic. Once your rules involve many interacting conditions, no-code builders become genuinely harder to work in than code. The logic is spread across screens and automations with no way to search it, review it, or test it properly. Founders hit this wall and assume they've done something wrong. They haven't — it's the tool's ceiling.

Performance at volume. Fine at thousands of records. Not fine at millions, or at complex queries across several large tables. The wall here is real and arrives abruptly.

Real-time behaviour. Live collaboration, instant sync between devices, anything where two users need to see the same changing state at once. Some platforms approximate this; none do it well.

Deep integration. Talking to a third-party API that isn't in the platform's connector list, or an existing system with a non-standard interface, ranges from awkward to impossible.

Anything genuinely novel. If the core of your product is a thing nobody has built before, it isn't going to be a feature of a general-purpose builder.

Per-user economics. Platform pricing often scales with records, users, or automation runs. At small volumes it's cheap. At scale it can become a meaningful line item, and unlike hosting, you can't optimise it — you can only migrate off it.

Where custom code earns its cost

Custom is the right answer when:

• The logic at the heart of the product is the product.
• You expect volume that no-code pricing or performance won't survive.
• You need real-time sync or offline behaviour.
• You're integrating with systems that have no off-the-shelf connector.
• You need control over data handling for compliance reasons.
• The product needs to be an asset — something with a repository, a commit history, and portable value.

That last one matters more than founders expect during diligence. A product built on a proprietary platform is harder to value, harder to audit, and harder to move.

"Start no-code, rebuild later" — smart or trap?

Both, depending on one thing: whether you'd be rebuilding from a position of knowledge or from a position of panic.

It works when you use no-code deliberately as an experiment, keep your data in a structure you could export, and rebuild once you know what the product actually is. You'll build a much better custom product afterwards, because you'll have real usage data instead of guesses. The rebuild is cheaper than the original custom build would have been, because you're no longer designing blind.

It fails when the no-code version succeeds faster than you planned, and you're now trying to re-engineer a live product with real customers on it while it's on fire. Migration under load, with users you can't lose, is one of the more stressful projects in software.

The practical hedge: from day one, be able to export your data in a clean, structured form, and know roughly what a rebuild would involve. If you can answer "if this takes off in six months, what does moving look like?" you're using the strategy. If you can't, you're relying on it not working.

The AI-built option

There's a third path now — founders building with AI coding tools themselves, or hiring someone who leans on them heavily. Worth being straight about:

AI genuinely accelerates the parts of software that are patterned — CRUD screens, forms, standard integrations, boilerplate. That's a real productivity gain and it's part of why build costs have come down.

What it doesn't replace is judgment about system design, handling messy requirements, debugging production problems, and being accountable when something breaks at 2am. If you're evaluating someone who's clearly AI-assisted, that's normal and fine — the question is whether they understand what they shipped. I've written more on where that line sits in will AI replace developers.

The failure mode to watch for: a build that demos beautifully and cannot be extended, because nobody — including the person who delivered it — knows how it works.

A decision table

That last row is the one worth taking seriously. A landing page and twenty customer conversations frequently answer the question for the price of a domain name.

How to have this conversation with a developer

Ask directly: "Is there an off-the-shelf way to do this that doesn't involve hiring you?"

A developer worth working with will give you a real answer. If the honest answer is "yes, and here's what it would cost you," you've learned something valuable about the project and about them. Someone who insists custom is the only option for a straightforward CRUD app is either inexperienced or selling.

If you want that question answered honestly about your own idea — including the version where the answer is "you don't need me yet" — get in touch.