17 Hidden Costs of Software Development Your Quote Won't Mention

The hidden costs of software development are the bills that arrive from outside the development quote: third-party APIs and services, hosting, licenses, change requests, your own team's time and maintenance after launch. Very few of them are tricks, just line items nobody wrote down. My rule of thumb is to add 15-30% contingency on top of the build price, depending on how well the project is defined, and to budget 15-20% of the build cost per year for running and maintaining what you've built.

The short answer: all 17 costs at a glance

I write quotes like these myself as a freelance developer in Denmark, so this list doubles as a reminder of what I need to spell out in my own. Here's the full list in one table. The last column is my own judgment of how far each item can push the budget on a mid-sized project when nobody planned for it.

Notice the pattern: the items with the most budget risk are work, not software subscriptions. If you want the build price itself first, start with my European software development cost guide. This post covers everything around it.

Costs that grow during the build

The first six items appear while the product is being built. They're the hardest to put a number on, because they depend on how clearly the project was defined and how often the plan changes along the way.

1. Discovery nobody priced

When a quote rests on a short brief and one call, the open questions haven't gone away. They get answered mid-build instead, when each answer can mean reworking something that already exists. You pay for that thinking either way. The cheapest place to pay for it is a short discovery phase before development, where requirements, wireframes and an estimate are written down. I break down what that typically involves in my guide to discovery phase cost.

2. Change requests

Seeing the first screens gives you new ideas. That's healthy, and it's also the most common reason budgets slip. On an hourly contract you pay for the extra time directly. On a fixed-price contract, changes are priced separately as change orders. Before you start, ask how changes are estimated and approved, and what rate applies to out-of-scope work. I compare who carries that risk in fixed price vs hourly rate.

3. Your own team's time

No developer can build your product without you. Someone has to answer questions, approve screens, get access to other systems and test before launch. As a starting point, plan for a few hours a week from whoever owns the project on your side, and more in the weeks before launch. That time never appears in a quote, but it costs salary and usually comes out of other work. If nobody can spare it, waiting is often cheaper than starting.

4. Design, copy and translations

Many quotes assume you'll supply the designs and content, or that the product uses a standard component library. "Client provides content" means you write the help text, emails, error messages and terms. Selling in several European markets adds a translated version of all of it for each language, plus someone to check it. Custom screen design is its own line item, and stock photos and web fonts can need licenses too. Check what the quote assumes and put a number on what you're expected to deliver.

5. Data migration

Moving customers, orders or history out of spreadsheets or an old system is rarely a clean copy. You'll find duplicates, fields used for something other than their name suggests, and gaps someone has to decide about. The import itself can be quick. The cleanup and the decisions take time on both sides. Ask for migration as a separate line in the quote, and let the developer see a sample of the real data before the price is set.

6. API access to other systems

An integration with your accounting software, CRM or ERP looks simple on a feature list. In practice the other vendor may only open its API on a higher plan, require a partner agreement, charge for sandbox accounts, or bill consulting hours of its own. Documentation can be thin, and every failure case needs handling. Ask the other vendor what API access costs before you ask a developer to price the integration.

Third-party services, licenses and hosting

The next six items are the classic hidden costs. None of them is usually large on its own, but they recur every month, several grow with your user count, and a developer can't fix their price because the money goes to someone else.

7. Hosting, staging and EU data residency

Hosting is rarely the big number, but it never stops: servers, a database, backups and a domain pointing to the right place. People often forget the staging environment, a copy of the app where new versions are tested before release, which can nearly double the server bill. For a typical web app, think tens to a few hundred euros a month. If your customers expect their data to stay in the EU, pick an EU region from day one, because moving later is a project of its own. Either way, the hosting account should be in your company's name.

8. Usage-based services

A modern web app rents a lot of small parts: transactional email, SMS, maps, search, error tracking and file storage. Most have a free tier, which makes them cheap at launch and less cheap at scale. Many are American and bill in US dollars, so your monthly cost also moves with the exchange rate. Ask your developer for a list of every service the product uses, what each costs today, and what it would cost with ten times the users.

9. Payment processing fees

If you take payments, the payment provider takes a cut of every transaction. On Stripe's pricing page for Ireland, a standard EEA card costs 1.5% + €0.25, a UK card 2.5% + €0.25 and other international cards 3.15% + €0.25, with another 2% when currency conversion is needed. Rates vary a little by country, and invoicing or subscription add-ons cost extra. These fees never appear in a developer's quote because they aren't the developer's, but they come off your margin on every order.

10. AI API usage

If your product calls a language model from OpenAI, Anthropic or similar, you pay per use, measured in tokens (small chunks of text). One request costs next to nothing. A feature a thousand users hit every day can become a noticeable monthly bill. The cost depends on the model, how much context you send along, and how often the feature runs. Get a per-user estimate before launch. I work through examples in my guide to estimating LLM API costs.

11. Paid packages, fonts and tool licenses

Most of what developers build with is free, open-source software. Some packages, component libraries, admin panels and fonts need a paid license, though, and some must be renewed every year to keep receiving updates. Ask which paid licenses the product relies on, whose name they're registered in, and what happens if they lapse. A license in your developer's name becomes your problem the day you stop working together.

12. Domains and app store accounts

Small amounts, but they recur. Domains renew yearly. Publishing on the App Store requires an Apple Developer Program membership at $99 a year, and Google charges a one-time $25 fee for a Google Play developer account. If you sell anything inside the app, both platforms typically take a share of those sales as well. Create these accounts in your company's name from the start, so you never have to transfer apps between accounts later.

