Custom Web App Development vs Off-the-Shelf SaaS

Almost no custom web app development starts with a specification. It starts with a spreadsheet that somebody built to track one thing, which grew a second column, then a tab, then a formula only one person understands. Three years later that file holds the schedule, the pricing and half the customer records, four people edit it at once, and nobody can say with confidence which copy is current.

That is the real decision point, and it is not the one most build versus buy articles address. You are not choosing between a blank page and a product. You are choosing between three routes out of a working but fragile process: buy a product, assemble something in a no code platform, or commission software shaped to the way you work.

Should you build a custom web app or buy SaaS? Buy, unless at least two of three conditions hold: the process is a competitive differentiator rather than an overhead, no product fits it without distorting how you work, and the integration work is the bulk of the job. If only one holds, a product plus configuration is almost always cheaper. A bespoke build also carries an ongoing cost floor of roughly 15 to 20 per cent of the build price every year, forever.

The Spreadsheet That Became Load Bearing

The pattern is specific enough to name, and naming it is usually how a team recognises itself.

It begins with one person and one purpose. Someone needs to know which jobs are booked this week, so they open a sheet. A second person needs to read it, so it moves to a shared drive. Then a third needs to edit it, so now people type into the same cells at once. Then a tab per month. Then a lookup against a second file. Then a macro, written by a contractor who has since left.

The tells are consistent. The file has a date and a version suffix in its name. There is a master copy and everyone knows who holds it. Onboarding a new starter means being shown the file rather than being told the process, because the process is not written down anywhere else.

By this point the spreadsheet is not a document. It is an application with no access control, no audit trail, no validation, no backup policy you would defend, and one maintainer. It works, which is exactly why nobody has replaced it, and it is also why replacing it is now expensive.

What the Status Quo Actually Costs

Nobody quantifies the spreadsheet, so it looks free. It is not, and the arithmetic is easy to run for your own business.

Start with re-keying. If two people each spend 45 minutes a day moving data between the sheet, the accounting package and a shared inbox, that is seven and a half hours a week, or about 340 hours across a working year of 45 weeks. At a fully loaded GBP 22 an hour you are spending around GBP 7,500 a year copying numbers between screens, and that buys nothing except the chance to make a typing mistake.

Then add reconciliation, where somebody checks the sheet against the source of truth monthly and spends half a day deciding which version is right. Then add errors caught late: the quote sent at last month’s price, the job double booked, the renewal missed. Each is a small number and an annoyed customer, and none appear in any budget line.

Then add key person risk. One person understands the formulas, and when that person is ill, on holiday or gone, the process degrades to guesswork.

Personal Data in a Spreadsheet Is Still Regulated Data

If the file holds names, contact details, staff records or client information, it is personal data and the UK GDPR applies to it exactly as it would to a database.

The ICO is direct about what that requires. Its guide to data security states that a key principle of the UK GDPR is that you process personal data securely by means of appropriate technical and organisational measures, and that those measures must ensure the confidentiality, integrity and availability of your systems and the personal data within them. A spreadsheet on a laptop has no row level permissions, no retention rule and no record of who read what, and it copies itself in full every time somebody emails it.

The consequences are not theoretical. In October 2024 the ICO fined the Police Service of Northern Ireland GBP 750,000 after hidden data in a spreadsheet released under a freedom of information request exposed the surnames, initials, ranks and roles of all 9,483 PSNI officers and staff. The enforcement notice cites Articles 5(1)(f), 32(1) and 32(2). Without the ICO’s public sector approach the fine would have been GBP 5.6 million.

Every organisation running a process on spreadsheets has a worksheet like that somewhere.

Buy the Product: When SaaS Is Obviously Right

This is the answer most of the time, and it deserves to be argued first rather than dismissed in a closing paragraph.

If your process is a common one, the product exists, and it is cheaper than anything you could build. Payroll, expenses, helpdesk ticketing, appointment booking, electronic signature, bookkeeping, applicant tracking. Somebody has spent a decade and a large engineering team on the edge cases you have not encountered yet: the leap year bug, the VAT rate change, the refund that arrives after the period close.

You are also buying labour you would otherwise pay for. The vendor carries the uptime, the security patching, the browser churn, the accessibility work and the compliance evidence your clients ask for. None of that shows up as a feature, and all of it is real money.

The honest test is not whether the product does everything. It is whether it does the important 80 per cent without forcing you to change anything you care about. If the only mismatch is that your team says “job” and the software says “ticket”, buy the software and change the word.

The Three Conditions That Justify Custom Web App Development

