writing
Low-Code or Custom Code? A Founder's Guide to Choosing
Low-code and no-code tools are genuinely good now. They're also the source of some of the most expensive rebuilds I get called in to do — the ones where a business outgrew the tool, hit a wall it couldn't customize past, and had to rebuild the thing properly under deadline pressure.
Both of those are true at once. The skill isn't picking a side; it's knowing which situation you're in. Here's the framework I actually use.
What low-code is genuinely great at
Low-code earns its reputation in a few specific places.
Speed to a first version. When you need something working this week to test an idea, pre-built components and visual builders beat custom code every time. For prototypes and proof-of-concept, low-code is usually the right call.
Internal tools. Admin panels, simple workflows, forms over data — the stuff that needs to exist but isn't your product. Building these from scratch is rarely a good use of engineering time.
Letting non-engineers build. When the person who understands the process can assemble the tool themselves, you remove a whole layer of translation and back-and-forth. That's real leverage — as long as it stays inside the lines.
If your need looks like one of those, reach for low-code and don't feel clever about writing more code than you have to.
Where it quietly becomes the wrong choice
Low-code buys speed by making decisions for you. That's the whole deal — and it's fine right up until the decisions it made stop fitting.
The wall shows up in predictable places. Complex or unusual business logic the tool wasn't built for, where you end up fighting the platform instead of using it. Scale — performance and cost on these platforms can turn ugly as volume grows, and you have limited control to fix it. Deep integration with the rest of your systems. And lock-in: when the logic that runs your business lives inside a vendor's tool, moving off it later is a project nobody wants to fund.
The dangerous part is that none of this hurts at the start. It hurts later — usually right when the thing has become important.
The questions I actually ask
When a team is deciding, I push on four things:
- Is this your product, or plumbing? Plumbing can be low-code. The thing customers pay for, and the thing that sets you apart, usually shouldn't be — that's exactly where you need control.
- How weird is the logic? Standard and well-understood leans low-code. Genuinely specific to how your business works leans custom.
- What does this look like at 10x? Not today's volume — the volume that means you succeeded. If the honest answer is "the tool struggles," you're choosing a rebuild, just on a delay.
- How painful is it to leave? If switching costs are low, low-code is a cheap bet. If this tool would end up running something core, the lock-in is the real price, not the monthly fee.
The honest answer is usually "both"
The teams that get this right don't pick one religion. They use low-code for speed where speed is what matters — prototypes, internal tools, the edges — and custom code for the core that has to scale, differentiate, and last. The mistake in both directions is the same: using the wrong tool for the part of the system that matters most.
If you're weighing a build-vs-buy or low-code-vs-code decision you'll have to live with for a few years, that's exactly the kind of call I help founders make before it turns into a rebuild. Let's talk.