Menu

Build vs buy

Custom App, No-Code or Off-the-Shelf: How to Decide

The short answer

Start with what exists. Use off-the-shelf software when a product covers the job and you can adapt your process to it; use no-code when you need something shaped to you but the data and users are modest; use an AI-generated MVP to test an idea fast; and choose a custom build when the software is your product or your edge, or when the others' limits are costing you more than building would [1].

The four aren't rivals so much as stages. Many good custom apps started as a spreadsheet, then an Airtable-style base, then a prototype. The skill is noticing when you've outgrown one.

Updated November 11, 2026 · 18 sources cited

The four options side by side

How the four approaches compare on the things that decide it
Off-the-shelfNo-code / low-codeAI-generated MVPCustom build
What it isA product sold to many customers [2]An app assembled from a platform's blocks [3]Code produced by prompting an AI tool [4]Software designed and written for you
Time to first useFastest: sign up and configureFast: you assemble it yourselfFast to a demo, slower to something dependableSlowest: it has to be designed, built and tested
Fit to your processYou adapt to itGood, within the platform's limitsWhatever you prompt, until it breaksExactly what you specify
Who maintains itThe vendorYou, on the vendor's platformUnclear until someone owns the codeYou or your partner
Ownership and exitYour data, if you can export itYour data; the app logic stays on the platform [5]You have the code, if you can understand itCode and data, if the contract says so [6]
Main riskWorkarounds pile upHitting platform limitsHidden security and quality problems [7]Cost, time and upkeep

A decision framework in six questions

Answer these in order. The first "yes" usually points to your starting point.

  1. Does a product already do this well enough? Try two or three for real, with your own data, for a few weeks. If one works after changing your process a little, buy it. UK government teams are told to look for what exists and decide what to build and what to buy before they commit [1] [8].
  2. Are you still testing whether anyone wants it? Then you need learning, not software. A no-code app or an AI-generated prototype is usually enough to find out [9].
  3. Is it an internal tool with a modest number of users and records? An Airtable-style base with forms, views and automations often serves for years. Check the vendor's published limits on records, automations and API calls against your numbers [10] [11].
  4. Will strangers trust it with money, health or personal data? Then it needs deliberate security and privacy work [12] [13], which points toward custom code reviewed by experienced engineers, or a mature product built for that domain.
  5. Is the software itself what customers pay for, or how you stand apart? Then owning it usually matters, and custom is the default.
  6. Can you fund upkeep after launch? If not, custom is the wrong answer today, however good the idea. Choose the option where someone else carries maintenance.

When each option stops working

Every option has a ceiling. These are the signs you've reached it.

Off-the-shelf has stopped working when

  • Staff keep a side spreadsheet because the product can't record something you need.
  • You pay for several tools and someone copies data between them by hand.
  • The vendor's roadmap and yours have parted ways, and their API can't fill the gap.

No-code (including Airtable-style tools) has stopped working when

  • You are near the plan's record, automation or storage limits, or paying for a tier only to raise them [10].
  • Integrations fail under load because of API rate limits [11].
  • Permissions are too coarse: you can't let a client see only their own records.
  • Nobody can explain how the automations fit together, and a change in one breaks another.
  • People outside your organization need a polished, branded, mobile-friendly experience.

An AI-generated MVP has stopped working when

  • Each new feature breaks an old one, and fixes are guesses.
  • Nobody can say for sure how sign-in, permissions or payments work.
  • Real customer data is going in and the code has never had a security review [7] [14].
  • There are no automated tests, so every release is a gamble.

A custom build has stopped working when

  • Small changes take weeks because the codebase fights back [15].
  • The one person who understood it has left [16].
  • A product now exists that does the same job well, and maintaining yours costs more than switching.

If you're at the ceiling of an AI-built or freelancer-built app, After the MVP covers how to tell whether to refactor or rebuild.

Airtable-style tools: what they're good at

