What No-Code App Builders Are Actually Good For

Over the past year I have shipped a growing suite of real web applications on AI-assisted app platforms. Onboarding flows, assessments, member tools, internal dashboards. Real auth, real data, real users logging in and doing real work. I have also hit the walls, hard enough to know exactly where they are.

That second part matters. Most of what gets written about these tools comes from one of two camps. The people selling them will tell you they can do anything. The developers dismissing them will tell you they are toys. Neither camp is shipping on them every week. I am, and I have no stake in either story, so consider this a field report.

Here is my honest map.

How I ended up here

I have spent two decades in communications work: brand, video, live production, web, and the endless operational glue that holds organizations together. For most of that time, when a ministry or a small business needed software, the honest answer was that they could not afford it. Custom development was a five-figure conversation before anyone wrote a line of code. So the need got met the way small organizations always meet it: a spreadsheet, a binder, or a person who just remembered everything.

I have watched a volunteer scheduling system live inside one woman's head for years. She was excellent. She was also a single point of failure, and everyone knew it, and nobody could do anything about it because the alternative was software nobody could pay for.

That is the gap these platforms actually fill. Not "replace your engineering team." Most of the organizations I serve never had an engineering team. The realistic alternative to a platform-built app was never a custom app. It was nothing.

When I launched my consulting practice in 2025, I decided to test that proposition seriously instead of theoretically. Build real things, put real users on them, and find out where the edges are. A year later, here is what I know.

Where they shine

Internal tools and workflows. The unglamorous middle of every organization: intake forms, review queues, directories, checklists with state. This is the layer that used to be a spreadsheet pretending to be an app, and it is where these platforms are almost unreasonably good.

One example from my own work, kept generic on purpose: an organization needed a way for submissions to come in, get reviewed by the right person, get approved or sent back with notes, and get tracked so nothing fell through. Before, that was an email thread and a shared spreadsheet, and things fell through constantly. The platform version took a few days to build. It has a form, a queue, statuses, permissions, and a record of who did what. Nobody would call it impressive software. Everybody who uses it calls it a relief.

That is the pattern. The value is not that the tool is sophisticated. The value is that the process finally has a home.

Structured flows. Onboarding sequences, applications, assessments that score responses and route people somewhere based on the result. I have built several of these now, and the platforms handle the three ingredients well: forms that collect clean data, data models that store it sensibly, and auth so the right people see the right things.

That trio, forms plus data plus auth, covers a shocking share of what small organizations actually need. Most requests that arrive sounding like "we need an app" decompose, on inspection, into exactly those three things arranged in a particular order. When that is true, the platform route is not a compromise. It is simply the correct size of solution.

Prototypes that become products. This one surprised me. I expected the prototype-to-production line to be a hard border: sketch it on the platform, then rebuild it properly. In practice, several things I built as a demo are in production today, because the platform was solid enough to just keep going. The auth was real auth. The database was a real database. There was no moment where continuing forward was worse than starting over, so we continued forward.

The old model was that prototypes were disposable by nature. The new model is that a prototype is a product that has not been asked to grow yet. That changes how you scope early conversations, because "let me mock that up" and "let me build that" are now sometimes the same sentence.

It also changes the politics of getting things approved, which nobody talks about enough. In organizations that run on committees, and I have served plenty, the difference between presenting a slide about a proposed tool and handing people a working link is the difference between a quarter of deliberation and a ten-minute yes. A working thing collapses the discussion from "should we do this someday" to "should we keep this thing that already exists." Those are very different meetings, and only one of them ends before lunch.

Where they stop

Complex logic and edge cases. The first 90 percent arrives fast, sometimes embarrassingly fast. The last 10 percent, the weird permission case, the integration that behaves differently on Tuesdays, costs real engineering thought, and sometimes the platform simply will not bend.

Here is the shape of the problem. The platform is opinionated. Its opinions are what make the first 90 percent fast. But when your requirement disagrees with its opinion, you do not get to have a conversation about it. You either restructure your requirement to fit the platform's worldview, or you bolt on a workaround that you will be explaining to someone for years, or you accept that this particular feature is not happening. I have done all three. The skill is knowing early which features live near an opinion boundary, and steering the design away from the cliff before anyone falls off it.

Anything performance-critical. Heavy media processing and high-traffic public products still belong on custom builds. I say this as someone who spent twenty years in video production and knows exactly how much abuse rendering and encoding inflict on infrastructure. If your application's core job is crunching large files, serving spikes of anonymous traffic, or shaving milliseconds because milliseconds are the product, you have left the platform's home territory. It will not fail politely. Build custom.

Portability. Know going in: you are renting the foundation. The platform hosts your logic, your data model, and your interface in a form that mostly cannot be picked up and carried elsewhere. Maybe that never matters. Platforms rarely vanish overnight. But pricing changes, features get deprecated, companies get acquired, and your risk tolerance should be set before you build, not after.

My hedge is boring and effective. Keep your data exportable, and actually run the export once in a while to confirm it works. Keep your logic documented outside the platform, in plain language a future builder could follow: what the app does, what the rules are, what routes where. If I ever have to rebuild, I lose the implementation. I do not lose the thinking. The thinking was always the expensive part.

The questions I ask before starting

After a year of this, my intake conversation has settled into a few questions that sort projects quickly.

What was the realistic alternative? If the honest answer is a spreadsheet, a paper form, or continuing to do nothing, the platform is probably right. If the answer is "we budgeted for custom development," the calculus is different.

Is the app the product, or does the app support the product? A booking tool that supports a photography business can live on a platform happily. If the software itself is what customers are paying for, its performance and polish are your brand, and you should own the foundation.

Where are the edge cases hiding? I ask clients to tell me about the exceptions before we talk about the happy path. Two or three hairy exceptions are fine. Fifteen means the logic is the project, and the platform will fight us.

Who maintains this in two years? If the answer is "whoever is around," the platform's simplicity is a feature that outranks almost everything else. Handing off a platform app is dramatically easier than handing off a codebase.

The rule I use

Build on the platform when the alternative was a spreadsheet, a paper process, or nothing. Go custom when the app is the product and its performance is the brand.

And either way, ship the small version this week instead of describing the big version for a quarter. I have sat through too many planning cycles where the deck about the future application consumed more hours than the first version of the application would have. The small shipped version does something no document can do: it generates reality. Users touch it and tell you things. Data accumulates and surprises you. Half the features in the grand plan turn out to be unwanted, and the feature everyone actually needed was never in the plan at all.

Momentum teaches you more than planning does. That was true when I was producing live events, where the show goes on at 10 a.m. whether the plan is finished or not, and it is true in software. These platforms' deepest value is not that they make building cheap. It is that they make starting cheap. The organizations I work with do not fail because they chose the wrong technology. They fail, when they fail, because they waited, and the waiting was free right up until it wasn't.

Pick the small real thing. Build it this week. Let it teach you what to build next.