The question “what does a custom application cost?” has only one honest answer: “it depends on what it has to do”. Any article or vendor that gives you an exact amount before understanding your processes is not making you an estimate, but testing your budget. That does not mean, however, that you are condemned to sign blind.
This text is for the owners and directors whose companies have outgrown Excel and off-the-shelf programs: orders get lost among emails, inventory does not talk to production, and the processes that make the company good do not fit into any mass-market software. We show you what the cost is actually made of, which variables move it, how you obtain an estimate that means something — and, just as importantly, the situations in which a custom application is a mistake.
Why there is no price without analysis
“What does an application cost?” resembles “what does a building cost?” — it depends whether it is a garage or a production hall. The variables that separate a small project from one ten times more expensive are concrete: how many types of users there are and what each is allowed to do; how many screens and workflows it covers; how many existing systems it must talk to — inventory, accounting, online shop; how much historical data must be migrated and what state it is in; which reports it must produce; which security and compliance requirements apply to your field.
The counter-intuitive part: the big cost is not in the usual case, but in the edge cases. “The client places an order” is simple. “The client cancels after a partial delivery, with an advance paid and a return in transit” — this is where the real complexity hides, and such situations are discovered only by analysing the process with someone who asks the right questions.
The anatomy of the total cost: six components, not one
The first budgeting mistake is to equate “the cost of the application” with the cost of the build. The real components:
- Analysis (discovery). Someone documents your processes, edge cases and priorities before a single line of code is written. It is the cheapest part of the project and the one that prevents the most expensive mistakes.
- The build. The development itself — usually the largest line in the offer, but rarely more than half the total cost over the application's lifetime.
- Testing. Including by your own people, on real data, before launch.
- Launch and data migration. The old data must be cleaned and moved, and the people trained.
- Maintenance and evolution. Living applications change: legislation, new processes, security updates. At quotation, request the annual maintenance cost as an explicit figure — subscription or rate — and do not accept “we'll see after launch”.
- Hosting and third-party licences. Servers, external services and licences are paid monthly, separately from development.
The golden rule: an application without a maintenance budget is not an asset, it is a debt with an unknown due date.
How to obtain an estimate that actually means something
You can influence the quality of the estimate more than you think, with four moves:
- Write the process down on paper before the first discussion — who does what, with what data, what happens on exceptions. Two pages are enough for the offers to become comparable.
- Ask for the breakdown by functionality. Not “order management application: total amount”, but each module with its effort. Only that way can you cut what is not essential.
- Ask for the minimum viable version. What is the smallest product that solves the main problem? The rest become later stages, paid for after the first version has proved its value.
- Compare two or three offers against the same document. Big price differences on the same brief almost always mean someone understood something different — clarify before you choose.
Any figure heard before the analysis is an indicative estimate that gets confirmed at quotation — treat it as such. What a healthy development contract must contain, we have gathered at the frequently asked questions about prices and contracts.
When the custom application is NOT worth it
The most valuable advice in this article is a list of situations where the correct answer is “no”:
- Standard software covers the need. Accounting, generic CRM, HR, invoicing — these problems are solved by mature products with small monthly costs. Do not rebuild what you can rent.
- The process changes from one month to the next. Custom development fixes the process in code; if the process has not settled, you will pay for modifications endlessly.
- Only one person is asking for it. If the application solves one department's frustration, not a company-wide bottleneck, it will die together with the initiator's enthusiasm.
- You have no internal owner. Someone in the company must be responsible for the application — prioritising requests, validating changes. Without this person, the project drifts.
- The budget covers only the build. See the golden rule above.
This is also where the question “who maintains it long term?” belongs — the answer influences the decision as much as the price of the build, and the full calculation between an in-house IT employee and outsourcing can clarify it for you.
When it truly is worth it
There is also the reverse: situations in which the custom application is the best investment the company can make. When your process is your actual competitive advantage — the way you quote, produce or deliver differently from the competition — mass-market software would drag you back towards the market average. When the volume is high and the rules are yours, automating your own processes pays for itself through hours saved month after month. And when you need a unique bridge between existing systems, which nobody sells ready-made.
Worth remembering on the financing side too: through PNRR (Romania's National Recovery and Resilience Plan) there are digitalisation grants for SMEs between 20,000 and 100,000 EUR, non-repayable aid, and software development can be an eligible expense — check the guide of the call in force at the date of submission.
Warning signs at quotation
Whoever you talk to, stop if you see: a firm price given within 24 hours, without a single question about your processes; the answer “anything is possible” to every requirement; no mention whatsoever of maintenance; and — the most expensive in the long run — code that remains the vendor's property. Require in the contract ownership of the code and a documented handover, otherwise changing vendors becomes practically impossible.
The next step
Write down on two pages the process you want to solve, with its exceptions, and on that basis request two or three offers broken down into the six components above. Only then does the question “what does it cost?” receive an answer that means something. If you want to go through this analysis with someone who does it frequently, Neoxis offers it as part of its development and automation services.