How much does custom software cost? What drives the price

It depends on how much has to be discovered, decided and connected, not on how many screens there are. For Skofi's own work, the owner-stated position is that most projects land between $5,000 and $10,000 (US dollars), and larger systems cost more than $10,000. That is a typical range for our projects, not a market benchmark and not a quote. We quote after a discovery conversation, once we have seen the process, its exceptions and the systems involved, and the quote says what is included and what is not.

We do not publish day rates, hourly rates, market averages or per-feature prices, and you should be suspicious of any article that does. Averages across the whole industry mix a form on a database with a regulated multi-country platform, and the number that results describes neither. What is useful, and what the rest of this article gives you, is the list of things that move the price and a way to check a quote against them.

If you are not yet sure that custom is the right route, read our build-or-buy article first: it covers the arithmetic of licence drift, integration tax and workaround cost. Our article on custom software, no-code and AI-built apps compares the routes. This one assumes you have decided to build and want to understand the bill.

Ten things account for most of the difference between one quote and another. None of them is a number you can look up; each is something you can assess for your own project before you speak to anyone.

Scope clarity is the largest driver and the cheapest to fix

Our automation cost article makes the same point for process automation: the happy path is the smallest term. The expensive cases are the order for a product you stopped selling, the customer spelled two ways, the invoice that arrives as a photograph. A team that can say how many items were touched by hand last month, and why, has already written most of the specification. A team that describes the process as designed is describing something that does not run.

Permissions are where simple apps become complicated

'Users can log in' is a day of work. 'A branch manager sees only their branch, a clerk can enter but not approve, an auditor can read everything and change nothing, and a contractor sees only their own jobs' is a design problem, a database design and a test suite. The trading ERP we built has a grid of eighteen modules against five actions, editable per role and overridable per person, and enforces it in the navigation, the routes, the write layer and a database trigger. That is a lot of care, and it is the reason the system can hold the company's books. If your app does not need that, say so and the quote falls.

Data migration is often a project of its own

On the trading ERP the books lived in a single-machine desktop application whose export produced nothing usable, so recovering the history meant writing a decoder before any new module could be built. We describe it as part of the engagement, and in an estimate it would be a separate line. Ask any studio whether migration is in the price, which years, which entities, and who proves that the totals match.

Integrations cost most where you have least control

An integration to a modern system with a documented API and sandbox is routine. An integration to a system with a partial API, strict rate limits or no test environment is not, and neither you nor the studio can fix that. On the fleet order automation the client kept monday.com and we built only the gap: a parser, a portal and an SLA engine. Keeping the platform was cheaper than replacing it, and it is a pattern worth asking about before you commit to a full build.

A quote should say, in plain words, what you are getting, what you are not, and what would change the price. Items that are commonly left out are exactly the ones that surprise people later, so ask about each of them by name.

Also check the practicalities. State the currency. Our range is in US dollars, and for international clients we are paid through Wise, PayPal or Payoneer, so the exchange rate and any transfer fees are worth agreeing at the start. Confirm that the repository and the hosting accounts are in your name from the first commit, which is how we work, and ask every provider the same.

Use fixed price for a defined first release whose acceptance criteria you can write down, and time-and-materials with a ceiling for work that genuinely cannot be defined yet. Avoid both extremes: a fixed price on a vague brief, and open-ended time-and-materials with no visible output. In each case somebody carries a risk, and the question is whether they have been paid to carry it.

Many good engagements use both: a short discovery to settle the unknowns, then a fixed price for a defined first release, then time-and-materials or a retainer for what you learn from real use. If a provider will only offer one model for everything, ask why.

Software has running costs that start the day it goes live and do not stop. Ask about each of them before the build, because they decide whether the total cost of owning the system matches what you expected to pay for it.

Budget attention for the second year as well as the first. Upstream systems change their fields, credentials expire, and the person who understood the integration moves on. A budget of zero is how software becomes something nobody dares touch. We do not publish a percentage for upkeep, because we have not measured one across our work and any figure we gave would be invented. Ask the provider to state their basis for post-launch work in writing: a retainer, a defect-fix period with time-and-materials afterwards, or something else.

Give every provider the same written brief and ask each to price the same first release against the same assumptions. Then compare assumptions, exclusions and acceptance criteria before you compare totals. A cheap quote and an expensive one are often quotes for different things.

