How much does custom software development cost?
Custom software costs team size times weeks, plus running costs. Here is what drives the number, how pricing models compare, and what each budget band buys.
Custom software costs what the team costs multiplied by how long the work takes. A small, focused product built by two or three senior people can take a couple of months. A multi-role platform with integrations and compliance work takes a larger team and much longer. Anyone who quotes a number without asking about scope, users and integrations is guessing, and the guess usually gets corrected later, in your invoice.
Key takeaways
- Custom software cost is people multiplied by time, so every pricing question comes down to how many people you need and for how many weeks.
- Scope, user roles, integrations, platforms, compliance, design depth, data migration and uncertainty drive the weeks far more than the choice of programming language does.
- Fixed price, time and materials, and a monthly team are three different ways of deciding who carries the risk of the unknown, and none of them is best in every case.
- The build is only part of the cost: hosting, monitoring, maintenance, third-party APIs and, for AI features, model usage continue after launch.
- The cheapest way to lower cost is to remove decisions before development starts, not to shorten the testing, monitoring or handover.
- A quote that cannot explain what is excluded, who owns the code, or what happens when scope changes is a warning sign, however low the number.
- Budget bands are best read as scope types: the more of the budget that goes to integrations, compliance and several user roles, the less is left for the core product.
What does “custom software” actually cost?
It costs the loaded weekly cost of the people who design, build, test and deploy it, times the number of weeks, plus a buffer for what nobody could foresee.
Everything else refines that formula. A cheap quote means a smaller team, fewer weeks, less senior people or less included. An expensive one is the opposite, or it contains risk padding because the scope is vague.
Cost = (people on the team × weeks) × weekly rate per person + buffer + running costs.
The hard part is estimating the weeks. The same feature can take three days or three weeks depending on what already exists, what the data looks like and which external systems have to cooperate. That is why serious estimates start with a short discovery rather than a price list. If you want to see the same reasoning applied to a smaller first release, read how much an MVP costs.
What drives the number?
Eight factors account for most of the difference between a modest and a large project. They are listed here roughly in order of how often they move an estimate.
| Driver | Why it adds weeks | How to keep it down |
|---|---|---|
| Scope (number of distinct features) | Every feature needs design, build, tests, edge cases and review | Write the one outcome the first release must achieve and cut the rest |
| User roles | Each role adds screens, permissions, notifications and test cases | Launch with one role; handle others manually at first |
| Integrations | Each external system has its own documentation, limits, sandbox and failure modes | Integrate only what you cannot do by hand for the first weeks |
| Platforms | Web, iOS and Android multiply testing and release work | Start with the platform your users actually live on |
| Compliance and security | GDPR, health, financial or children’s data add controls, audit trails and reviews | Decide early which data you really need to store |
| Design depth | A branded, animated interface takes far longer than a clean standard one | Use an established component library and spend design effort on the core flow |
| Data migration | Old data is usually messier than anyone remembers | Migrate less, migrate later, or clean at the source first |
| Uncertainty | Unclear requirements, unknown systems and many stakeholders create rework | Pay for a short discovery to turn unknowns into decisions |
Scope and user roles
Scope is the largest lever. A booking tool with a calendar, a payment and an e-mail confirmation is one size. Add waiting lists, multi-location rotas, loyalty points and reporting and it is several times that, because the features interact.
User roles compound this. A single type of user is cheap. Once a customer and a supplier, or a patient and a clinic, have to interact, you add flows, permissions and notifications in both directions. An internal admin panel is effectively a second small product.
Integrations and platforms
An integration is a small project that depends on a system you do not control. Stripe is well documented and quick to connect for simple cases. Older ERP systems or partner APIs may have poor documentation, rate limits and surprising data formats, which is where estimates fail most often.
Platforms matter similarly. With React Native and Expo one codebase can serve web, iOS and Android, which is cheaper than three teams, though store review and device testing remain.
Compliance, design depth and data migration
Compliance is rarely a feature; it is a property of how everything is built. Health or financial data means access logs, encryption and retention rules. Adding that late is far more expensive than designing for it.
Design depth is the most negotiable driver. A restrained interface on a proven component set such as Radix is fast to build and easy to change. Custom motion and many unique screens cost real weeks. Data migration is the quiet one: ten years of spreadsheets means duplicates, inconsistent formats and missing values, so budget for it explicitly.
Uncertainty
Uncertainty is not a feature, but it is the factor that most separates good estimates from bad ones. When requirements are unclear, the team either pads the quote or discovers the answer mid-build, which means rework. A short, structured discovery phase reduces uncertainty cheaply. If you are preparing to request quotes, a clear written brief helps a great deal; see how to write a software project brief.
What team shapes are common?
The team shape determines the weekly cost, and the right shape depends on how complex the product is, not on how big the budget is.
| Shape | Typical makeup | Suits |
|---|---|---|
| Pair | One senior full-stack engineer plus a part-time designer or lead | A narrow prototype or a very focused first release |
| Small squad | Tech lead, one or two engineers, a designer part-time | Most MVPs and first versions of web apps and SaaS |
| Product team | Lead, several engineers, a designer, QA support | Platforms with several roles, integrations and a long roadmap |
| Augmented team | Your own engineers plus external seniors in specific roles | Companies with an in-house team that needs capacity or expertise |
Seniority matters more than headcount. Two senior engineers who have built similar systems before often finish sooner than four less experienced people, and larger teams add coordination overhead. Ask who will actually write the code, and whether they are on the calls.
Fixed price, time and materials, or a monthly team?
These models differ in who carries the risk of the unknown, not in how much work gets done.
| Model | How it works | Advantages | Drawbacks |
|---|---|---|---|
| Fixed price | Agreed scope, date and price | Predictable budget; strong incentive to finish | Needs clear scope; change requests cost extra; agencies may pad the price for risk |
| Time and materials | You pay for actual hours or weeks worked | Flexible; you pay only for what is done; easy to change direction | Budget can drift; needs trust and good reporting |
| Monthly team | A dedicated team for a fixed monthly fee | Continuity; fast iteration; the team learns your product | Less suitable for a one-off project with a hard cap; you must keep it busy with useful work |
Fixed price works when scope is genuinely known, which is why it usually follows a discovery phase. Without discovery it is either heavily padded or renegotiated every time something changes. Time and materials suits exploratory problems; the risk is drift, so insist on a weekly demo. A monthly team suits products that keep evolving, at the price of an ongoing commitment.
A worked example (hypothetical)
Imagine a clinic booking platform with online appointments, reminders by e-mail and SMS, staff calendars, and payments through Stripe. The numbers below are invented for illustration. Your rates and scope will differ.
Assume a blended cost of €4,000 per person-week. That figure is arbitrary and chosen only to make the arithmetic readable.
| Role | Allocation | Weeks | Person-weeks |
|---|---|---|---|
| Tech lead | 50% | 10 | 5 |
| Designer | 50% | 4 | 2 |
| Engineer A | 100% | 8 | 8 |
| Engineer B | 100% | 8 | 8 |
| Total | 23 |
23 person-weeks × €4,000 = €92,000. Add a 10% buffer for the unknown and you reach roughly €101,000.
Now see what changes the number:
- Add a second user type, such as a patient portal with medical history: perhaps 6 to 10 more person-weeks.
- Add an integration with a clinic’s existing practice-management system: depends entirely on that system’s API, which is why you do not price it before you have read the documentation.
- Skip the staff calendar sync in release one and let staff use a shared view: a few person-weeks saved.
Two projects that sound identical (“a booking app”) can differ by a factor of three. That is why a range and a discovery phase are more honest than a number after a ten-minute call.
What do you pay after launch?
Launch is the start of the running costs, and a budget that ignores them will be short in year one.
- Hosting and infrastructure. Servers, databases and storage on AWS, GCP or Cloudflare. Modest for a small product, growing with usage.
- Monitoring and error tracking. Logs, metrics and alerts, so someone knows about a problem before a customer does.
- Maintenance. Dependency updates, security patches, small fixes and browser or operating-system changes. A commonly quoted rule of thumb is to set aside a meaningful share of the build cost each year, often somewhere between 10 and 20 percent. Treat that as a starting assumption, not a law.
- Third-party services. Payment fees, e-mail and SMS providers, mapping, identity checks and any API that charges per call.
- LLM tokens. If the product uses a language model such as Claude or a GPT model, you pay per token processed. Cost per answer depends on prompt length, retrieval, and model choice, and it should be measured from the beginning rather than discovered in the first invoice. See AI in your business: from demo to production.
Ask any provider for a one-page estimate of monthly running costs at your expected usage.
How can you lower the cost without paying for it later?
Reduce the number of open decisions and the size of the first release. Do not reduce testing, monitoring or ownership.
- Write the one metric that matters. If the first release is supposed to prove that customers will pay, everything not serving that is a candidate to cut.
- Do the boring parts manually first. An admin panel, reporting, and some integrations can be spreadsheets or existing tools for the first weeks.
- Pick standard components. A proven design system, authentication provider and payment platform save weeks.
- Decide before building. A clickable prototype tested with real users is far cheaper than changing a built feature.
- Check whether you need custom at all. See build versus buy software.
- Keep a weekly demo. Frequent demos catch misunderstandings when they cost days, not months.
Three things should not be cut even on a tight budget, because they are cheap early and expensive later: the code living in your own repository from day one, automated tests on the flows that make money, and error monitoring before the first user arrives.
What are the red flags in a quote?
A very low price is not the warning sign on its own; a price you cannot explain is.
- No discovery and no questions. A quote after a short call, with no questions about users, data or integrations.
- A single number with no breakdown. You cannot see what is included, who works on it, or for how long.
- Vague exclusions. Hosting, third-party fees, testing and handover are not mentioned.
- Unclear ownership. The agency keeps the repository, cloud accounts or domain, so changing supplier means starting over.
- Juniors on the work. The senior people on the sales call are not the people writing the code.
- No demos. Months without something you can click.
A good quote states assumptions, lists exclusions, names the team, describes how change requests are handled and says who owns what. For a wider checklist on picking a partner, see how to choose a software development company.
How do budget bands map to scope?
The bands below are orientation, not prices. They describe the kind of scope that usually fits, and a good provider will tell you honestly if your idea sits in a different band.
| Budget band | Typical scope |
|---|---|
| Under €25k | A prototype, a single-purpose internal tool, a landing page with a small application behind it, or an experiment designed to test one assumption |
| €25k to €75k | A focused MVP with one main user role, a handful of core flows, one or two simple integrations and basic admin |
| €75k to €150k | A fuller first product: several roles, several integrations, a proper admin area, stronger security work, polished design and a mobile or second platform |
| €150k and above | A platform with complex domain logic, compliance requirements, many integrations, multiple apps, data migration or a long roadmap with a standing team |
At the lower end you choose one narrow job and do it well. At the upper end, much of the money goes to things users never see: integrations, security, migration and reliability.
If your idea does not fit the budget, the answer is almost always to cut scope, not quality. A smaller product that works and is owned by you is worth more than a larger one that is unfinished.
How Hidook approaches this
Hidook is a remote-first product engineering studio that designs, builds and runs custom web applications, SaaS platforms, MVPs, AI and LLM systems and cloud infrastructure. We do not give a price after a first call. We start with a discovery in week 0: workshops, constraints, the one metric that matters, and a written scope and price at the end.
From there, the engagement models are a Sprint (fixed price and fixed date, with the price set after discovery), a Product team (a dedicated squad on a monthly basis) or a Partnership (a monthly retainer for fractional CTO work and senior help). During the build we demo and deploy to a live URL every Wednesday, you own the repository and cloud accounts from day one, tests run on every pull request, and error tracking is in place before the first user.
We also say no. If a spreadsheet or an off-the-shelf tool would do the job, we will tell you. See web app and SaaS development and MVP development for how this works in practice.
Frequently asked questions
Why is custom software so much more expensive than a template or off-the-shelf tool?
An off-the-shelf tool spreads its development cost across thousands of customers, while custom software is paid for by one. You are buying exactly the workflow you need, and that is worth the cost only when no existing tool covers it. If an off-the-shelf product fits most of your needs, start there.
Can I get an accurate quote from a short call?
Not an accurate one. After a short call a provider can give a range and tell you which factors will move it. A reliable price comes from a discovery phase that produces a written scope, a prototype and a list of risks.
How much should I budget for maintenance after launch?
Plan on an ongoing yearly cost for updates, security patches, hosting and small improvements. A common rule of thumb is a share of the original build cost, but the real figure depends on usage and how much the product keeps changing. Ask for a monthly running-cost estimate before you sign.
Does using AI features change the cost?
Yes. There is extra build effort for retrieval, evaluation and safeguards, plus an ongoing cost per answer from model usage. Measure both from the first week.
What if my budget is smaller than any quote I receive?
Reduce scope rather than quality. Cut roles, integrations and platforms, build the core flow only, and do secondary tasks manually until the product proves itself. A narrow product that is tested and owned by you is a better starting point than a broad one that is unfinished.
If you want to test your idea against these cost drivers, write to [email protected] or book a call at https://hidook.tech/contact/.