There is no honest fixed price for bespoke software before the problem is understood.
That is not an attempt to be vague. Two projects that sound similar on paper can involve very different levels of uncertainty, integration, data handling, user journeys and ongoing responsibility. A small internal tool can be the right answer for one business; another may need a customer-facing application, a difficult integration or a careful recovery of an existing system.
The useful question is not simply “what does software cost?” It is “what is the smallest piece of work that solves the problem well enough to be worth doing?”
What actually affects the cost?
The main factors are usually practical rather than fashionable.
1. How clear the problem is
If the outcome, users and constraints are already clear, the work can be scoped more directly. If the problem is still emerging, the first phase may need to reduce uncertainty before anyone commits to a larger build.
That does not mean you need a polished specification. It means the unknowns should be made visible instead of quietly becoming expensive later.
2. The number of people and workflows involved
Software used by one person is different from software used by customers, a small team and several external partners. More roles can mean more permissions, edge cases, support needs and ways for a workflow to fail.
The aim should be to understand the real workflow, not to add features for every hypothetical scenario.
3. Existing systems and integrations
Connecting to payment providers, accounting tools, CRMs, APIs, old databases or internal systems can be extremely valuable. It can also be where the real complexity lives.
An integration should be scoped around the information that must move, the failure cases that matter and who is responsible when a third-party system changes.
4. Data, security and reliability
Projects that handle personal information, money, important records or business-critical processes need appropriate care around access, backups, auditability and failure handling. That work is part of the product, not an optional extra added at the end.
5. What already exists
Starting from a blank page is not always the most expensive route. An existing build can be a useful foundation, or it can contain hidden constraints that make a careful rescue the better first phase.
Before promising a rewrite or a quick fix, it is worth understanding what the current system does, where it is fragile and what must be preserved.
Sensible ways to start
Not every project needs to begin with a large commitment. Depending on the situation, a useful first step could be:
- clarifying the workflow and delivery options;
- investigating a risky integration or existing codebase;
- building one contained improvement;
- producing a working prototype to test the key assumption; or
- defining a larger product phase with clear decisions, assumptions and delivery shape.
The point is to spend early effort where it reduces the most uncertainty.
What a good proposal should make clear
A proposal for bespoke software development should explain more than a total cost. It should make clear:
- the problem being addressed;
- what is included and excluded;
- the assumptions the plan depends on;
- how progress will be reviewed;
- what happens when a risk or unknown appears; and
- what you will own when the work is complete.
That is particularly important for people commissioning software for the first time. You should be able to understand the shape of the work without becoming a technical expert overnight.
Start with the problem you need solved
Singularity Shift works with individuals, founders, teams and larger organisations. Whether the need is a focused improvement, a web application, mobile or desktop software, an integration or a technical rescue, the first step is to describe the outcome and what is getting in the way.
From there, the scope and cost can be shaped around the work itself—not forced into a package that does not fit.