1. 01Write a one-page brief. Our custom software, no-code and AI-built article has a six-item version: the process, the data and who may see it, the systems it touches, how long you expect to use it, who maintains it, and your exit.
2. 02Say what the first release is and is not. Name what you are deferring, so nobody prices it by accident.
3. 03Ask each provider to list their assumptions and what is excluded, in writing, in the same document as the price.
4. 04Ask for acceptance criteria you could test yourself, such as 'a branch manager cannot read another branch's records', not 'a secure system'.
5. 05Ask the same ten questions of each, including who reviews the code and what the tests are. Our article on hiring a developer who uses AI coding tools sets them out.
6. 06Compare payment terms, currency, ownership of the code and accounts, and the handover contents. These differ more than the totals do.
7. 07Talk to the people who will actually do the work. A proposal written by one person and delivered by another is a risk worth naming.

Do not treat the lowest quote as the baseline or the highest as the safe choice. Look instead for the quote whose assumptions match your reality best and whose exclusions you understand. If two quotes differ by a large margin, the useful question is what the cheaper one assumes that the other does not.

• A single number with no assumptions, exclusions or acceptance criteria. You cannot tell what you are buying.
• A price given before anyone has asked about your exceptions, your data or your integrations. It is a guess, however confident the tone.
• No mention of testing, staging, backups or handover. These are the items that get cut when the budget is tight.
• The code, repository or hosting accounts in the provider's name 'for now', or only in an AI tool's own workspace.
• A price that falls sharply when you push back, with no change to the scope. Either the first number had padding in it or the second has a gap.
• Dramatic speed or saving claims from AI tooling with no evidence from comparable work. Use of AI is not a reason for a high price or a low one by itself.
• Open-ended time-and-materials with no ceiling, no increments and no written note of what was done.
• A refusal to say what would make them advise you not to build, or to buy something instead.
• Pressure to sign quickly. Software is a long relationship, and a provider worth having can wait for you to read the assumptions.

Ship a smaller first release, reuse platforms where they fit, settle the unknowns before the build, and protect the parts that are expensive to retrofit. That order matters: the first two save money and the last one is what stops the savings turning into a second bill.

Things that lower the cost safely

• A smaller first release. Build the main flow and make the rare exceptions visible instead of automatic. Real use will tell you which exceptions matter, and it is cheaper to add them then.
• Reuse platforms where they fit. Keep the work platform, the accounting package or the CRM and build only what does not exist, as we did on the fleet order automation. Our build-or-buy article calls this the middle option, and it is usually the cheapest route to something that works.
• Buy the commodity parts. Authentication, payments and email sending are services you rent, not features you should write.
• One person who can decide, and an agreed system of record. A question that takes several meetings to answer is often the largest hidden cost on a small project.
• Real samples of every document and record on day one, creased ones included. A clean sample makes a build look cheap and then late.
• Migrate less history, or leave it readable in the old system.
• A clean, consistent interface on proven components. Bespoke visual design is a choice, not a requirement, for an internal tool.
• Fix the intake upstream. Many exception paths disappear if the form or the process that feeds the system is fixed first.

Things that look like savings and are not

• Skipping tests on money, permissions and deletion. A wrong answer in those places looks like a right answer until it is expensive.
• Enforcing permissions in the screens only. Retrofitting database-level rules later costs more than doing them at the start.
• No audit trail. If you will need to say who changed a figure, add it from the start, because it cannot be reconstructed afterwards.
• No backup you have restored, no staging, no rollback path.
• No handover. A build nobody else can maintain moves the cost to the day the builder is unavailable.
• Accepting AI-generated code unread because it was quick. Our vibe-coding-to-production article covers what review of such code finds.

• Qualitative advice is not a budget. If you need a number for a funding round or an internal approval, you need a discovery conversation, and even then it is a range until scope is settled.
• Our range is ours. It describes Skofi's projects, from a small studio run from Pakistan, and says nothing about what an agency in another market will charge. Compare quotes, do not compare a range with a quote.
• Settling scope up front is not always possible. Some products only reveal their shape through use, and for those the honest model is small funded steps, not a detailed specification.
• Regulated data, such as health or payment data, needs specialist assessment whichever route you take. Nothing here makes software compliant, and none of it is legal advice.
• 'Smaller first release' can be a trap if the missing piece is what makes the system useful. Cut exceptions and polish, not the core of the process.