They are rarely hidden in the sense of being concealed. They are simply outside the boundary the proposal drew, and the boundary was drawn around development. The build price answers "what will you charge to write this?" The question you actually need answered is "what will this cost me to have?" — and the gap between those two is where budgets fail.
Most of the gap is predictable and can be listed before signing: third-party services with their own pricing, non-production environments, integration effort with systems the vendor does not control, data migration, support after delivery, and the internal time your own people will spend. None of these are the vendor's fault. All of them are yours to total up.
A crowdfunding platform quoted at 55,000 went live at roughly 55,000 of development. In the first year it also spent on identity verification per check, payment provider fees, hosting across three environments, an email service, monitoring, and two months of a developer's time on changes the launch revealed. None of it was a surprise to anyone who had asked. It was a surprise to the budget.
Identity and KYC checks, payment and payout fees, SMS, document signing, data providers. These scale with usage, which means they are smallest exactly when you are estimating them.
Staging, testing and demo environments are how you avoid changing production at eleven at night. They are also three more sets of infrastructure and often three more sets of third-party sandboxes.
Every external system brings onboarding, sandbox access, its own review process and its own timetable. A proposal can quote the code; it cannot quote the provider's approval queue.
If anything is being replaced, moving the data is a project with its own mapping, cleaning, verification and cutover. Where it appears as a single line in a proposal, it has not been scoped.
Whatever is included during the build usually ends at handover. What replaces it, at what price, from what date — and what you do in the gap if the answer is "we will discuss it then".
Requirements, review, acceptance, content, and answering questions. On a serious project this is not a rounding error; it is a named person's job for months, and it is never in the quote.
Policies, terms, data-protection work, and whatever your jurisdiction requires. Software adjacent, budget relevant, and rarely the vendor's to deliver.
Dependency updates, security patches, provider API changes and platform deprecations. Software that nobody maintains does not stay still; it degrades on somebody else's schedule.
