How We Price a Custom Software Project

What we count

An estimate is not a feeling. We break the scope into components, estimate each in engineer-days, apply a contingency for the parts with genuine unknowns, and add design, QA and project overhead as percentages of the build.

The four things that move the total most are rarely the ones clients expect. It is almost never the number of features.

1. Distinct screens — each one needs design, build, states and tests
2. Integrations — every external system is an unknown with its own failure modes
3. Data migration — driven by quality, not volume
4. Roles and permissions — three roles is roughly twice the work of one

Why integrations cost more than they look

A feature we build entirely ourselves is predictable: we control the code, the data and the tests. An integration is a negotiation with something we do not control, and the cost is dominated by its failure modes rather than its happy path.

Rate limits, partial failures, silent schema changes, sandbox environments that behave differently from production, authentication that expires at inconvenient times. A “simple” integration with a well-documented modern API might be two days. The same integration with a legacy system and a PDF for documentation can be three weeks, and there is no way to know which one you have without looking.

The honest estimate for an integration with a system we have not seen is a range with a spike attached. Anything else is a guess dressed up as a number.

The data migration multiplier

Migration cost tracks data quality, not row count. Moving five million clean, consistent rows is a scripting exercise. Moving forty thousand rows accumulated over twelve years across three systems, with free-text fields where an enum should be and duplicates nobody agrees are duplicates, is a project.

• Are there duplicates, and does anyone agree on the rule for merging them?
• Do required fields have values in every historical record? (They never do.)
• How many date formats are in the date column?
• Are there records referencing entities that no longer exist?
• Does anyone still need the data from before the last system change?

We look at real data before pricing this component. When a client cannot provide it, we price a short investigation first rather than guessing.

Rough bands, honestly stated

These are bands, not quotes. A project at the bottom of a band and one at the top usually differ by integration count and data quality rather than by ambition.

How to make it cheaper without making it worse

The only reliable lever is scope, and the best cut is almost always the same one: build for one role first. A system that serves admins properly and everyone else later costs far less than one that serves three roles adequately from day one.

• Ship one user role, add the others once the core is proven
• Defer reporting — export to a spreadsheet in v1 and build dashboards when you know which numbers people actually look at
• Integrate with one system now, the rest after launch
• Migrate two years of history rather than twelve
• Use a component library rather than fully bespoke design

What does not work as a cost-saving measure: skipping tests, skipping the architecture week, and cutting QA. All three save money in the quote and cost more in the first quarter of real use.

Where our pricing comes from

We run a UK company with an engineering office in Lahore. That structure is why our day rate sits below a comparable London studio while the engineering is done by permanent staff rather than a marketplace contractor.

We say it plainly because clients find out anyway, and because it explains something real about the quote rather than leaving them to guess whether a lower number means a lower standard.

Frequently asked questions