What a custom application costs (and how not to waste the money)
Why two quotes for the same thing differ by an order of magnitude, which costs appear in no proposal, and the questions to ask before signing anything.
· Full-stack development
You ask for quotes for an application and get figures that bear no resemblance to each other. It is not that some are expensive: it is that each one has understood something different, and none of them said so. This article is for asking properly and for reading what comes back.
What really moves the price
The cost of a build does not depend on «how many screens it has». It depends on five things:
- How many types of user there are. An application with a single user type is one project. With three — customer, employee, administrator — it is almost three projects, because each role needs its permissions, its screens and its tests.
- How many systems it connects to. Every integration — payment gateway, accounting, e-invoicing, messaging — is work, and it is also work you do not control: you depend on the other party's documentation and changes.
- Whether money is involved. Taking payment demands security, traceability, refund handling and payment states. It multiplies the effort.
- Whether it processes sensitive personal data. Health, data on minors, financial information. That means legal requirements which are design, not a paragraph in the legal notice.
- How many people will use it at once. Ten internal users and ten thousand concurrent ones are nowhere near the same architecture.
If the quote you receive does not mention these five, it is not quoting for your project: it is quoting for a generic idea.
The costs that do not appear in the proposal
And here is why many projects end up at twice the expected figure:
- Hosting and services. Server, database, backups, domain, certificates, transactional email. It is a monthly cost, forever.
- Corrective maintenance. Software does not break by itself, but its environment changes: operating systems, browsers, libraries with vulnerabilities, third-party systems that change how they connect. An unmaintained application stops working on its own within two or three years.
- Data migration. Moving what lives today in spreadsheets, with twenty years of inconsistencies, nearly always costs more than anybody estimated.
- Training and habit change. If the team does not use it, the project has failed however perfect the software is.
- Changes. They will happen. What matters is that the contract says how they are requested, how they are priced and who approves them.
A practical rule: budget annual maintenance as a meaningful fraction of the initial build. If nobody has mentioned it to you, ask before signing.
The mistake that burns the most money
Building everything before anybody uses it.
The complete system gets defined, signed, developed over eight months and delivered. And in the first week of real use it turns out the main flow was not that one, that a case which happens every day was missing, and that half the functions are opened by nobody.
The alternative: the minimum that solves the main problem, in production and with real users, as soon as possible. And from there, decide with data what gets built next. It is not a fashion: it is the only way for the budget to be spent on what is used.
Before signing, ask this
- Who owns the code? Get it in writing. If it is not yours, you are renting.
- Who owns the data and how do I export it? Ask to see a real export before starting, not at the end.
- What happens if you disappear? An accessible repository, deployment documentation, accesses in your name. A project only its builder can touch is a hostage project.
- What does maintenance include and what does it not? With written response times.
- How are changes priced?
- What technology and why? If the answer is not understandable, there are two possibilities and one of them is bad.
And the prior question: is it really needed?
It is worth saying, even though it takes work away from us: many problems that look like they need a custom application get solved sooner with existing tools well connected. A good invoicing system, a shared database and two automations solve an enormous share of cases, cost a fraction and maintain themselves.
Custom development is justified when what you do is your competitive difference, when no tool on the market fits, or when per-user licence costs already exceed the cost of building. Outside those cases, there are cheaper routes.
Where the line sits we cover in when a spreadsheet is no longer enough.
If this sounds like you
We start by seeing whether your problem can be solved without building: that is the process and AI audit, and it comes out with a written plan and an honest estimate, including the estimate for building nothing. If development is the right answer, that is custom development. And if the short route is automating what you already have, it is in what to automate first.
We are Mindset & Code: automation, data and development for small businesses. You can see what we do and what it costs.
General guidance. Any specific estimate depends on the scope, the integrations and the number of users, and is made in writing before any budget is committed.