Why the range is so wide

“Custom software” can describe a small approval tool, a CRM used by twenty employees or a marketplace serving thousands of customers. Screens alone do not reveal the complexity. Roles, business rules, data, integrations, security and operational consequences determine much of the work.

The same idea can also be approached at different levels. A prototype tests whether a workflow makes sense. An MVP supports a narrow real-world use case. A mature platform handles exceptions, administration, reporting and scale. Asking for the price without agreeing on the level produces misleading comparisons.

What are you actually paying for?

Discovery and product decisions

A team needs to understand the operation, users, constraints and success criteria. This work prevents technically correct software from solving the wrong problem.

Design

Product design defines information, flows, states and behaviour—not only colours. Internal software also needs design: confused employees and avoidable mistakes have a business cost.

Engineering and quality

Frontend and backend development, database design, permissions, integrations, testing and deployment form the visible build. Complexity grows when actions affect money, regulated information or several external systems.

Operation

Hosting may be modest, but responsibility is not. Monitoring, backups, security updates, support and controlled releases keep the platform dependable after launch.

Better question

What is the smallest investment that can prove the important business assumption with real users?

How to reduce cost without weakening the product

Reduce breadth before quality. One complete workflow is more valuable than six unfinished modules. Use established services for generic needs such as payments or transactional email. Delay advanced reporting until the core data is reliable. Design for the most important role first.

Bring access to decision-makers and real users. Slow feedback, changing ownership and unresolved policy questions can consume more time than difficult code.

How to compare development proposals

Check whether each proposal includes the same work. Look for discovery, design, migration, integrations, testing, deployment, documentation and support. Ask what is explicitly excluded and how changes will be handled.

Also ask who owns the source code and data, who can operate the system, and what happens if the relationship ends. A lower estimate with unclear ownership or no operational plan can carry a much higher risk.

Expect an estimate to become more precise in stages

An early conversation should produce a broad direction. A short discovery phase can produce a prioritised scope and a more defensible estimate. Delivery in visible increments then replaces speculation with evidence.

This is not avoiding commitment. It is the responsible way to price work whose purpose is known but whose details are still being discovered.

Frequently asked questions

Can custom software be delivered for a fixed price?

Yes, when the scope and assumptions are sufficiently clear. Discovery or a paid first phase is often needed before a responsible fixed proposal can be made.

What ongoing costs should we expect?

Typical costs include hosting, monitoring, backups, third-party services, support and continued development. They depend on usage and operational requirements.

Who owns custom-developed software?

Ownership and licensing should be defined in the agreement. The same applies to source code, data, third-party components and the ability to move to another operator.

Need a realistic first range?

Share the business problem, users and current process. We will tell you what must be learned before anyone can price the work responsibly.

Let’s talk