A bespoke build is justified by strategy, not by irritation. There are three conditions that genuinely support one, and the useful rule is that you need at least two of them. One condition on its own is nearly always cheaper to solve with a product plus configuration. The same test applies at enterprise scale, which our CRM and ERP build versus buy guide covers at a different order of magnitude.

The Process Is a Differentiator, Not an Overhead

Ask what a customer would notice if the process got twice as good. If the answer is nothing, it is overhead and you should buy it, because payroll being excellent wins you no business. But a specialist installer whose scheduling logic squeezes an extra job into every van’s day, or a lender whose underwriting rules are its actual product, is running competitive advantage through that software. You cannot buy an advantage your competitors can buy at the same monthly price.

No Product Fits Without Distorting the Process

Every product encodes assumptions about how work flows, and the tell that they are wrong for you is that adopting the product would require you to stop doing something profitable. If your business quotes on a basis the product cannot express, and quoting that way is why customers choose you, the product is asking you to become more ordinary in exchange for a licence fee.

The Integration Surface Is the Actual Work

Sometimes the interesting part is not the screens at all. It is pulling stock from one system, prices from a second, engineer availability from a third, and writing the result into a fourth. When most of the effort is integration, the user interface is a thin layer over your own plumbing, and a product’s built in screens are the part you need least. This is the condition most often underestimated, and it is where the middle trap lives.

The Trap in the Middle: Buying, Then Building Anyway

The most expensive outcome is neither route taken cleanly. It is buying a product because it looked cheaper, then spending more bending it to your process than a bespoke build would have cost, and still paying the licence.

It happens gradually and every individual step is defensible. The product does not fit, so you engage an implementation partner. The partner writes configuration in the vendor’s proprietary scripting layer, which is code, but it does not feel like code because it lives inside the product. Then you need it talking to two other systems, so you buy an integration platform. Then the vendor ships a major version and your customisations need regression testing.

At that point you have all the costs of custom software and none of the ownership: a codebase you cannot read, hosted somewhere you do not control, written in a language that exists in one product, maintained by a partner whose day rate is now a line in your budget. Our guide to custom software development cost covers how those numbers accumulate.

Warning Signs You Are in the Trap

The trap is easier to detect than to escape, and the signals are unambiguous once you look for them.

• The implementation partner’s fee is larger than the first year’s licence fee.
• Somebody’s full time job is effectively administering one product.
• You have written logic in the vendor’s proprietary scripting language, and nobody outside your company can read it.
• Every vendor upgrade triggers a regression test of your customisations, so you defer upgrades.
• You pay for an integration platform that exists only to keep this one product supplied with data.
• You maintain a shadow spreadsheet alongside the product, because the product cannot express something you need.

That last one is the clearest. If the spreadsheet survived the software purchase, the software did not solve the problem.

No Code and Low Code as a Serious Third Route

The no code versus custom question deserves better than a footnote, because for internal tools development the low code platforms are frequently the correct answer and they are not a toy.

Platforms like Airtable, Retool and Microsoft Power Apps let you build a real multi user application with a database, forms, permissions and automations, in days rather than months, without hiring anyone. They handle hosting, backups, authentication and mobile layout. For the specific job of getting a load bearing spreadsheet into something with proper access control and an audit trail, they are frequently the fastest route to a large risk reduction.

They are also priced per seat, which is the fact that determines whether they remain the right answer as you grow.

Where No Code Genuinely Wins

It wins when the shape of the problem is records, forms, views and simple rules: a register of assets, an approvals queue, a client onboarding checklist, a room booking system. It wins hardest when the person who understands the process can build it themselves, because the requirements never have to survive translation into a specification and back.

It also wins on time to value. A working tool in two weeks that is used every day beats a perfect one in six months that is still in design, and the built version teaches you what the requirements actually were.

Where No Code Hits a Wall

The wall is usually one of five things. Performance at real row counts, once a view has to filter hundreds of thousands of records. Permissions with any real complexity, such as row level rules depending on the record’s state and the viewer’s team. Transactional integrity, where two things must both happen or neither must. Testing and version control, because there is often no way to review a change before it goes live. And anything with a genuine state machine, where rules govern which transitions are legal.

You do not hit the wall gradually. You hit it when a change that should take an hour turns out to be impossible.

What Per Seat Pricing Does at Scale

Per seat pricing is cheap at ten users and can be indefensible at four hundred, and the published rates make that easy to demonstrate.

