"How much does it cost to build an app?"
It's the most common question we get, and the honest answer — "it depends" — is also the least helpful one.
So let's make it helpful. Here's what actually drives software costs, why estimates vary so wildly between vendors, and how to budget realistically.
Why Software Is Expensive
Software isn't expensive because code is hard to write. Modern tools, frameworks, and AI make writing code faster than ever. Software is expensive because of everything around the code:
Decisions
Every feature involves dozens of decisions:
- What happens when the user enters invalid data?
- What does the loading state look like?
- How does this work on mobile?
- What happens when two users edit the same record simultaneously?
- How do we handle the user's session expiring mid-action?
A login form seems simple. But deciding on password requirements, error messages, rate limiting, session duration, "remember me" behavior, password reset flow, account lockout policy, and accessibility compliance turns a "simple form" into a week of work.
Edge Cases
The happy path — where everything goes right — is maybe 20% of the work. The other 80% is handling what happens when things go wrong:
- Network failures
- Concurrent users
- Invalid data
- Browser inconsistencies
- Third-party API changes
- Time zones
- Character encoding
- Accessibility requirements
These aren't bugs. They're engineering. And they're the difference between software that works in a demo and software that works in production.
According to research by Capers Jones[1], a pioneer in software measurement, the average software project requires roughly 5x more effort in testing, debugging, and rework than in initial coding. The code itself is the tip of the iceberg; the real cost lies in making it reliable.
The Gap Between Description and Reality
"Build a dashboard" is a sentence. Building a dashboard that loads fast with 100,000 records, renders correctly on mobile, respects user permissions, handles real-time updates, and is accessible to screen readers is a project.
The gap between what people describe and what they actually need is where most cost overruns live. Not because stakeholders are unclear — but because software has inherent complexity that isn't visible until you start building.
How Pricing Models Compare
Fixed Price
How it works: Vendor quotes a fixed price for a defined scope.
The promise: You'll pay exactly what was quoted.
The reality: The scope is never fully defined upfront. When requirements change (they always do), you get one of three outcomes:
- Vendor absorbs the cost and cuts corners to stay profitable
- Vendor charges change request fees that balloon the total
- Vendor delivers exactly what was specified, even when both parties know it's not what's needed
Fixed price works for very small, very well-defined projects. For anything substantial, it creates perverse incentives.
Time and Materials (Hourly)
How it works: Vendor bills by the hour.
The promise: You only pay for actual work.
The reality: Two problems:
- No predictability: You don't know the final cost until the project is done
- Perverse incentive: The vendor is financially rewarded for taking longer
Hourly billing can work with high trust and experienced project managers, but it requires constant oversight.
Effort Unit-Based Pricing
How it works: Work is estimated in effort units (a measure of complexity). You buy a monthly allocation of effort units. Each feature is estimated before you commit.
Why it works:
- Predictable: You know your monthly cost upfront
- Transparent: You see exactly what each feature costs in effort units before it's built
- Flexible: Priorities can change development cycle to development cycle without renegotiating contracts
- Aligned incentives: The vendor benefits from delivering efficiently, not from taking longer
This is how Toolwiz pricing works. You choose a plan with an effort unit allocation, and each development cycle delivers features within that budget.
What Does Software Actually Cost?
Rather than quoting specific project numbers, here's how to think about cost in terms of complexity:
Simple Features (1-3 Effort Units)
- Static content pages
- Simple form with validation
- Basic CRUD operations
- Style changes and UI tweaks
Medium Features (5-8 Effort Units)
- User authentication flow
- Search with filters
- File upload and processing
- Email notification system
- Dashboard with charts
Complex Features (13-21 Effort Units)
- Payment integration
- Real-time collaboration
- Third-party API integrations
- Complex business logic with rules engine
- Multi-role permission system
Very Complex Features (34+ Effort Units)
- Full e-commerce checkout flow
- AI/ML feature implementation
- Migration from legacy system
- Multi-tenant architecture
At Toolwiz, our plans range from 40 effort units/month (Starter) to 150 effort units/month (Enterprise). A typical MVP might be 40-80 effort units total. A mature product might consume 80-150 units per month in ongoing development.
See our full pricing breakdown →
Hidden Costs Most Vendors Don't Mention
Hosting and Infrastructure
Your software needs to run somewhere. Cloud hosting costs depend on traffic, storage, and compute requirements. Budget for a few hundred euros per month for most projects, more for high-traffic applications.
Maintenance
Software isn't "done" when it launches. Dependencies need updating, security patches need applying, and bugs need fixing. Budget 15-20% of initial development cost annually for maintenance.
Gartner research[2] consistently reports that the majority of enterprise IT spending goes to maintaining and running existing systems rather than building new capabilities. For custom software, ongoing maintenance isn't a surprise cost — it's the primary cost.
Iteration
Your first version won't be your last. Plan for at least 2-3 iterations after launch based on real user feedback. The first version tests assumptions; subsequent versions refine them.
Third-Party Services
Authentication providers, email services, payment processors, analytics, error tracking — these add up. Budget for a few hundred euros per month for a typical SaaS application.
How to Budget Realistically
Step 1: Define Your MVP Honestly
List only the features that are essential to test your core hypothesis. Not "nice to have" — essential.
Step 2: Estimate in Effort Units
Work with your development partner to estimate each feature. This gives you a total project size.
Step 3: Add a Buffer
Software estimates are optimistic by nature. Add 25-30% to your estimate for unknowns.
Step 4: Plan for Post-Launch
Budget for 3-6 months of development after launch for iteration and refinement. This is where the product actually becomes good.
Step 5: Account for Running Costs
Hosting, third-party services, and maintenance are ongoing. Factor these into your monthly budget from day one.
The Most Expensive Mistake
The most expensive thing in software development isn't building the wrong feature. It's building the wrong feature and not finding out until the end.
Short development cycles, regular reviews, and transparent progress tracking exist specifically to catch mistakes early. A misunderstood requirement caught in week 2 costs a conversation. The same mistake caught in week 12 costs a rewrite.
This is why we run 1-2 week development cycles with stakeholder review at the end of each one. Not because it's a nice process — because it's the cheapest way to build software that actually works.
Want a realistic estimate for your project? Request early access →