Airtable and tools like it sit between a spreadsheet and a database: tables that link to each other, forms for intake, views for different teams and automations for routine steps. For many small businesses and nonprofits that's the right next step after spreadsheets, and it's cheap to try.

  • Good at: structured records with relationships, simple intake forms, team views, light automation, and getting something useful running this week.
  • Less good at: fine-grained permissions for outside users, complex business rules, high volumes of records or API calls, and a branded experience for customers.
  • Before you commit: check record limits, automation run limits and API rate limits on the vendor's own pages for your plan [10] [11], and confirm you can export everything as CSV.

Hybrid approaches

The choice is rarely all or nothing. Common combinations:

  • Buy the core, build the edge. Use an existing product for accounting or CRM and build a small custom piece on its API for the part that's unique to you.
  • No-code back office, custom front door. Staff keep working in a no-code base while customers use a custom app that reads from it, until volume says otherwise.
  • Replace in slices. Rebuild one part of an old system at a time, routing traffic to the new piece as each is ready, rather than switching everything on one date [17].

Worked example

Worked example

A training provider's course bookings

The situation
An illustrative scenario: a small training company takes bookings by email, tracks them in a spreadsheet and sends certificates by hand. It wants clients to book and pay online and see their own certificates.
The options on the table
  • A booking product with payments built in.
  • An Airtable-style base with a booking form.
  • A custom client portal.
The decision
Trial a booking product for public courses. Use a no-code base for internal tracking. Revisit custom only if corporate clients need a private portal the products can't provide.
What to take from it
Payments and bookings are high-risk to build yourself and well served by products. The unique part (a corporate portal, perhaps) is the only candidate for custom work.

Questions people ask

Is custom app development worth it for a small business?

When the app is how you deliver your service or stand apart, often yes. When it duplicates a solved problem like invoicing or scheduling, usually no: buy the product and spend the money on what's unique [1].

When should I move from Airtable to a custom app?

When you hit published plan limits on records, automations or API calls [10] [11], when outside users need fine-grained permissions, or when automations become too tangled to change safely.

Can an AI-generated MVP become the real product?

Sometimes. Have its security, data model and sign-in reviewed by an experienced engineer before real users depend on it [7]; then decide whether to refactor it or rebuild parts.

What's the difference between no-code and low-code?

No-code tools let you build entirely through visual configuration [3]; low-code tools do the same but expect some code for the harder parts [18].

Will I be locked in to a no-code platform?

Your data can usually be exported, but the app's logic, automations and interface stay on the platform [5]. Moving off means rebuilding those, so check export options before you commit.

The Custom App Development Process, Stage by StageDiscovery, design, build, launch and maintenance, with what the client must decide and deliver at each stage.What Drives Cost and TimelineThe factors that move scope, budget and schedule, and how to write a brief that gets comparable proposals.After the MVP: Technical Debt, Rebuilds and Staying ReliableWhen a prototype or AI-generated codebase needs re-engineering rather than patching, and how to assess technical debt.

Sources

Every numbered claim on this page links here. Each source is public; follow the link to check it.

  1. Choosing technology: an introduction, GOV.UK Service Manual
  2. Commercial off-the-shelf, Wikipedia
  3. No-code development platform, Wikipedia
  4. Vibe coding, Wikipedia
  5. Vendor lock-in, Wikipedia
  6. Do Users Write More Insecure Code with AI Assistants?, Perry, Srivastava, Kumar and Boneh, arXiv
  7. The Technology Code of Practice, GOV.UK
  8. Minimum viable product, Wikipedia
  9. Airtable plans and limits, Airtable
  10. Web API rate limits, Airtable
  11. OWASP Top Ten, OWASP Foundation
  12. Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex
  13. Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions, Pearce et al., arXiv
  14. Technical Debt, Martin Fowler
  15. Bus factor, Wikipedia
  16. Strangler Fig Application, Martin Fowler
  17. Low-code development platform, Wikipedia