← Back to overview
What should you look out for in a custom software proposal?
What a strong proposal makes clear
A proposal is both a contractual and an intellectual document. Check whether at least the following is explicit, not just implied:
- Scope and excluded work: what belongs to v1 / MVP, what is phase 2 or optional? Which assumptions about data, integrations and infrastructure apply?
- Definition of Done: how do you know when something is "finished" (testing, acceptance, performance, accessibility, documentation)?
- Changes: how do you handle new insights during the build: process, impact on planning and budget, who decides?
- Intellectual property and licences: who owns source code and design, what about open source and third-party components?
- Support and handover: is there a warranty or stabilisation period, documentation, monitoring, SLA options for after launch?
- Exit: how do you hand over the project if you switch partners: repo, secrets, CI/CD, environments?
Red flags
Vague promises without acknowledgement of risk, prices without clear scope, or "everything in one big bang" with no interim releases: these increase the likelihood of tension and rework.