Custom Software Development Proposal Template
Fixed-price software goes wrong when the specification is thinner than the client’s imagination. This template makes the requirements document a paid, signed-off first phase, and states how a change request is handled — which is the difference between a profitable build and an endless one.
Take the whole thing
The scope, deliverables, timeline and client questions — as plain text you can paste anywhere. No signup.
The scope, as written
I'll design and build the software your business actually needs — whether that's a web app, an internal tool, an API, or a mobile-ready platform. You get a clean, scalable codebase, proper documentation, and a product your team can confidently own and extend. Scope is fixed at the specification and changes are handled through a written change process, so the budget stays predictable and neither of us is guessing what 'done' means.
What this work typically sells for
£533/day average for UK software engineering contracts
A day rate, not a project price — multiply by your estimate once the specification phase has told you how many days the build actually is. This is a UK contract average across a large platform dataset; rates in India and Brazil run materially lower, and the report itself calls its figures directional benchmarks.
What's included
- Requirements workshop + technical specification document — the definition of scope this proposal is priced against
- UI/UX wireframes + design review (2 rounds)
- Full-stack development (frontend + backend + database) in 2-week sprints with a demo at each end
- Automated tests, code review standards, and deployment to staging and production
- Source code in your own private Git repository from day one, plus setup and handover documentation
- 30-day post-launch support covering defects in delivered scope
- Excluded: hosting, domains, third-party APIs, SaaS subscriptions, app store fees, software licences and paid libraries — all in your accounts, paid by you, so you keep control of them
Worth adding for this kind of work
- Requirements and specification treated as a billable phase with its own sign-off
- A written change-request route, so new features have a price rather than an argument
- Who owns the code, the repository and the hosting after launch, stated plainly
The timeline
- Sign proposal & pay deposit
First instalment confirms the project start date and reserves my capacity; it is non-refundable. Payment details sent via WhatsApp.
- Requirements workshop
Deep-dive session (video or WhatsApp call) to define scope, tech stack, integrations and success criteria.
- Wireframes + spec delivered
UI mockups and technical specification shared for review. Your written sign-off on the spec is what starts the build — everything after it is measured against that document.
- Development sprints
Iterative build with a demo at the end of each 2-week sprint. Feedback is consolidated once per sprint; anything new goes through the change request process rather than quietly into the sprint. Updates via WhatsApp.
- UAT + your sign-off
You test against the agreed acceptance criteria and return one consolidated defect list within 5 working days. Defects are fixed at no cost; new requests are quoted.
- Launch, handover + support window
Deployment to production, full code and documentation handover, and the 30-day support window begins. Final invoice sent on WhatsApp; IP transfers on payment.
Where this proposal usually goes wrong
Fixed-priced from a one-paragraph brief.
Bill the specification phase separately. You cannot price what nobody has defined.
No change-request process.
One clause: new scope gets an estimate and approval before it is built. Without it, "small tweaks" are unpaid.
Leaving hosting and maintenance unmentioned.
Say what happens after the 30-day window. Silence is read as "supported forever, free".
Questions clients ask about this work
What happens when the scope changes mid-build?
It usually does, and that is fine — it just needs a process instead of goodwill. Anything not in the signed specification becomes a change request: I write down what it is, estimate the effort and cost, and you approve it on WhatsApp or email before I build it. Nothing is started without your yes, and nothing is billed as a surprise. What I will not do is promise to "absorb small changes where reasonable", because that phrase has no boundary and it is how fixed-price projects turn into a slow argument. Genuine clarifications of existing scope cost nothing; new behaviour is a change request.
What exactly does the 30-day post-launch support cover?
Defects — delivered functionality not behaving as the agreed specification says it should. Those I fix at no charge, prioritised by severity, with critical production issues taken same-day. It does not cover new features, enhancements, changes you decided on after launch, third-party outages, or issues caused by someone else changing the code or infrastructure. Those are quoted as change requests or covered by a monthly maintenance retainer, which most clients take up because software needs upkeep, not just delivery.
Will I own the source code, and what if we stop mid-project?
Yes. Full IP in the delivered code transfers to you on final payment, and the code lives in your own private repository from the first commit — you can watch it being written. Pre-existing generic components and open-source libraries I use come with a perpetual licence to use them in your product rather than a transfer, which is standard and does not restrict you. If we stop mid-project, you pay for completed sprints, and everything paid for is yours to take to another developer with the specification and documentation. I will not hold code hostage, and I will do a handover call.
Why are you more expensive than the quote I got elsewhere?
Sometimes I should not be. If your need is genuinely simple, an off-the-shelf tool or a no-code build will serve you better and cheaper, and I will tell you that in the workshop rather than sell you a custom build you do not need. Where a cheap quote hurts is on what it excludes: tests, code review, documentation, error handling and a handover another developer can pick up. That is 30–40% of the effort and 100% of what determines whether the thing survives its second year. Compare quotes on what happens after launch, not just on the number.
Is my data and business information safe with you?
Yes, and it is contractual, not just goodwill. Anything I see — your data, systems, credentials, roadmap and commercial information — is confidential and is not shared or reused. I use least-privilege access, request credentials through a password manager rather than WhatsApp, work on anonymised or sample data wherever the task allows, and hand back or destroy all access at the end of the engagement. I will sign your NDA if you have one. I do reserve the right to describe the type of work in my portfolio, with no client data and no confidential detail, and I will not name you without your permission.
What if an invoice goes unpaid, or the project stalls on my side?
On payment: sprints pause and deployments are held until the account is settled; production deployment and IP transfer happen on final payment. On stalling: timelines assume you return feedback, approvals, content and access within 5 working days. If a project goes quiet for more than 30 days I have to re-book my schedule, so restarting depends on availability and carries a re-mobilisation fee for reloading context. I will always warn you on WhatsApp before either applies — the point is to keep the project moving, not to catch you out.
A template gets it written. Tracking gets it signed.
You already have the document — copy it above and send it however you like. What a copy cannot tell you is whether anyone read it. Send this same template from ClosingMoment and you will know the moment your client opens it, which sections they read, and how long they spent — so you follow up while they are still deciding.