Most software problems are visible, in hindsight, in the proposal. Here are ten warning signs worth noticing before you commit.
1. A price with no questions asked
If someone quotes confidently after one short call, they are guessing, or selling a template. Good proposals follow real questions about your problem and users.
2. Fixed price, vague scope
A firm number against a fuzzy description is a recipe for argument later. Ask for the scope, assumptions and exclusions in writing.
3. No mention of users
Software succeeds when people use it. A proposal that is all features and no discussion of who uses it, and how, is missing the point.
4. Technology before problem
Heavy emphasis on buzzwords and tools, light on what you are trying to achieve. The tool should follow the need.
5. Unclear ownership
Who owns the code? What licences are involved? What do you receive at handover? These should be explicit before work starts, not discovered at the end.
6. No plan for testing
"We'll test it" is not a plan. Look for mentions of testing with real users, on real devices, and checks for accessibility and security.
7. Impossible speed
"Any app in two weeks" usually means a template or corners cut. Real timelines depend on scope and how fast decisions arrive.
8. Nothing about support
What happens when something breaks in month three? If aftercare is not mentioned, ask. It matters more than the launch.
9. Pressure to sign quickly
"The price is only valid until Friday" is a sales tactic. A confident partner is comfortable with you taking time and comparing.
10. Jargon you cannot get explained
If you ask a question and the answer is more jargon, that is a sign of how communication will go for the whole project. Good teams explain things plainly.
And what good looks like
It helps to know the opposite too. Green flags include: questions about your users before any numbers appear; a written scope with assumptions and exclusions; an offer to start small; a clear explanation of who owns what; a named person you will actually talk to; honesty about risks; and comfort with you taking your time and comparing options. A team that is happy to be compared is usually confident in its work.
What to do
Ask questions, in writing, about each concern, and notice how the answers feel. Defensive or vague responses are information. Our guide to choosing a software company has questions to ask, and writing a brief helps you compare proposals fairly.
Want a proposal that avoids all ten? Talk to us, and see how we run projects.