What a written software proposal has to contain
A proposal is the baseline. Later change is measured against it. If a sponsor and the delivery lead cannot both read it, the document is not finished. IncogX uses the same test on its own proposals.
Seven parts belong on the page. A deck that skips them is a conversation, not an agreement.
- The outcome. One or two sentences on what will be true when the work is done. A list of technologies is not an outcome.
- Who it is for. The sponsor who can accept the plan, and the people who will use the system. If those are different people, the proposal says so.
- The boundary. What is in this engagement, and what is out. Out of scope is a kindness. It stops a later argument about a feature nobody priced.
- The first increment. The smallest piece a sponsor can see and judge. IncogX builds in two-week sprints. The proposal names what the first review will show.
- The commercial model. Fixed price, time and material, a dedicated team, a retainer, or an MVP package. The model follows how certain the scope is. A fixed price on an undiscovered problem is a guess.
- The risks already known. A date that depends on a third party, a rule that is not written yet, a system nobody has credentials for. Known risks go in the proposal. Surprises that were already visible are a failure of the document.
- After launch. Who operates the system, how long warranty fixes run, and what a later change will cost to discuss. Handover is part of the work, not a favour after it.
Discovery can be free. An NDA comes before project material. A serious note to info@incogx.in gets a reply within 24 hours. The proposal that follows should still contain these seven parts, in language a sponsor can audit.