Proposal translation · EGP² briefing
How to read a software development proposal like a CTO
A software development proposal is a sales document that dresses like an engineering document. It is written to be signed, not understood — and the gap between those two things is where budgets, timelines, and working relationships go to die.
You don't need to become technical to close that gap. You need to know which five sections carry the real risk, and what a qualified answer looks like when you push on them.
1. The scope section — look for the verbs
Scopes fail on verbs, not nouns. "Build a customer portal" tells you almost nothing. Does build include design revisions? Data migration from your current system? Training your staff? A proposal that lists deliverables without defining the verbs around them is a proposal where every disagreement later becomes a change order.
Ask: "For each deliverable, what specifically is excluded?" A confident firm has an answer ready. A firm that says "we'll figure that out together" is telling you the scope isn't done.
2. The assumptions section — this is the real contract
Buried near the back, the assumptions section quietly transfers risk to you. "Client will provide timely feedback" can mean 48-hour turnarounds your operations team never agreed to. "Assumes existing systems expose standard APIs" can mean a six-week detour when it turns out they don't.
Every assumption is a sentence that starts with "the price changes if…" Read it that way.
Ask: "Which of these assumptions have you verified against our actual environment, and which are hopes?"
3. The timeline — find the dependency on you
Vendor timelines are usually honest about their work and silent about yours. Content, approvals, test users, security reviews, data cleanup — the schedule assumes you deliver these instantly. When you don't, the delay is contractually your fault.
Ask: "Walk me through every point in this timeline where your team is waiting on mine, and what happens to the schedule and the invoice when we're a week late."
4. The team — who is actually doing the work
The people in the pitch meeting are rarely the people writing the code. That's normal — but you should know the actual staffing model: named roles, seniority mix, on-shore or off-shore, and how much of your budget is a subcontractor you've never met.
Ask: "Who is the most senior engineer that will touch this weekly, and can I meet them before signing?"
5. The exit — what you own if it ends
The most expensive clause is the one that isn't there. If the engagement ends — well or badly — do you own the source code? The cloud accounts? The design files? Is the documentation good enough for another firm to pick up? Proposals that are vague here are creating switching costs on purpose.
Ask: "If we part ways at month six, describe exactly what we walk away with and what a new firm would need to continue."
What both sides actually need
Here's what surprises most executives: pushing on these five sections helps the vendor too. In a recent EGP² engagement, a CEO and COO brought us a proposal from a software firm they liked but couldn't fully evaluate. Translating it revealed not just what the executives needed to ask — but what the proposing firm needed from them to actually succeed: cleaner data, a named decision-maker, and realistic feedback windows.
The project went forward on clearer terms, for both sides. That's the goal. A proposal you fully understand isn't a weapon against your vendor — it's the foundation of a relationship that survives contact with reality.
Have a proposal on your desk right now? That's our specialty. Bring it to the Submission Portal or run the Decision Planner to see what a translation engagement looks like.