It's the first question every client asks and the last one most development companies answer. You browse ten custom software websites and all ten give you the same response: "it depends, ask us". It's an honest answer… but a useless one for planning.

So let's do the opposite: give you real ranges from the Spanish market, explain what actually moves the price, and teach you how to spot an unserious budget before signing it. It's the same conversation we have at HexagonalGuru with every client on the first call.

The Short Answer: Indicative Ranges

Asking for "a price for custom software" is like asking how much a house costs: it depends on size, location and finishes. But nobody is scandalized when a real estate agency publishes ranges, so here are ours — indicative, from the Spanish market, for professional teams with serious processes:

The ranges are deliberately wide, and here is the first lesson: anyone who gives you a fixed price without a discovery phase is guessing — and you pay for the guessing later, in overruns or in scope cuts.

What Actually Moves the Price

Two projects that sound identical ("a platform to manage orders") can differ by a factor of five. These are the multipliers:

1. Functional scope. "Users and orders" is not the same as that plus roles, approvals, notifications, reports, exports and a mobile app. Every feature adds analysis, development, testing and documentation.
2. Integrations. Connecting with your ERP, the payment gateway, the CRM or that logistics provider's API "that almost works" is usually the most underestimated line item. Every integration brings its research and its edge cases.
3. Data migration. Bringing twenty years of history from three Excels and an Access file is a project inside the project.
4. Non-functional requirements. Performance under load, high availability, security audits, GDPR with sensitive data, accessibility… they're invisible in the demo, but you pay for them in engineering.
5. Design and user experience. A functional internal backoffice doesn't cost the same as a polished user experience for a public-facing product.
6. Deadlines. "I need it in two months" when five is reasonable means more people in parallel, more coordination and more risk. Urgency gets invoiced.

The Cost That Doesn't Show Up in the Budget

The build price is just the entry ticket. Budgeting a software project properly means looking at the total cost of ownership (TCO):

• Corrective and evolutionary maintenance: the industry standard is to set aside between 15% and 25% of the initial cost per year. Software that doesn't evolve dies.
• Infrastructure: servers, databases, CDN, monitoring, backups. From tens to thousands of euros per month depending on scale.
• Third-party licenses and services: payment gateway, email delivery, maps, SMS… small fees that add up.
• Your own time: someone on your team will have to participate: validating features, giving feedback, making decisions. That's a cost, even if it doesn't come on an invoice.

How a Serious Budget Is Built

A professional budget is not a number in a PDF: it's the result of a process. This is how we do it, and how any provider you talk to should:

1. Discovery. Understanding the business, the users and the real problem before talking about solutions. This is where you discover that "I want an app" actually means "I want my technicians to stop using WhatsApp for support tickets".
2. Scope definition. What's in and — just as important — what's not in this phase. Everything in writing.
3. Phase-based estimate. Broken down by modules or deliverables, not a single magic number. That way you can prioritize, trim or start with an MVP.
4. Proposal with explicit assumptions. What's included, what's excluded, what depends on third parties and what happens when something changes (because something always changes).

Red Flags in a Budget

• A fixed price without questions. If they haven't asked you twenty uncomfortable questions, they don't know what they're going to build.
• A single figure with no breakdown. Without line items there's no way to compare or to trim.
• Everything included, everything perfect. Real projects have risks; if the budget mentions none, they'll show up later as "billable surprises".
• Absurd deadlines. "Your full platform in three weeks" means it starts fast… and ships late.
• No discovery phase, or a "free" discovery that's just a sales meeting in disguise.
• The suspiciously low price. The gap between the cheapest budget and the second one usually ends up being paid with interest: in quality cuts, in templates disguised as custom work, or in projects abandoned halfway.

How to Compare Two Budgets

Don't compare the final number: compare the contents. A budget 40% cheaper that excludes data migration, testing and design is actually more expensive. Ask each provider: what exactly is included? What happens when I request a change midway? Who will the actual team be, not the salesperson? Can I talk to a previous client? The answers compare better than the figures.

The Bottom Line

Custom software costs what it costs to build it well: from a few thousand euros for a serious website to six figures for complex platforms. The difference between a good and a bad experience usually isn't the price — it's the process: honest discovery, scope in writing, itemized estimate and explicit assumptions. Distrust anyone who gives you a number without asking — and also anyone who never gives you one.

If you have a project in mind and want a real number, write to us: first conversation with no strings attached, and if we're a fit, an itemized budget with all assumptions on the table. Tell us about your project →

Keep reading: RAG: how to make an LLM answer with your company's data — an example of what can be built today for less than you imagine.