Custom software, no-code or AI-built: how to choose

Choose the cheapest route that can be made safe for the data and permissions the tool will hold, and that a person you can name will still maintain in the years you expect to keep it. Move to the next route when that sentence stops being true. For most functions that means buying a product. For a simple internal workflow it means configuring a platform your team already pays for. It means custom engineering only for a smaller set of cases than the people who sell it, including us, tend to admit.

The new route in the mix is the AI-built app. It has changed the cost of getting a first version, not the cost of owning one. That difference is most of what this article is about.

The last two are the same destination reached at different speeds. Both give you a codebase you own. The hybrid differs only in how the first drafts are produced, and it depends entirely on the review being real. The tools write the code; Anthropic's own security guidance for Claude Code says that you are responsible for reviewing proposed code and commands before approval.

Nine criteria separate the routes. The table gives the shape of each; the sections after it explain the ones people most often get wrong. The cells describe tendencies, not guarantees: a well-run no-code build can beat a careless custom one.

How unusual is the process?

Try to describe your process in the product's vocabulary. If you can, buy it. If you can only do so by inventing steps that exist to correct earlier steps, that is the cost of the product's shape, which our build-or-buy article calls workaround cost. The solar operations case study is the plainest example we have: the existing platform allowed one site per deal, but a rollout across six depots is one negotiation and six roofs, so the team either raised six deals or left five buildings off the system. No amount of configuration fixed a data model that had the wrong noun in it.

Who maintains it, and what happens when they leave?

This is the criterion that decides most outcomes, and the one least often asked. A no-code build is maintainable by an operations person only while that person is there and the logic is legible. Our platform pages say the same thing about automations: rules that only one person understands do not survive that person. An AI-built app starts with a worse version of the problem, because the maintenance knowledge is a chat history. Custom software needs an engineer, either retained or a handover good enough that another one can take over. If you cannot name the person, the route is not finished being chosen.

Data sensitivity and permissions

Ask what the worst realistic leak or wrong number would cost. For an internal checklist the answer is small and any route will do. For customer personal data, money or role-based access, the permission rules have to be enforced where the data lives, not just hidden in the interface. That is the test in our vibe-coding-to-production article: sign in as two users and replay one's request as the other. Platforms enforce their own permission models, which is a strength and a limit, since you cannot add a rule the platform does not offer. Custom engineering can enforce any rule you can state, including in the database, but only if it is built and tested to do so.

Platforms also have a pattern for outside users. Our monday.com and Airtable pages describe portals that show a contractor or client only their own records without a licence each, rather than granting base access so someone can update one field. The fleet order automation we built is that shape: installers see only their own jobs and the board stays closed.

Integrations

List every system the tool must read from or write to, and who is allowed to change each. Each integration is a standing cost, and the cost is largest when several products must behave as one system, which is the integration tax in build-or-buy. SaaS and no-code routes handle common integrations well through connectors. They handle unusual ones badly, or only through an automation layer you then also have to maintain. In the fleet case the client kept monday.com and we built only the gap: a parser, a portal and an SLA engine. That is usually cheaper than a full build, and it is not custom software versus a platform. It is both.

Lifespan

A tool for a single campaign or a one-off migration should take the cheapest route that works, even if that route is untidy. A system you expect to run for years is dominated by maintenance, not the first build, and that moves the maths towards routes you can own and hand over. Be honest about which one you have. Many internal tools were meant to be temporary.

Lock-in, ownership and the exit path

Ask four questions of every route before you start. Where does the data live, and can you get all of it out in a usable form? Who owns the code or the configuration? Can another engineer, or another platform, take over without the original builder? What would leaving cost, in effort rather than fees? The trading ERP exists because the answer to the first question was no: the books sat in a single-machine desktop application whose export produced nothing usable, and building was the way to get them into one place.

For AI builders, check the tool's current terms rather than assuming. Tools differ on whether you can take the project out as a repository, and the answer changes often, so read it for the tool you are considering. Whatever the answer, keep the repository and hosting accounts in your own name. The vibe-coding-to-production article makes the same point.

We do not quote prices in articles, because they change and because the useful comparison is the shape of the cost over your horizon, not today's number. The arithmetic for your own case is in our build-or-buy article. The qualitative shape is below.

Read the rows as defaults to argue with, not rules. The first matching row is usually the one to start from.

• Buy by default assumes a product exists for your category and that its pricing stays sensible. Vendors change both. Check the current pricing page rather than last year's memory of it.
• The hybrid is the claim we are most careful about. We build this way, but we have not measured it as cheaper than other custom builds. AI drafting can produce more code for a reviewer to read, not less, and a reviewer who cannot read the diff makes it worse than a slower route. For money, permission and migration logic, a person writes or approves the tests first.
• No-code platforms run happily for years in the right place. We are paid when platforms run out, so we are more likely to notice the ceiling than a vendor is. Weigh our view of the ceiling accordingly.
• AI builders improve quickly. What we say about their weaknesses comes from our reading of generated code and the vendor guidance we cite, not from a test of every tool, and some of it will date. Read the tool's current export and hosting terms before you decide.
• Regulated data, such as health or payment data, needs specialist assessment whichever route you take. No choice in this article makes an app compliant, and none of it is legal advice.

Whoever you ask, a vendor, a platform consultant or a studio, you will get a better answer from a one-page brief. These six items do most of the work.

1. 01The process, in plain steps, including the exceptions that people currently handle by hand.
2. 02The data it will hold and who may see or change each part. Say which parts are personal, financial or confidential.
3. 03The systems it must read from or write to, and which one is the source of truth for each fact.
4. 04How long you expect to use it, and what would make you retire it.
5. 05The person who will maintain it after launch, by name, and what happens if they leave.
6. 06Your exit: what you would need to take with you if you changed supplier, platform or tool.