Retool’s pricing page lists its Business plan for UK cloud at GBP 40 per month per builder and GBP 12 per internal user, with the Team plan at GBP 8 and GBP 4. Microsoft lists Power Apps Premium at GBP 16.90 per user per month paid yearly, excluding VAT, dropping to GBP 10.80 with a 2,000 seat minimum. Airtable publishes Team at USD 20 and Business at USD 45 per user per month, both billed annually in US dollars.

Run those forward. Forty users on Retool Business, three of them builders, comes to about GBP 6,800 a year. The same shape at four hundred users is roughly GBP 59,600 a year, and it rises again the moment you add people. On Power Apps Premium, four hundred seats is about GBP 81,000 a year before VAT.

None of those rates is unreasonable. The point is that the bill tracks headcount rather than value delivered, and headcount grows.

The Exit Problem When Logic Lives in a Proprietary Tool

Every platform will export your data. None of them will export your application.

The rows come out as CSV or through an API, and that is the part everyone checks before signing. What does not come out is the thing you built: the automations, the formula columns, the permission rules, the conditional forms, the flow that turns a request into three notifications and a status change. That logic is the asset, it took months of decisions to get right, and only one vendor’s runtime can execute it.

The practical consequence is that leaving a low code platform is not a migration, it is a rebuild. You get your data back and you write the application again somewhere else, from a specification that was never written down because the platform was the specification.

That is not an argument against using one, only for keeping a written description of the rules outside the tool.

Five Year Total Cost of Ownership Across the Three Routes

The comparison people usually make is dishonest in a specific way: it puts the fully costed version of one route against the sticker price of another. Take forty users and one operational application replacing a spreadsheet and two small subscriptions. The figures are illustrative planning numbers, not quotes, and your build price is the variable that moves most.

Read in prose: at forty users the no code platform wins, at roughly GBP 75,800 over five years. The custom build lands second at about GBP 94,500, because a GBP 45,000 build plus GBP 1,800 of hosting and GBP 8,100 of annual maintenance still beats the SaaS route’s stacked licence, middleware and administration. Buying the product comes last at about GBP 135,000, and it does so because of the middle trap rather than the licence alone.

Why the Same Table Inverts at Four Hundred Users

Change one input, headcount, and the ordering changes completely. This is the single most common reason a build becomes rational.

At four hundred users the SaaS licence at GBP 30 per seat per month is GBP 144,000 a year on its own, and with the same middleware and a larger administrative load the five year total passes GBP 800,000. The no code route lands near GBP 375,000. The custom build barely moves: more users means a slightly larger hosting bill and maintenance budget, so even doubling the build price to GBP 70,000 leaves a five year total near GBP 153,000.

The reason is structural. Per seat pricing is a variable cost that scales with your organisation, while a custom system is a fixed cost plus a small variable, and that variable is infrastructure, which is cheap. Whether the inversion matters to you is a business forecast rather than a technical judgement.

The Ongoing Cost Floor of a Custom Build

The line people leave off a custom estimate is the one that never stops. A bespoke application has a cost floor, and it does not fall to zero in a quiet year when nobody requests a feature.

The floor is made of hosting, monitoring, backups you have tested restoring from, TLS certificates, security patching, dependency upgrades, and somebody who answers the phone when it breaks at nine on a Monday. Plan against roughly 15 to 20 per cent of the original build cost per year. That is a planning assumption drawn from how these projects behave rather than a published statistic, but it is the number we budget against, and a build quoted without it is not a complete quote. Our post on software maintenance cost breaks it down further.

Every five year custom total above assumes that line is funded. Projects that skip it do not save the money, they defer it and pay it later as a rewrite, which is exactly what technical debt describes.

Software That Is Not Maintained Decays

An application that has run untouched for two years is not stable. It is unpatched, and the difference matters.

Nothing about your code changed, but everything around it did. Language runtimes reach end of life on a published schedule: Node.js currently supports version 26 as Current with versions 24 and 22 as active LTS lines, which means anything built on version 20 or earlier is now out of support and receiving no security fixes. Dependencies accumulate published vulnerabilities. Browsers change how they treat cookies and storage. Payment providers sunset API versions and give you a deadline.

None of these are your fault and all of them are your problem, because in a bespoke system there is no vendor absorbing them on your behalf. This is the genuine, structural advantage of buying: somebody else’s engineering team spends every week keeping the floor from rotting, and the licence fee is what that costs. Your own maintenance budget buys exactly the same work, and you either pay it deliberately or you pay it in an emergency.

Finding Your Own Per Seat Crossover

You can compute the crossover point in about ten minutes, and it is more persuasive to a finance director than any argument about ownership.

