When Is a Custom Web App Worth Building?

A custom web app is worth building when your process is genuinely unlike anyone else’s and no existing product covers it without a workaround you pay for every day. Below that line, the subscription wins.

Seven firms in the search results will tell you they build custom web apps. None of them tells you when you should not build one. We write that half, because it is the half that costs you if you find out late.

The test that settles it in an afternoon

Write down the operation that annoys you most, step by step, as it actually happens. Then count two things: how many times a week somebody performs it, and how many of the steps exist only because the tool you pay for cannot do what you need.

If the workaround steps are a handful and the operation happens twice a week, you have an irritation, not a business case. If the workaround steps are most of the process and somebody does it fifty times a week, you have found the thing worth building. The answer is in that arithmetic, not in a feature comparison.

When the subscription wins

When you have not searched hard enough. Most business needs already have a product behind them. Search the category name rather than your description of the problem, check the integration directories of the tools you already pay for, and read what people with your job are using. A tool that covers eighty per cent costs a fraction of a build, and the remaining twenty per cent is usually solved by an internal convention.

When your process is not settled yet. An app freezes one version of how you work and makes it expensive to change. If the way you operate is different every month, you would be paying to make this month permanent. Stabilise the process on paper first, then automate it.

When you are doing it to look modern. A dashboard nobody opens is a monthly cost with nothing on the other side.

When nobody owns it after launch. An app does not end at delivery. Without a plan for maintenance you have not bought a tool, you have bought a future problem with your name on it.

When building wins

When your logic is genuinely yours. A pricing model, an approval sequence, a way of calculating something that resembles nobody else’s. General tools force compromises there, and you pay for those compromises in lost minutes, every day, forever.

When the same operation happens hundreds of times. The saving comes from repetition, not from elegance. Ten minutes saved on an operation performed fifty times a week adds up to a person-day.

When the data lives in five places. A spreadsheet, an inbox, a notebook and one colleague’s memory. A single place where everything arrives changes more than any sophisticated feature.

When the tool becomes a sales argument. A configurator or a calculator your customer uses on their own, before they call you, changes the commercial conversation. They arrive informed and pre-qualified.

The Cargo Brothers is the fourth case made concrete. Vehicle transport across many countries, vehicle types and routes meant the quoting model was genuinely theirs, and no off-the-shelf calculator could hold it. We designed and built a pricing engine from scratch that turns the whole model into an instant, on-brand quote on the site, with the automation behind it handling the repetitive operational work. The tool is not an internal convenience there, it is part of how the business sells.

The arithmetic people get wrong

Compare the build against three years of subscription, not against one month of it. Take what you pay per seat per month, multiply by the seats you will actually have in two years, multiply by thirty-six, and add the cost of the workarounds: the hours spent re-entering data, the reconciliation nobody logs, the mistakes the tool allows.

Then put the honest cost of building on the other side, which is not the invoice. It is the invoice plus hosting, plus security updates, plus the changes you will want in month eight, plus whoever answers when it breaks. A build that looks cheaper than the subscription on paper is usually a build where the second half was left out of the sum.

What that comparison does not capture, and what tips plenty of real decisions, is leverage. A subscription makes you as good as everyone else paying for it. A tool built on your own logic is something a competitor cannot sign up for.

The part everybody forgets: the interface

A badly thought-out internal app does not get used, and an unused app is pure cost. That is the difference between ordering software and commissioning a product.

What matters, in order: how many clicks the most frequent operation takes, what happens when somebody gets it wrong, and whether a new hire understands the screen without being trained on it. None of those three appears in a specification written by somebody who does not perform the operation daily.

Which is why we build them as products rather than as feature lists: web apps and custom tools, designed around the real flow instead of the org chart.

How to start without burning the budget

Do not write the full specification before you have used anything. Most requirements in a document written at the beginning are assumptions, and assumptions get paid for at implementation.

Pick the flow that hurts most. Build only that. Use it for two months. Then decide what comes next based on what you learned rather than what you believed in month one.

And put ownership of the code in writing. Default rules for software differ by country, and in several of them they run the opposite way to design: rights can sit with whoever commissioned and directed the work rather than with whoever wrote it. Either way the clause gets written explicitly, along with where the code lives and who can access it if we stop working together. It belongs in the list of things to ask before you sign.

How we approach it

We ask first whether something already exists that does the job. If it does, we tell you, even when that means there is nothing for us to build. If it does not, we start from the operation that repeats most often and from the screen somebody will open fifty times a week, and we agree the scope and the price before any of it starts.

FAQ

When is a custom web app worth building instead of paying for SaaS? When your logic is genuinely yours and the subscription forces a workaround you pay for every single day, or when the tool itself becomes something you sell with. If an existing product covers eighty per cent and the rest can be handled by an internal convention, keep the subscription. The cost difference is usually an order of magnitude.

How much does a custom web app cost? It depends almost entirely on how many flows have to be covered and how many rules your business runs on. A calculator with one formula and a portal with accounts, permissions and reporting are projects of different orders of magnitude. The useful question before price is how many screens and how many rules.

What costs appear after launch? Hosting, security updates, changes when your process changes, and fixes when something breaks. An app does not end at delivery the way a brochure site does. Budget maintenance from day one, and decide before you build who answers the phone when it stops working on a Friday.

How do I know an off-the-shelf tool does not already do this? Search properly before you commit: the category name rather than your description of the problem, the integration directories of the tools you already pay for, and the forums where people with your job swap setups. Most business needs already have a product. If one covers eighty per cent, do not build.

Can I start with a small version? Yes, and usually that is the right move. Build the one flow that hurts most, use it for two months, then decide what comes next based on what you learned rather than what you assumed. A full specification written before anyone has used anything is mostly guesswork, and guesswork gets paid for at implementation.