Costs that start after launch

Launch day isn't the last invoice. The final five items begin once the product is live, and they're the easiest to forget because they sit outside the project itself.

13. Framework and dependency updates

Software ages even when nobody touches the code. Frameworks, packages and server software receive security patches, and older versions stop getting them. Laravel ships a new major version every year, and each one gets bug fixes for 18 months and security fixes for two years, according to Laravel's support policy. Small, regular updates are cheap. Jumping several versions at once is a project in itself, as I explain in what a Laravel upgrade costs.

14. Bug fixes after launch

Real users find bugs no test caught. The question is who pays. Some contracts include a warranty period where defects in the delivered work are fixed at no charge, and some don't. Get it in writing: how long the period lasts, what counts as a bug, and what counts as a new request. "The button doesn't work" is a bug. "The button should do something else" is a change, and changes cost money.

15. Monitoring, backups and out-of-hours support

Who notices when the app goes down on a Sunday night? Uptime monitoring, error reporting and backups need setting up, usually a small subscription, and someone who responds. A backup is only worth something once someone has tested restoring it. If you need support outside business hours, that's a separate agreement and it costs more than weekday help. Plenty of products don't need on-call cover, but that should be a decision, not a surprise.

16. GDPR and security work

If the product handles personal data, the GDPR requires a data processing agreement with every service that processes that data on your behalf. You also need sensible access controls and a plan for what happens after a breach. If any of those services are based outside the EU, check how the data transfers are covered. Some of this is developer work, like logging and data deletion. Some is yours, like the privacy policy. Larger or sensitive systems may also need an external penetration test. All of it is cheapest to know about before development starts.

17. Handover and switching developers

The day you change developers or hire your first in-house engineer, the new person has to learn the codebase. Without documentation, access and a proper handover, weeks can pass before they ship anything. You pay this cost late, but it's decided early. Make sure the code lives in your own repository from day one, that every account is in your name, and that documentation is part of the deliverables. My clients own their code from day one, and I'd expect the same from any supplier.

How much contingency to add to your budget

You can't price all 17 items exactly in advance. What you can do is make room for them. Here's how I'd recommend framing it:

• Contingency on the build: 15% if there's been a discovery phase and the scope is written down. 25-30% if the project is loosely defined or depends on integrations nobody has worked with before.
• Even on fixed price: the developer's own buffer is already in the price, but changes and anything out of scope come on top. Keep at least 10% for that.
• One-off items as their own lines: copy, translations, licenses, data cleanup and accounts don't belong in the contingency. List them separately.
• Running costs from day one: 15-20% of the build cost per year for hosting, services, updates and small improvements.

Here's a hypothetical example for a project quoted at €35,000, where the requirements are reasonably clear but there was no discovery phase. The figures aren't from a real project, but the proportions are typical.

So a €35,000 quote becomes a realistic first-year budget of roughly €50,000, before counting your own team's time. That looks steep, but it's what the project was always going to cost. The difference is that you know it before you sign.

When hidden costs mean you should buy, not build

Add up all 17 items and the build-or-buy math can flip. An off-the-shelf SaaS tool includes hosting, updates, backups and support in its subscription. If it covers around 80% of what you need, it's often cheaper over three to five years than building your own, even when the per-seat price looks high. Compare total cost of ownership over five years, not build price against monthly fee.

Off-the-shelf tools have hidden costs too: per-seat pricing that climbs as you grow, paid add-ons, and data that can be hard to export. Custom software pays off when it supports something specific to how your business works, or when licenses over a few years would cost more than owning the product outright.

If your budget only just covers the build, with nothing left for contingency or running costs, that's a sign to start smaller or buy a standard tool. It isn't a sign to look for a cheaper developer.

Next steps

Take the quote you've received, or the idea you're working on, and go through the list. Mark each item as included, not relevant, or a question to ask. Whatever is left on the list goes straight back to the developer.

If you're weighing several offers, use my method for comparing software development quotes so you're comparing like with like. You can see how I price discovery, builds and ongoing work on my pricing page.

Frequently asked questions

Are hidden costs a sign of a dishonest developer?+

Rarely. Most hidden costs are money the developer never receives, like hosting, payment fees and licenses, or work that depends on decisions nobody has made yet. The real warning sign is a quote with no exclusions and no assumptions. Then you don't know what you've bought, and the gaps only show up when the first extra invoices arrive.

Should hosting and third-party accounts be in my name?+

Yes, wherever possible. When accounts are registered to your company and paid with your card, you keep control if the working relationship ends, and you can see exactly what you're paying for. Some developers resell hosting with a markup in exchange for managing it. That can be fine, as long as it's transparent and you can have the accounts transferred to you.

Can I get a fixed monthly price for maintenance?+

Yes, many developers offer a monthly retainer covering updates, monitoring, backups and a set number of hours for small fixes. Usage-based services such as email, SMS, payments and AI are usually billed separately, because they rise and fall with your user numbers. Ask what happens to unused hours, and what rate applies once the included hours run out.

How does VAT work on software services from another country?+

For business-to-business services bought from a supplier in another EU country, the reverse charge usually applies: the supplier invoices without VAT, and you account for it in your own VAT return. Services from outside the EU are typically handled the same way. If your business is VAT-registered with full deduction, it often nets to zero, but it has to be recorded correctly. Rules vary by country, so check with your accountant.