What Actually Drives the Cost of Custom Software.

Every agency gets asked the same question in the first call: what will this cost. Every honest answer starts the same way, which is that it depends, and that answer is useless unless someone tells you what it depends on. This is that list.

We are not going to print a price table here. Any number published without knowing your scope is either marketing or a guess, and both cost you more than they save. What follows is the set of variables we actually price against, so you can look at your own project and form a realistic expectation before anyone quotes you.

Scope is not a feature list

The single biggest driver is not how many features you want. It is how well defined they are. A brief that says "user dashboard" can mean a read-only summary screen or a configurable analytics workspace with saved views and exports. Those are different projects by an order of magnitude.

This is why we write a scope before anyone commits money. Not to slow things down, but because an undefined build gets priced with a risk margin, and that margin is money you pay for someone else's uncertainty. A tight scope removes it.

How many platforms you are really shipping

Web only is one target. Web plus iOS plus Android is three, even with React Native sharing most of the code. The shared codebase saves you a great deal of the build, but store submission, device testing, platform review cycles and native edge cases are real work on each platform you add.

The cheapest decision available to most founders is shipping one platform first, learning from real users, then expanding. The expensive decision is shipping three at once because it felt more ambitious.

Integrations, and who owns the other side

Connecting to a well documented, modern API is routine. Connecting to a payment provider with regional requirements, a legacy ERP, or a partner system whose documentation is a PDF from four years ago is not. The work is not the integration itself, it is discovering how the other system actually behaves versus how it is documented.

When you brief a project, list every external system it must talk to. That list moves quotes more than almost anything else on this page.

Whether design exists, and whether it is buildable

Arriving with finished, considered designs removes a phase. Arriving with nothing means design is part of the build. Arriving with designs that were never checked against engineering is sometimes the most expensive case of the three, because someone has to decide which approved screens are getting rebuilt.

This is the reason we keep design and engineering in one team. Feasibility becomes part of the design conversation instead of a bill that arrives afterwards.

Data you are bringing with you

A greenfield product starts empty. A replacement for something you already run comes with years of records that need to move, and real data is always messier than the schema suggests. Migration, cleaning, validation and the cutover plan are their own workstream, and they are routinely underestimated because the new product gets all the attention.

What happens after launch

A build has an end date. A product does not. Hosting, monitoring, dependency updates, store requirement changes and the fixes that only appear under real usage all continue. Decide upfront whether you are running that yourself or keeping the team that built it, because retrofitting a handover later costs more than planning one.

How we price against all of this

Pricing is negotiated per project against an agreed written scope. Not hourly, and not from a package list, because neither reflects what actually makes a project expensive. You get a quote before committing, payment terms are agreed upfront, and scope changes mid-build go through a written change order so nothing moves silently.

If you want a real number, the fastest route is one call and a written scope. That is the only way anyone can give you a figure that means something.