Almost every first conversation about a software project starts with the same question: how much will it cost? It is a fair question, and it is the one I can least responsibly answer in a single sentence. After 25 years of building software for many kinds of companies, I have learned that a quoted number given before the problem is understood is not an estimate. It is a guess that someone will later pay for.

This article does not give you a price, because any figure I printed here would be wrong for your project. What it does give you is the list of things that actually move the cost, so that you can judge an estimate when you receive one, and so that you can make the choices that bring the cost down without hurting the result.

Why two quotes for “the same thing” can differ so much

If you ask three companies to quote for “a customer portal”, you can easily receive three very different numbers. This is rarely because one is overcharging. It is usually because each has imagined a different portal. One assumed a simple login with a list of invoices. Another assumed role-based access, document uploads, email notifications, an admin area and a payment gateway. The third assumed all that plus a mobile app.

Software is unusual in that the same sentence describes products that differ by an order of magnitude in effort. So the first job of any honest estimate is to turn a sentence into a scope: a written description of what will exist when the work is finished. Be wary of any price that arrives without one.

The main drivers of cost

1. Scope: how many things it does

Every feature is a piece of work: designing it, building it, testing it, and then keeping it working as everything around it changes. Features also interact. Adding a fifth user role does not cost one fifth more than the fourth; it touches every screen that checks permissions. When you list what you want, separate the things you need on day one from the things that would be nice later. That single distinction is the most effective cost lever you have.

2. Uncertainty: how well the problem is understood

A well-understood problem, such as a form that stores records and sends an email, can be estimated closely. A problem where nobody is sure how the process should work, or what the data looks like, cannot. Uncertainty does not make the work impossible, but it does make a fixed price risky for both sides. Either the supplier pads the price to cover the unknowns, or the project drifts into disputes about what was included. Spending a little time up front to reduce uncertainty, through a short discovery phase, a prototype or a sample of real data, usually saves more than it costs.

3. Integrations: how many other systems it touches

Connecting to payment gateways, accounting packages, CRMs, courier services or a government portal is where estimates most often go wrong. Each external system has its own rules, its own quirks and sometimes its own approval process that has nothing to do with the code. A well-documented modern API is straightforward. An old system with no documentation, or one that only exports files, is not. If your project involves integrations, ask for them to be identified explicitly in the estimate, along with any approvals you will need to obtain.

4. Users, data and performance

Software for ten internal users and software for ten thousand customers are different engineering problems. More users, more data and more simultaneous activity mean more attention to database design, caching, hosting and monitoring. Most business applications do not need exotic architecture, but you should tell the developer honestly what volume you expect, including where you hope to be in two or three years, so the foundation is not too small.

5. Platforms and devices

A web application that works on desktop and phone browsers is one thing. Native Android and iOS apps, offline operation, push notifications and store publishing are others. Cross-platform tools such as Flutter and React Native can share most of the code between Android and iOS, which is why they are often the sensible choice for business apps, but they do not make the work free. Decide which platforms genuinely matter to your users.

6. Quality, security and compliance expectations

Testing, code review, backups, logging, access control and security hardening are not optional extras, but their depth varies. A system that handles payments or personal data needs more care than a brochure site. If you have contractual or regulatory requirements, tell the developer at the start; adding them late is far more expensive than designing for them. Be cautious of anyone who claims certifications or guarantees they cannot demonstrate.

7. Data migration and existing systems

If you are replacing an existing system, the old data has to move across. Cleaning, mapping and validating that data is often underestimated. Spreadsheets full of free-text entries, duplicate customers and inconsistent dates take real effort to turn into a clean database. Ask early how much of the old data you truly need.

8. After launch

Software is not finished when it goes live. Servers need patching, libraries need updating, bugs surface in real use, and the business keeps changing. Budget for hosting, maintenance and a stream of small improvements. As a rough habit, treat the first release as the beginning of a relationship with the software rather than a purchase that ends.

What an honest estimate looks like

Whatever the final number, a trustworthy estimate has some recognisable features. It describes the scope in plain language, so you can check that it matches what you imagined. It lists assumptions, such as “the payment provider’s sandbox will be available” or “you will supply product data in a spreadsheet”. It breaks the work into milestones so you can see progress and, if needed, stop. It says what is not included. And it explains how changes will be handled, because there will be some.

If the estimate is for a fixed price, it should say what happens when the requirements move. If it is time and materials, it should give a range and describe how you will be kept informed of spending. Our guide to choosing between fixed price and time and materials covers that decision in more depth.

How to bring the cost down without cutting the value

  • Start smaller than you think you need. A focused first release, used by real people, teaches you more than a long specification. You can add the second and third wave of features knowing what matters.
  • Provide real examples early. Sample documents, spreadsheets, screenshots of the current process and a list of the awkward exceptions remove uncertainty faster than meetings do.
  • Say what you are unsure about. A developer can design around an unknown if told about it. Surprises are what cost money.
  • Consider whether you need software at all. Sometimes a configured off-the-shelf tool, a small automation script, or a change to the process solves the problem more cheaply. A good developer will tell you so, even when it means a smaller project.

The honest answer

The cost of custom software depends on what you build, how well you understand it, how many other systems it touches, and how long you plan to keep it alive. Anyone who can give you a firm figure before understanding those things is either guessing or selling something standard.

At IT-Labs we offer a free initial consultation and a written estimate, with no published rates, precisely because the right number only exists after we have understood your problem. If you would like to start that conversation, you can learn more about our custom software development service or get in touch.