Take the monthly cost of the product route, all in: licence, middleware, and the fraction of a salary spent administering it. Subtract the monthly running cost of a custom system, which is hosting plus one twelfth of the annual maintenance budget. Divide the build price by what is left. The answer is the number of months until the build has paid for itself.

Worked through at forty users: the SaaS route runs at about GBP 2,150 a month and the custom system at about GBP 825, so the monthly saving is roughly GBP 1,325. A GBP 45,000 build divides into that about 34 times, so payback lands near two years and ten months. At four hundred users payback falls under a year.

Two caveats. The build price is the least certain number here, so run it at your quote and again at 50 per cent more. And a payback longer than about three years is a weak case, because your process may not survive unchanged that long.

Data and Lock In Cut Both Ways

Vendor lock in is the standard argument for building, and it is real. It is also half the picture, because a custom system nobody documented is locked in too.

On the product side, check before you sign what actually comes out. Records usually export cleanly. Attachments, historical audit logs, comment threads, permission structures and the relationships between records frequently do not. The practical measure is not whether an export button exists but whether you could stand up a working replacement from the export alone.

On the custom side, the equal and opposite risk is a system built by one contractor with no README, no tests, no runbook, credentials in a config file on a laptop, and a repository in somebody’s personal account. That is worse than SaaS lock in, because at least the vendor is still trading.

The remedies are contractual and cheap to insist on at the start. Own the repository yourself, require documentation and a runbook as named deliverables, and require that a second engineer can deploy it from that documentation alone. Test the claim before final payment. Our complete buyer’s guide covers the contract terms in more detail.

Security and Compliance Under Each Model

The split of responsibility differs by route, but one thing does not move at all, and getting this wrong is common.

Under the UK GDPR you are the controller. The ICO defines a controller as the body which, alone or jointly with others, determines the purposes and means of the processing of personal data, and a processor as one which processes personal data on behalf of the controller. Your SaaS vendor is almost always the processor. You remain responsible for demonstrating compliance, and the ICO is explicit that a controller is responsible for its processors and must hold a binding contract containing the provisions required by Article 28(3).

What the vendor genuinely carries is the infrastructure layer: physical security, platform patching, network controls and often certification. The NCSC’s shared responsibility model is clear that even with SaaS you retain three things: assessing that the service meets your security needs, configuring it securely, and deciding which data you put into it.

In a custom build you inherit the whole technical layer as well: patching, access control, encryption, logging, backup and restore. Our post on GDPR technical compliance covers what that looks like in code. The legal position does not change between routes.

Accessibility Applies to Internal Tools Too

Internal tools are routinely built as though nobody using them could be disabled, which is both wrong and, for some organisations, unlawful.

Under section 20 of the Equality Act 2010 an employer has a duty to make reasonable adjustments, including taking such steps as it is reasonable to take to avoid a substantial disadvantage caused by a provision, criterion or practice, and to provide auxiliary aids. A rota system that cannot be operated with a keyboard puts a disabled employee at a substantial disadvantage, and there is no exemption for software your customers never see.

For public sector organisations the position is explicit. GOV.UK’s guidance on accessibility requirements states that intranet and extranet websites are covered by the accessibility regulations, that they must meet WCAG 2.2 AA, and that older internal sites published before 23 September 2019 must be made accessible when they are updated.

The criteria internal tools fail most often are the mundane ones: 2.1.1 Keyboard and 3.3.2 Labels or Instructions at level A, 1.4.3 Contrast (Minimum) at level AA, and among the WCAG 2.2 additions 2.4.11 Focus Not Obscured (Minimum) and 2.5.8 Target Size (Minimum), both at level AA.

Accessibility Is a Ceiling You Do Not Control on No Code

This is the accessibility point that changes a build versus buy decision rather than merely adding work to it.

On a no code platform you do not write the markup. The platform generates it, so your application’s accessibility is capped by that of the platform’s component library. If its date picker cannot be operated from the keyboard, or its modal traps focus badly, you cannot fix it. You can raise a support ticket and wait.

That is fine when the ceiling is high enough, and several platforms take the problem seriously. It is not fine when you have a specific obligation, a specific employee or a public sector duty, because the remedy sits outside your control and your timeline.

In a custom build the accessibility work is yours to get right, which costs more up front and removes the dependency. Ask any prospective vendor for an accessibility conformance statement before you design a process around their components, and treat its absence as an answer.

De-Risking a Custom Build With a Thin First Slice

The way custom projects fail is not usually technical. It is committing the whole budget to a specification written before anybody had used anything.

