Most companies start software projects without knowing things that would materially change their decisions. Not because the information is hidden, but because no one told them to ask. Here is what to know before you sign anything or write a line of code.
The estimate is not the cost
A development estimate is a best guess made with incomplete information. Every variable that is uncertain in the estimate becomes a potential source of additional cost.
The scope might be incomplete. Requirements might change. The existing systems you need to integrate with might be more complex than described. Third-party APIs might behave differently than documented.
The standard deviation on software estimates is high. A project estimated at $50,000 might cost $35,000 if everything goes well or $90,000 if things go badly. Projects rarely cost less than estimated. They often cost more.
Budget with contingency. A 25 to 30 percent buffer on top of the estimate is not excessive for a project with significant unknowns.
The spec is what you will get, not what you imagine
The developer will build what is specified. Not what you meant. Not what makes sense. Not what a reasonable person would infer from your description. What is written down.
This is not malice. It is the nature of the work. A feature that seems obvious to you because you have months of context about your business is not obvious to someone who saw a brief document last week.
This means: everything important must be explicit. If a button should appear only for admin users, say that. If a report should filter by date range, specify what the default date range is, what the minimum and maximum range is, and what happens when there are no records in the selected range.
The investment in detailed specification before development costs less than the development cost of rebuilding features that missed the intent.
Dependencies on third-party systems are significant unknowns
Almost every software project depends on external systems: payment processors, CRM APIs, shipping providers, data sources. Each dependency introduces risk.
The API might have inconsistencies between documentation and behavior. The API might have rate limits that affect your product's performance. The API might change after you have built against it. The API might have outages that affect your product.
For each external system your project depends on, understand: how critical is this integration, what happens to your product if this service is unavailable, and who is responsible for maintaining the integration when the external system changes?
The "done" milestone is different from the "launched and working" milestone
Development teams deliver code. The code passing all defined tests is "done" from the developer's perspective. That is not the same as the product being live, stable, and producing value for real users.
Between "done" and "launched and working" is: staging environment testing, user acceptance testing, performance testing under real load, fixing the bugs that only appear in production, onboarding initial users, and the operational hiccups of any new system.
Plan for two to four weeks of this work after development "completes" before the project is truly delivering value.
You own the relationship with the hosting infrastructure, not the developer
Developers provision hosting for many clients. When they move on, or when you decide to work with a different team, you need access to the infrastructure they set up.
Before development starts, agree on who controls the hosting accounts. Hosting accounts should be in your name, with your payment method, and with the developer having access as a collaborator rather than as the owner.
The same applies to domain registrars, DNS, and third-party service accounts. You should be the account owner. Transferring domain ownership or hosting after the fact is possible but creates downtime risk and negotiation friction.
Off-the-shelf costs will surprise you
Beyond development, production software costs money to run:
Hosting: $50 to $500 per month for most applications, depending on scale. More for compute-intensive workloads.
Third-party services: email delivery (SendGrid, Postmark), error monitoring (Sentry), authentication (Auth0, Clerk), analytics, support tools. Each one adds $20 to $200 per month.
Compliance: data processing agreements, security certifications, and compliance tooling if you handle personal or sensitive data.
Developer costs for ongoing maintenance: bugs need fixing, dependencies need updating, new features need building. Plan for ongoing engineering costs from day one.
Data ownership and portability
If the software holds important data, understand: how do you get your data out if you need to? In what format? With what completeness?
This applies to custom-built software (can you run the database queries needed to export your data?), no-code platforms (Bubble has data export; some platforms do not), and third-party services (CRM data, analytics data, customer records).
You should be able to answer "if this vendor disappeared tomorrow, what would happen to my data?" before you start building.
Your internal team is a project resource
Software projects do not run themselves. Someone on your team needs to:
Be available for questions from the development team (a decision delayed costs developer time).
Review and approve deliverables at milestones.
Gather feedback from internal stakeholders and real users.
Manage the vendor relationship, handle contracts, and process invoices.
This takes more time than most clients expect. Budget 5 to 10 hours per week of internal time for a project of any meaningful scale.
The first version is not the last version
Plan for iteration. The features that users actually use will not be exactly the features you specified. Usage patterns will reveal missing functionality and over-built features that no one uses.
Build a product roadmap for the six months after launch, not just for the first version. The product velocity you can sustain after launch depends on how well the initial architecture was built.
Read our guide to software development contracts before signing anything. Then get in touch to discuss your project with our team, or use the MVP cost calculator to get a baseline estimate before the conversation.