Custom software has no catalog price. Behind a quote is an estimate of the hours of analysis, design, development, testing and rollout needed to solve a specific problem in your company. That is why understanding how it is quoted is more useful than hunting for a number: it lets you compare proposals and spot when something does not add up.
In custom software the cost is not in "coding": it is in understanding the problem well, agreeing on the scope and not changing it every week.
When building custom makes sense
Before quoting, make sure custom is what you need. It is usually worth it when:
- Your process is your own and no program on the market covers it without forcing you to change how you work.
- You pay for several subscriptions patched together with spreadsheets.
- You need to integrate systems that do not talk to each other: invoicing, inventory, store, CRM.
- The software is part of your competitive edge and you do not want to depend on a third party.
If your need is standard (say, basic bookkeeping), a SaaS will probably serve you faster. We compare them in detail on our custom software page, and if you are torn between a CMS and building your own system, read Laravel vs WordPress.
How a quote is put together
A serious quote usually goes through these stages, and each one weighs differently:
- Discovery: interviews, process map, who uses the system and for what. It is the cheapest stage and the one that saves the most later.
- Scope and design: features, screens, business rules and data. This defines what goes into the first version and what waits.
- Development: the most visible part. It is split into short deliveries so you see real progress.
- Testing: with real data and real users, not just the team that built it.
- Rollout: server, data migration, training.
- Support and evolution: fixes, improvements and maintenance.
What raises or lowers the cost
- Number of users and roles: every user type with its own permissions adds logic and testing.
- Business rules: calculations, approvals and exceptions take the most time and give the most value.
- Integrations: SRI electronic invoicing, banks, messaging, your store. Each one is a mini-project.
- Data migration: bringing in information from Excel or a previous system almost always costs more than expected, because old data arrives dirty.
- Reports and dashboards: they look simple, but require defining clearly what is measured.
- Security and backups: access control, auditing and backups are not optional if you handle customer data.
Billing models
Model | How it works | When it fits |
|---|---|---|
Fixed price | Fixed scope, fixed price | When the scope is well defined |
Hourly | You pay the actual time worked | When scope is uncertain or evolving |
Stage-based | Each phase is quoted when the previous one ends | Long projects with prior discovery |
Retainer | Monthly fee for hours or services | Ongoing evolution and support |
None is best in the abstract. What matters is that the scheme matches how clear the project is to you. For continuity, we have the retainer plan.
Red flags in a quote
- A very low price with no scope detail: the rest will probably be billed as "changes".
- Nothing in writing about who owns the code at the end.
- No discovery stage: they jump straight to coding.
- No mention of support after delivery.
- Date promises without knowing your process.
- No way to see progress before the end.
How to keep the cost from spiraling
- Define the scope in writing and review it with the people who will use the system.
- Start with the essentials: a first version that solves the main problem, expanded with what you actually use.
- Centralize decisions in one person on your side: committee changes drag everything out.
- Review progress every week or two and correct early, which is cheap; late is expensive.
- Deliver data and access on time: a large share of delays come from waiting.
Ownership and dependency
Before signing, make clear that the code, the database and the access will be yours at the end, and that enough documentation exists for another team to continue. Custom software that only its builder can maintain is a dependency, not an asset.
How we work at Codegea
We start with a no-cost discovery meeting. Then we send you the scope, the timeline and a closed price in writing for the first version, with deliveries you can test at every stage. Changes are agreed before they are executed, not after. If your case makes sense as an electronic invoicing product or as a custom ERP, we will explain it with examples.
Tell us about your process from contact and we will tell you honestly whether you need something custom or whether another option suits you better.
Written by
Derian Pinto
Founder & Full Stack Developer
Founder of Codegea. Builds custom websites, stores and platforms, and integrates and supports Arc XP for media companies.