Proposal templates
Scope, technical approach, milestones and pricing for a build — structured around what actually gets negotiated.
A software development proposal defines what will be built, how, in what phases, and for what price and timeline — the document a client signs off on before a statement of work and contract are drafted.
What the client is trying to solve or achieve — not a restatement of the tech stack, but the business reason for the project.
High-level architecture and stack choices, written for a non-technical stakeholder to follow, with detail available on request.
Concrete, demoable checkpoints — not just 'development' as one phase — so the client can see progress and payment maps to delivered work.
Explicitly list what isn't included (e.g., ongoing hosting, third-party API costs, post-launch support beyond a set window) to prevent disputes later.
Fixed price per milestone, time-and-materials, or a hybrid — stated clearly, since this materially changes how change requests get handled.
Copy this into your own document, or build it directly as a branded page in Hanko. Bracketed text like [Client Name] is a placeholder to fill in.
Software Development Proposal — [Project Name]
Prepared for: [Client Company Name], [Contact Name]
Prepared by: [Your Company Name]
Date: [Date] | Valid until: [Date]
Objective
[1-2 sentences on the business problem this project solves — e.g., 'Replace manual order tracking with a self-serve customer portal to reduce support tickets.']
Proposed solution
[2-3 sentences describing what will be built at a high level — the core features and how they address the objective above.]
Suggested stack: [e.g., Next.js frontend, Postgres, hosted on Vercel/AWS] — open to discussion based on your existing infrastructure.
Scope of work
Included:
• [Feature/module 1]
• [Feature/module 2]
• [Feature/module 3]
• QA and bug fixes through launch
Not included: [e.g., third-party API/licensing costs, ongoing hosting after launch, content population, post-launch feature requests]
Milestones & timeline
Milestone 1 — [e.g., Technical discovery & architecture sign-off]: [X weeks], $[amount or % of total]
Milestone 2 — [e.g., Core build, demoable]: [X weeks], $[amount or %]
Milestone 3 — [e.g., Integration & QA]: [X weeks], $[amount or %]
Milestone 4 — [Launch]: [X weeks], $[amount or %]
Total estimated timeline: [X weeks/months]
Investment
Total project fee: $[amount], billed by milestone above
— or —
Time & materials: $[rate]/hour, estimated at [X] hours, invoiced [weekly/bi-weekly]
Change requests outside scope are quoted separately before work begins.
Assumptions
[e.g., 'Client will provide brand assets and API credentials within 5 business days of kickoff.' State whatever your timeline actually depends on.]
Next steps
Accept below to move to a signed statement of work and kickoff scheduling.
[Signature / Accept button] Date: [___]
Fixed price works when scope is well-defined; time-and-materials fits when requirements are still evolving. A hybrid — fixed price for a discovery/design phase, then a fixed quote for build — handles most ambiguous projects well.
Enough that each one is demoable and payment maps to real progress — typically 3-5 for a project measured in weeks to a few months. Too few and a client is paying largely on trust; too many turns into micromanagement.
A recommended stack, yes — full commitment, not necessarily. If the client has infrastructure constraints you don't know yet, frame the stack as a starting recommendation pending technical discovery.
Send it as a branded proposal in Hanko, get it signed as an SOW, and bill each milestone as it's delivered.
Product
InvoicingProposalsAgreementsClient portalsSolutionsCompareAlternativesBest ofTemplatesPricingProduct updates and the occasional tip, about once a month.