Short answer
Cost comes from scope, quality, and responsibility - not the number of screens.
There is no single reliable price for "dedicated software". The cost of the first period is at least team work + external services + risk reserve + launch and maintenance. Scope can only be assessed once users, deliverables, processes, integrations, data, and quality requirements have been named.
To show the mechanics: 120 man-days at an illustrative rate of PLN 1,500 net gives PLN 180,000 of work. A 15% reserve is PLN 27,000, and 12 months of sample operating costs of PLN 2,500 each is PLN 30,000. In total, the model gives PLN 237,000 net. This is an example calculation, not Coderise pricing or market median.
Two offers may have the same amount and a completely different scope: one covers analysis, testing, migration, monitoring and stabilization, the other only the implementation of functions. Therefore, the price should be read together with the assumptions, exclusions and definition of termination.
Full model
Separate the cost of production from the cost of ownership.
Analysis and design
Process, users, prototype, architecture, risks, data and first scope plan.
Manufacturing
Implementation, integrations, migrations, tests, UX, infrastructure as code and documentation.
Launch
Environments, monitoring, security, training, migration, implementation and stabilization.
Operations
Cloud, licenses, API, backups, alerts, updates, incidents and required level of support.
Change
New needs, regulations, versions of external systems and improvements based on data from use.
Exit
Data export, knowledge transfer, ability to change supplier and safe shutdown.
The server bill itself is sometimes a small part of the TCO. In business systems, operational costs also include responsibility for alerts, dependency updates, data recovery, user support, and integration customization.
The scale of the effort
First compare person-days and assumptions, then compare amounts.
The ranges below are Coderise's working model for order-of-magnitude conversation. They are not an offer or market statistics. A person-day means a day of work for one person, but does not assume that all roles work in parallel throughout the project.
Discovery, prototype or limited module
Checking the problem, risks, integration or single flow. Typically not a full production system.
Goal: to reduce uncertainty before a larger investment.Focused MVP or internal tool
One core process, limited roles, few screens and integrations, and basic operational readiness.
Goal: trigger a measurable result for the selected group.Production system with integrations
Many roles and variants, migration, more extensive security, reporting and operational responsibility.
Goal: to handle the complete process in a real environment.Critical platform or system
Multiple domains, teams, integrations and availability, compliance, audit or multi-tenancy requirements.
Goal: develop the product in stages, not as one closed scope.Valuation factors
The eight questions that change scope the fastest.
How many users and roles does the system apply to?
Each role adds permissions, interface variants, tests, and data responsibility.
How many variants and exceptions to the process are there?
“Order processing” can mean one flow or dozens of rules depending on the product and customer.
How many systems do you need to connect to?
The cost depends on the quality of the API, limits, test environments, documentation and owners on both sides.
Does the data need to be cleansed and moved?
Migration includes mapping, quality, duplicates, trials, reconciliation and revertability.
What is the cost of failure or wrong decision?
It affects testing, acceptance, auditing, monitoring, redundancy and emergency procedures.
What availability and speed do you need?
“Runs 24/7” requires a different architecture and operation than a tool used during office hours.
Who makes scope decisions and how quickly?
The lack of an available owner lengthens locks and increases the number of assumptions to be corrected later.
What needs to happen after launch?
Support, training, effect measurement, corrections and a development plan are part of the real implementation.
First period calculator
Calculate your own assumptions instead of copying someone else's price list.
The calculator shows the mechanics of net cost. Enter the effort, effective man-day rate, reserve and monthly operating costs. It does not take into account taxes, financing or the time value of money.
The reserve should be due to named uncertainties, for example an unavailable integration sandbox or an unverified migration. It is not a budget for arbitrary new features.
Valuation maturation
Accuracy increases with evidence, not document length.
Order of magnitude
The problem and the approximate user group are known. The result is used to decide whether to fund discovery.
The biggest unknown: whether to build and what is really needed.Variant range
The process, integrations, data, prototype and risks are described. Several scopes and stages can be compared.
The biggest unknown: the behavior of external systems and data.Valuation after trial
The most difficult technical assumptions have been verified, and the team has the first data on the pace of work.
The biggest unknown: user reaction and full process exceptions.Forecast updated
The plan is based on completed work, measured volume, and informed scope decisions.
The biggest unknown: future priorities and changes in the environment.Good pricing is versioned. It should show assumptions, exclusions, range of uncertainty and date of update. When implementation facts emerge, the forecast is compared with them and adjusted.
Settlement method
The contract model should match the level of uncertainty.
| Model | When it helps | The main risk | Inspection needed |
|---|---|---|---|
| Fixed price and range | Stable requirements and clear perception | Risk premium and cost of each change | Precise assumptions, exclusions and procedure for changes |
| Time & materials | The scope matures with feedback | Budget without active prioritization | Limit, frequent demos, metrics and product decisions |
| Iteration with a limit | You need to check the risk or achieve a specific stage result | A series of works without a "continue/stop" decision | Goal, time, maximum cost, and explicit result of the iteration |
| Target budget, stage scope | Known investment limit and possibility of prioritization | Trying to fit all features despite new data | Product owner and willingness to remove scope |
A fixed price does not remove uncertainty - it merely assigns it to the party to the contract. When the problem is poorly understood, a separate, limited discovery may be reasonable, after which the parties choose the scope of construction and the appropriate model of cooperation.
Cost control
Save by lower uncertainty and scope, not by hiding quality.
- Choose one measurable result of the first release. Limit roles, variants, and data sources to a group that allows you to test your hypothesis.
- Remove a process step before implementing it. Unnecessary acceptance or manual rewriting should not be replicated just because it exists today.
- Use ready-made functions for standard needs. It is worth building login, payments or mailing on your own only if you have a conscious advantage or limitation.
- Check the most expensive risks with a small sample. A short integration or migration spike can protect against a valuation based on an incorrect assumption.
- Automate testing and implementation from scratch. A repeatable change path reduces the cost of each subsequent version and the risk of manual operations.
- Measure usage after launch. Features without an impact on the result should not automatically move to the next stage of development.
Inputs for the first estimate
One page of specifics is better than a wish list.
- 1
Problem and result: what is not working today, for whom and how we will know the improvement.
- 2
Users and roles: who does the work, approves, administers and only reads.
- 3
Process and exceptions: beginning, end, main steps and most common deviations.
- 4
Systems and data: sources of truth, integrations, formats, quality and migration plan.
- 5
Quality requirements: availability, security, audit, performance, retention and recovery.
- 6
Boundaries: what is consciously not included in the first version and what assumptions require confirmation.
Reference points
A reliable forecast shows the range of uncertainty and is updated.
GAO's cost estimating guidance emphasizes analyzing sensitivity, risk, and uncertainty, documenting assumptions, and updating estimates based on actual costs and changes. GOV.UK describes discovery as the stage of understanding the problem, users and constraints before construction. AWS provides a separate calculator for modeling cloud costs, which should be part of the TCO and not equated to the entire cost of the product.
- U.S. GAO - Cost Estimating and Assessment Guide Assumptions, sensitivity analysis, risk, uncertainty, documentation and revaluation.
- U.S. GAO - Agile Assessment Guide Incremental software development and continuous assessment of functionality, quality and satisfaction.
- GOV.UK Service Manual – discovery Understanding the problem, users, and constraints before committing to building the service.
- AWS Pricing Calculator Modeling the cost of planned workloads and cloud infrastructure changes.
Frequently asked questions
How can you read a software estimate without false precision?
How much does it cost to build custom software?
Cost comes from team effort, services used, risk and subsequent maintenance. Without a description of users, processes, integrations, data and quality requirements, only a broad range or the cost of a discovery stage can be quoted honestly.
What increases the cost of a bespoke application most?
The most common drivers are integrations of unknown quality, data migration, complex roles and permissions, security and availability requirements, many process variants and no person available to make prompt scope decisions.
Is a fixed project price safer?
It provides predictability only when scope and acceptance criteria are sufficiently stable. With high uncertainty, the supplier prices in risk, limits flexibility or charges separately for every change. It is often better to estimate discovery separately and build in stages with a budget cap.
How much does software maintenance cost after release?
Include infrastructure, licenses and APIs, monitoring, backups, security updates, incident response and development driven by business changes. Cost depends on required availability and responsibility, so it should be modeled together with the build.
How can cost be reduced without lowering quality?
The strongest lever is limiting the first scope to one measurable outcome, using ready-made capabilities where they do not create an advantage, testing integration risks early and postponing variants without proven value.
When is an off-the-shelf SaaS product better than custom software?
When the process is standard, product configuration covers key needs, integrations are available and supplier dependency is acceptable. Custom software makes more sense when an unusual process creates significant value or ready-made tools force costly workarounds.