The honest answer is “it depends,” but that answer is only useful when the dependencies are visible. A marketing-site improvement, a mobile feature, a focused first release, and a multi-role operational platform are different kinds of work. Publishing one universal price for all four would create confidence without context.
Cost is shaped less by how many screens you can list and more by uncertainty, business rules, data, integrations, quality requirements, team shape, and what the product must survive after launch. You can still plan before every detail is known—as long as the estimate exposes its assumptions and the decisions that would change it.
Use project shapes, not universal price bands
Kalytex does not publish a pretend rate card for undefined work. A responsible first estimate starts by identifying the delivery shape, what is already known, which roles are needed, and what evidence will narrow the range. These lanes help compare proposals without inventing a market-wide price.
Match the estimate shape to the job
Problem framing, user and workflow research, technical risk, prototype, and a delivery recommendation.
A fixed or capped first step, named outputs, open questions, and a clear decision at the end.
One primary journey, a small number of roles, production foundations, and a contained set of integrations.
A range tied to the complete journey, team shape, assumptions, exclusions, and release criteria.
Frontend, backend, mobile, CMS, commerce, or internal-tool improvements within a live product.
A staged roadmap with priorities, capacity, dependencies, and review points rather than one giant promise.
Multiple roles and workflows, integrations, administration, reporting, migration, and stronger operational controls.
A phased budget with explicit risk reduction, governance, operational ownership, and stop-or-continue decisions.
Two projects in the same lane can still require very different investment. A visually small interface connected to difficult data or high-impact decisions may carry more risk than a much larger content surface. Client readiness, team composition, existing systems, and whether research, migration, content, and ongoing support are included all change the estimate.
What actually moves custom software cost?
- Number of distinct user roles and the permissions between them.
- Breadth of the core journeys and the number of meaningful exceptions.
- Quality and availability of existing data, plus migration and reconciliation needs.
- Reliability and documentation of third-party or legacy integrations.
- Security, privacy, audit, accessibility, and regulatory requirements.
- Real-time behaviour, offline needs, device capabilities, and performance targets.
- Administration, reporting, support tooling, and operational visibility.
- How quickly stakeholders can decide, provide access, review work, and resolve policy questions.
- The expected life of the product and the plan for maintenance after launch.
Notice what is missing: “number of pages” as the primary measure. Pages affect effort, but a single checkout, business rule, or permissions model can carry more risk than twenty marketing screens. Estimate around behaviour and system boundaries, not only the sitemap.
Where money compounds—and where it leaks
Spend on the decisions that protect the product
Testing expensive assumptions and defining one valuable first journey.
Producing a large specification that avoids users, data, and technical reality.
Security, accessibility, observability, automated delivery, and clear architecture matched to the risk.
A fashionable stack or platform complexity with no current product need.
Making important tasks clear, fast, inclusive, and easy to recover when something goes wrong.
Polishing low-value screens while core workflows remain confusing.
Admin tools, support visibility, ownership, and a release process the team can sustain.
Treating launch as the finish line and discovering support requirements in production.
A trustworthy estimate has a shape
Be cautious with both extremes: a fixed price created from a vague idea and an open-ended time-and-materials proposal with no milestones. A useful estimate connects money to scope, assumptions, evidence, and decisions.
The same principle sits behind the GOV.UK guidance on discovery: understand the problem, users, and constraints before committing to a solution. You do not need a heavyweight process. You need the cheapest credible way to reduce the biggest unknowns before they enter the build budget.
How to get an estimate you can govern
The goal is not perfect prediction. It is a plan that makes uncertainty and choices visible.
- 01
Share the outcome and current process
Explain the customer or operational result, the workaround today, the users involved, and why the timing matters.
- 02
Expose constraints early
List integrations, data, regulation, approvals, deadlines, existing suppliers, and anything the team cannot freely change.
- 03
Ask for assumptions and exclusions
Every material estimate should show what must be true and what the number does not currently include.
- 04
Stage the commitment
Fund discovery or a thin first release before committing the full platform budget when uncertainty is high.
- 05
Include life after launch
Plan hosting, monitoring, security updates, support, product analytics, content, maintenance, and the next evidence-led release.
A credible software estimate does not pretend uncertainty has disappeared. It shows you how the team will reduce it before it becomes expensive.
How to reduce cost without damaging the product
Reduce breadth before quality. Serve one audience, narrow the first workflow, defer rare exceptions, use proven services for commodity capabilities, and keep manual steps where a small pilot does not justify automation. Our guide to planning an MVP explains how to make that cut without turning the release into a throwaway demo.
Make decisions quickly, give the team access to users and system owners, prepare data early, and review working software every week. The companion article on why software projects go over budget covers the controls that keep the range useful after delivery begins.
What Kalytex needs to give you a useful first range
You do not need a formal request for proposal. A one-page note is enough if it explains the business problem, target users, current workaround, essential systems, material constraints, desired timing, and the investment range you are comfortable exploring. We can then tell you whether the next step is a short discovery, a focused release, a technical review, or simply buying an existing product.
Explore our software development services and selected product work for context. If the fit is not right, we will say so. A useful estimate begins with an honest decision about whether custom software is justified at all.