The alternative is a thin slice: one workflow, end to end, in production, used by one real person doing real work, in six to eight weeks. Not a prototype and not a demo, but the narrowest path through the system that produces a genuine outcome, with real data, real authentication and a real deployment. If the process is quoting, the slice creates a quote, prices it and sends it.

That slice does four things a specification cannot. It proves the integrations, which is where the surprises live. It measures the team’s real delivery rate instead of estimating it. It puts working software in front of the person whose process it is, which reliably changes the requirements. And it gives you an exit: you have spent a defined amount and you own something that works.

Then put a decision point there, in writing, before the larger spend is released. Our guide to building a web app covers the technical shape of a first slice, and our software development services page explains how we scope one.

A Decision Framework You Can Run in an Afternoon

None of this needs a consultancy engagement. It needs a few hours and honesty about the numbers.

First, write the process down as it actually runs, in steps, including the exceptions people handle by hand. This alone often ends the debate, because it surfaces that there are three processes rather than one.

Second, count the seats today and forecast them for three years. Third, shortlist exactly three products and score them against your written process rather than against their feature lists, marking every place where adopting the product would change how you work and whether that change costs you anything.

Fourth, price the middle trap explicitly: implementation fees, middleware, and the fraction of a salary that will administer it. Fifth, apply the two of three test. Sixth, compute the crossover in months at both seat counts. Seventh, if the answer is custom, commission a thin slice rather than a system.

Who Should Close This Tab and Go Buy Something

Some readers should stop here, and saying so plainly is more useful than a balanced conclusion.

If your process is a common one that thousands of businesses run in roughly the same way, buy the product. If you have fewer than about twenty users and no forecast that changes that, buy the product or build it on a no code platform, because the per seat arithmetic will not turn in your favour within any horizon you can plan for. If nobody will own the software after it is delivered, buy the product, because an unowned custom system decays into a liability quickly.

If you cannot describe your process in writing, do not commission anything yet. Write it down first. Many failed projects were commissioned against a description that three people in the same room understood differently, and no amount of engineering repairs that.

If only one of the three conditions holds, buy the product and revisit in a year. The conditions do change, usually because headcount grew. And if what you actually need is a public facing site rather than an internal tool, that is a different project, covered by our website development work.

Getting a Second Opinion Before You Commit

The expensive mistake in either direction is made before any code exists, so the cheapest thing you can buy now is an honest assessment.

Mecanik builds operational web applications for UK businesses, and a large part of that work is telling people they do not need one. Bring the spreadsheet, the seat count and the three products you shortlisted, and our custom software development team will either price a thin first slice or tell you which product to buy instead. If the application is customer facing rather than internal, start with website development and read the custom web development versus SaaS platforms comparison, which covers that side of the question.

Frequently Asked Questions

How much does a custom web app cost in the UK? A focused internal application replacing a spreadsheet and one or two subscriptions typically costs GBP 25,000 to GBP 60,000 to build, with a thin first slice taking GBP 8,000 to GBP 15,000 of that. Budget a further 15 to 20 per cent of the build price every year for hosting, patching and dependency upgrades, because that cost floor never reaches zero.

Is no code a real alternative to custom web app development? Yes. For records, forms, views and simple rules it is frequently the correct answer and it is far faster. It hits a wall on large row counts, complex permissions, transactional integrity, version control and genuine state machines. It is also priced per seat: Retool lists its Business plan at GBP 40 per builder and GBP 12 per internal user per month, which is cheap at ten seats and substantial at four hundred.

At what number of users does building become cheaper than buying? Divide the build price by the monthly saving, which is the all in product cost minus hosting plus one twelfth of the annual maintenance budget. At forty users a GBP 45,000 build against a GBP 2,150 monthly product cost pays back in roughly 34 months. At four hundred users it pays back in under a year, because per seat fees scale with headcount while a custom system’s running cost barely moves.

Who is responsible for data protection if we buy SaaS instead of building? You are. The ICO defines the controller as the body that determines the purposes and means of processing, and your SaaS vendor is almost always the processor acting on your instructions. You remain responsible for demonstrating compliance, for the compliance of your processors, and for an Article 28(3) contract. Buying software moves the infrastructure work, not the legal responsibility.

Do accessibility rules apply to internal tools nobody outside the company sees? Yes. Section 20 of the Equality Act 2010 requires employers to make reasonable adjustments, and a tool that cannot be operated with a keyboard puts a disabled employee at a substantial disadvantage. Public sector intranets and extranets are additionally covered by the accessibility regulations and must meet WCAG 2.2 AA. On a no code platform the accessibility ceiling is set by the vendor’s components.