The 5 Types of Software Projects and What Each One Actually Costs
One of the most common frustrations in software procurement is that cost estimates vary wildly and seem almost arbitrary. One vendor quotes $30,000. Another quotes $120,000 for what sounds like the same project. Who is right? And how do you even begin to budget for something you have never bought before?
The reason estimates vary so much is that "software project" is not a single category. It is at least five distinct categories, each with its own cost drivers, risk profile, and what-goes-wrong patterns. Once you understand which type of project you are actually buying, the estimates start to make sense.
Use our MVP Cost Calculator alongside this guide to model your specific project.
Type 1: Greenfield Web Application
A greenfield application is a new build from scratch. Nothing exists. You are starting with an empty repository and building a functional web product.
What Is Included
- System architecture and database design
- Backend API development
- Frontend user interface
- Authentication and user management
- Core business logic specific to your product
- Basic deployment infrastructure (cloud hosting, CI/CD pipeline)
- Internal testing and QA
- Documentation for handover
What Is Not Included (Unless Specified)
- Mobile applications (separate project, separate cost)
- Third-party integrations beyond those specified at project start
- Advanced analytics or business intelligence dashboards
- Compliance features (SOC 2, HIPAA, PCI beyond basic payment processing)
- Ongoing maintenance after launch
Cost Range: $20,000 - $200,000+
The range is wide because complexity varies enormously. Here is how to think about the tiers:
$20,000-50,000: A simple web application with five to ten core features, standard authentication, basic data display and input, and minimal third-party integrations. Examples: an internal business tool, a simple booking system, a content-driven site with a custom backend.
$50,000-100,000: A more complex application with fifteen to twenty-five features, one or two significant integrations (payment processing, third-party data feeds), user roles and permissions, an admin panel, and meaningful business logic. Examples: a SaaS MVP, a marketplace with two user types, an e-commerce platform with custom logic.
$100,000-200,000+: A large, complex system with many features, multiple user roles, complex workflows, significant data volumes, real-time requirements, or regulatory compliance requirements. Examples: a multi-tenant SaaS platform, a financial application, a logistics or supply chain tool.
What Typically Goes Wrong
Requirements are incomplete at the start. Greenfield projects have the most surface area for scope creep because everything is new. The solution is thorough discovery before development begins.
Integration complexity is underestimated. Every third-party API integration takes longer than expected. Budget a contingency of 30-50% on integration estimates.
Infrastructure is treated as an afterthought. Cloud infrastructure, CI/CD pipelines, monitoring, and deployment are not optional extras. They need to be scoped and budgeted from the start.
Our Custom Software Development team handles greenfield projects of all sizes. See also the Tech Stack Picker for architecture planning.
Type 2: Mobile Application
Mobile apps are distinct enough from web applications to deserve their own category. The key decision point is native vs. cross-platform.
Native vs. Cross-Platform
Native development means building a separate application for iOS (Swift/Objective-C) and Android (Kotlin/Java). Each platform has its own codebase, its own developers, and its own submission process. The result is the best possible performance and the deepest integration with platform features, but it costs roughly twice as much as cross-platform.
Cross-platform development uses a single codebase (React Native, Flutter, or similar) to build apps for both platforms. The cost is lower because you have one codebase rather than two. The trade-offs are performance in highly demanding use cases and occasional platform-specific bugs that require platform-specific fixes.
For most business applications, cross-platform is the right choice. For games, highly hardware-dependent applications, or products where the iOS/Android experience is a core part of the brand, native is worth the premium.
What Is Included
- UI/UX design for mobile (different design principles than web)
- Application development for iOS and Android
- Backend API to serve the mobile application (often overlaps with a web application)
- App store submission and setup for both platforms
- Push notification infrastructure
- Basic analytics integration
Cost Range: $30,000 - $150,000+
$30,000-60,000: A simple cross-platform app with five to eight screens, standard authentication, basic CRUD operations, and minimal device feature usage. Examples: a companion app for an existing web product, a simple field service tool, a basic content consumption app.
$60,000-100,000: A more feature-rich cross-platform app with offline capability, push notifications, complex data synchronisation, payment integration, or significant use of device features (camera, GPS, biometrics). Examples: a delivery driver app, a healthcare tracking application, a marketplace buyer/seller app.
$100,000-150,000+: Full native development for both platforms, or a complex cross-platform app with real-time features, heavy offline support, or demanding performance requirements.
What Typically Goes Wrong
App store review delays. Apple's review process can take days and is not guaranteed to approve the first submission. Budget time for rejection and resubmission.
Backend is scoped separately and under-estimated. Many clients budget for "the app" and forget that a backend API is also required if the app needs to store and retrieve data. Clarify whether the backend is included in the quote.
Device fragmentation. Android runs on thousands of device models with different screen sizes and OS versions. Budget for testing on a range of devices.
Type 3: Platform Integration
A platform integration project connects two or more existing systems. You already have a CRM, an ERP, a logistics platform, or a data source. You need data to flow between them reliably and automatically.
What Is Included
- API analysis for each system being integrated
- Data mapping (matching fields from one system to another)
- Authentication and secure credential management
- Error handling and retry logic
- Logging and monitoring for the integration
- Testing against each system's sandbox/staging environment
Cost Range: $5,000 - $40,000
$5,000-15,000: A simple one-directional integration between two well-documented systems with modern REST APIs. Examples: Syncing new customers from your CRM to your email marketing platform, pushing order data from your e-commerce platform to a spreadsheet or business intelligence tool.
$15,000-40,000: Bi-directional sync between two systems, integration with a legacy or poorly documented API, complex data transformation between systems with different structures, or integration involving real-time event handling rather than batch processing.
What Typically Goes Wrong
API documentation does not match the API. This happens more than it should. The developer discovers during implementation that the API behaves differently from what the documentation describes. Budget a contingency for this.
Rate limits are hit at volume. Many APIs have rate limits that are not obvious until you are running in production with real data volumes. This can require architectural rework.
Data quality issues in the source system. An integration that seems simple becomes complex when the source data contains inconsistencies, duplicates, or fields that are sometimes empty when the integration assumed they would always be populated.
Scope expands to include data clean-up. Once clients see data moving between systems, they often discover historical data that needs to be migrated or cleaned. This is a separate project, not an integration enhancement.
Our DevOps team handles integrations alongside infrastructure work for complex connectivity requirements.
Type 4: Legacy System Modernisation
This is the most complex and highest-risk category of software project. You have an existing system that is old, often poorly documented, and built on technology that is difficult to maintain. You need to bring it into the modern era without losing the data or business logic it represents.
Why It Is So Complex
Legacy systems are complex for reasons that are not obvious until you are inside them:
- Business logic is often buried in the code without documentation, and the original developers have left
- The system may depend on software libraries, frameworks, or databases that are no longer supported
- Data quality in legacy systems is often poor because validation was not enforced historically
- The system may be deeply integrated with other internal systems in ways that were never formally documented
What Is Included
- Legacy system audit and documentation
- Architecture design for the modernised system
- Incremental migration using patterns like the strangler fig (see When to Rebuild vs Refactor)
- Data migration and validation
- Parallel running of old and new systems during transition
- Testing at every stage
Cost Range: $50,000 - $500,000+
The range reflects genuine uncertainty. A legacy system that is relatively contained and well-understood might be modernised for $50,000-80,000. A system that has been evolving for twenty years, is deeply integrated with other internal systems, and runs a critical business process can cost $300,000-500,000+ to replace safely.
How to Budget for This Type of Project
Do not try to budget for legacy modernisation without a discovery phase first. A proper audit of the existing system - code review, architecture analysis, data model review - is necessary before any estimates can be meaningful. Budget $5,000-15,000 for this discovery phase, then use the findings to scope the modernisation work.
What Typically Goes Wrong
Undiscovered complexity. Every legacy modernisation project discovers things during execution that were not visible during planning. Plan for a 30-50% contingency on the initial estimate.
Data migration underestimated. Getting data from an old system into a new one is always harder than it looks. Data quality issues, format mismatches, and volume surprises are routine.
Business process assumptions broken. The system encodes assumptions about how the business works that may not match how the business currently works. Resolving these requires business decisions, not just engineering.
Type 5: Internal Tool or Dashboard
An internal tool is software built for use by your own team rather than external customers. Examples: a custom CRM for a specific industry workflow, a reporting dashboard that aggregates data from multiple internal sources, a project management tool tailored to your process, or a field operations application for your staff.
What Is Included
- User interface designed for power users (internal tools can tolerate more complexity than consumer products)
- Data integrations with internal systems (often the primary complexity)
- Role-based access control
- Reporting and data visualisation
- Authentication (often SSO with your company's existing identity provider)
What Is Not Included
- Consumer-grade design polish (internal tools do not need to win design awards)
- Public-facing marketing pages
- App store submission (internal tools are typically web-based or distributed internally)
Cost Range: $10,000 - $60,000
$10,000-25,000: A simple dashboard or tool with two to five screens, data from one or two sources, basic filtering and export, and standard authentication. Examples: a daily operations report dashboard, a simple ticket management system, a basic inventory tracking tool.
$25,000-60,000: A more complex tool with ten or more screens, data from multiple sources requiring transformation, complex filtering and search, audit logging, and role-based access control. Examples: a custom CRM with specific workflow automation, a multi-source analytics dashboard, a field operations management tool.
What Typically Goes Wrong
Underestimating data integration work. The internal tool often needs to connect to existing internal systems with varying data quality and documentation. This integration work can easily exceed the cost of the tool interface itself.
Scope expands to "replace" existing tools. An internal tool that starts as a dashboard for one team often grows into an attempt to replace several existing tools. Manage scope tightly.
Adoption requires training. Internal tools only generate value when people use them. Budget for documentation and training, not just development.
Budgeting Advice Across All Types
Regardless of which type of project you are building:
- Add a 20-30% contingency to any estimate. This is not because the estimate is wrong; it is because software projects reliably surface unexpected complexity.
- Get line-item estimates, not a single number. Ask for the breakdown by feature, integration, and phase. This gives you visibility into where the budget goes and what you can cut if needed.
- Separate discovery from delivery. Pay for a scoped discovery phase before committing to the full project budget. The discovery phase will make the full project estimate far more accurate.
To model your specific project, use our MVP Cost Calculator or estimate your project directly. To talk through which category your project falls into and what a realistic budget looks like, get a free quote from our team.
For team options to staff these project types, see our Dedicated Developer, Full-Stack Team, and Project Manager pages.
Related articles
How Much Does It Cost to Build a Web App? A Transparent Breakdown for 2025
Every "how much does it cost" article gives the same useless answer: it depends. This one goes further — showing you what the real variables are, what you get at each price point, and how to scope a build before you talk to a single agency.
Software DevelopmentHow to Brief a Software Project: The Document That Saves You Three Months
Most software projects fail before a line of code is written. They fail at the brief. Vague requirements produce the wrong software. Here is how to write a brief that a developer can actually build from — in one afternoon.