No-code or custom software? Where the real line is

When someone writes to us asking for a custom tool, the first question we ask isn't what they want to build. It's what they've already tried and why it fell short.

The useful answer, more often than is good for our business, is that they don't need development at all. A well-set-up Airtable, Notion, or Retool solves a huge amount, costs a fraction, and gets maintained by someone on your team without depending on us. Saying so costs us a project and saves us from a bad one, which is worse.

But the line does exist. This post is about where.

What a no-code tool does better than we do

Let's start with the uncomfortable part. If your case fits inside an off-the-shelf tool, custom development is worse. Not just more expensive: worse.

An Airtable gives you forms, basic permissions, role-based views, automations, a mobile app, and an API — today. We'd take weeks to match that, and once we did, you'd have to maintain it yourself. They, meanwhile, keep improving it while you sleep.

There's an advantage of theirs that almost nobody weighs properly: the cost of changing your mind. In a no-code tool, changing a field or moving a step in the process is done by the person who knows the process, in ten minutes, without opening a ticket. That's worth a lot when you're not yet sure how the thing should work — which is the real situation for most internal processes before they settle down.

If your process still changes every month, you don't have a software problem. You have a deciding problem, and commissioning custom development on top of something undecided is the most expensive way to find that out.

The four things that break a no-code tool

In our experience, it's almost always one of these four. They're not "once you scale": they're concrete lines, and you can feel them.

1. Logic that depends on state, not on the form. No-code tools excel at "if field A is X, do Y." They choke when the rule is "this depends on what happened before, in what order, and what the user did last week." And that distinction is subtler than it looks: at LoverCast we ran into a whole bug from coupling two ideas that looked alike — "don't know" and "empty" — into a single value. A data model that doesn't distinguish those cases doesn't get fixed by any tool: it inherits the problem.

2. Real fine-grained permissions. "Salespeople only see their own clients" — anyone can do that. "Salespeople see their own clients, plus their region's if they're on call, minus the ones currently in negotiation with management" — no tool does that without contorting itself. When permissions stop being a table and become rules, you've crossed the line.

3. Integrations that actually need to be reliable. Connecting two tools to move data once a day is easy. Making sure the order always reaches your ERP, that failures get retried, that nothing duplicates, and that someone finds out when something breaks — that's engineering, and it's exactly where visual glue turns into a system nobody knows how to debug.

4. Volume and latency. This one usually shows up last, and all at once. While the table has ten thousand rows, everything's fine; at a million, the views crawl and you discover the tool was never built for this.

The question that settles it before you spend anything

If we had to pick just one: is the part that makes you different the part that makes you money?

If your competitive edge is in how you buy, how you produce, or how you serve — and the software just tracks it — buy the tool. If your edge is the process, and that process is exactly the one no tool lets you model without torturing it, that's where building the custom tool is justified.

Here's one of our own examples, and it goes against selling ourselves. Carmela Cartonera sells handmade artisanal editions and gives away the works as PDFs. The obvious move would have been to build her a full ecommerce with its own CMS and database. She didn't need it: the catalog fits in the repository, the print runs are small, and the only genuinely dynamic part is payment, which Stripe handles. Publishing a new work is a commit. There's no admin panel because none is needed, and that saves her a monthly fee and a system to maintain.

We built little on purpose. That's the same judgment call we apply when you're the one paying.

How to leave a no-code tool without drama

One more thing, because it's the one almost nobody checks on the way in: how you'll get out.

Before you build your operation on top of a tool, check that you can export the data in a format that actually makes sense, and do it once, for real. It's not paranoia: it's what turns a future migration into weeks of work instead of a rescue mission.

When a project reaches us coming from a no-code tool that fell short, the real work usually isn't building the new thing. It's figuring out what rules were implicit in the automations that nobody documented, and whose day each one of them will ruin.

What we take away from this

• If your process still changes every month, don't commission development: decide first. Software doesn't fix a pending decision, it freezes it.
• The four lines are stateful logic, fine-grained permissions, reliable integrations, and volume. If you haven't hit any of those, stick with the tool.
• Custom development is justified when the part that makes you different is the part that makes you money. If it isn't, buying wins — and we'll tell you so.
• Look at the exit door on the way in. Export your data once before you need to.

If you're on the line and not sure which side you're on, tell us about it. If your case fits inside a tool, we'll say so in an email and save you the project.