How do milestone payments work for software development?

What is a milestone-based payment schedule?

A milestone-based payment schedule divides the total project cost into a series of smaller payments. Each payment is due only when a specific, pre-defined part of the project is complete. This approach is different from paying by the hour, which can be unpredictable, or paying the full amount upfront, which carries significant risk for you. It ensures that your investment is always tied to tangible results.

A milestone is a clear achievement in the project, not just a date on the calendar. It could be the completion of the design phase, the delivery of a key feature, or a successful test. On our projects, we typically plan to demo running software to you every 2 to 3 weeks. These demos often serve as checkpoints that lead to a milestone, allowing you to see and approve the progress yourself.

The most important part of the process is acceptance. We typically plan for payment to be milestone based, with every milestone tied to you accepting the work. An invoice only becomes due after you have reviewed the deliverable for that stage and confirmed that it meets the agreed requirements. This puts you in control, as payment follows your approval, not the other way around.

Before the project begins, we agree on the timeline and deliverables for each stage. The agreed dates become the milestones your payments are tied to. This creates a clear roadmap for the entire project, so you always know what to expect, what you are paying for, and when it will be delivered.

How does this protect your budget and timeline?

The main purpose of milestone payments is to remove uncertainty from a software project. By linking payments to approved work, you ensure the project stays on track and within budget. This structure prevents a common problem where a project's costs grow without clear progress being made.

The foundation of a predictable project is a detailed plan. We typically plan for you to approve the written scope before we start building. The scope is signed off, and we do not let it drift without your sign-off. This document acts as the rulebook for the project, defining exactly what will be delivered for the agreed price.

Once you approve the written scope, the project figure is fixed. This means you have a firm, predictable cost for the entire build, not an estimate that can change. There are no surprise invoices or charges for work that was not part of the agreed plan.

The written plan is what protects your budget and keeps the scope from drifting. It turns the project from an open-ended expense into a defined investment with clear deliverables. If you are considering a project, you can book a free discovery call and we will explain how we would define the scope for your needs.

What documents define the milestones?

Clear milestones depend on clear documentation written before any code. We use three key documents to define the project, and we agree on them with you before the build begins. Our requirements engineering and business analysis work ensures these documents are thorough and accurate.

The first document is the Business Requirements Document, or BRD. A Business Requirements Document captures what the business needs and why. It focuses on the goals of the project from your perspective, ensuring the final software solves the right problem.

Next is the Software Requirements Specification, or SRS. Our software requirements specification sets out the functional and non-functional requirements, aligned with ISO/IEC/IEEE 29148. This document translates your business needs into a detailed, testable list of what the software must do.

The third document is the Software Design Document, or SDD. A Software Design Document describes how the software will be built to meet the requirements. It outlines the technical architecture and approach our engineers will take.

These documents are part of every project we take on and are not sold separately. The BRD, SRS and SDD are agreed with you before engineering begins, not created for our own use. This planning stage is what makes a fixed price and a milestone payment schedule possible.

How do you know the work is being done correctly?

Milestone payments work best when you have full visibility into the project's progress. Instead of waiting for a single reveal at the end, you see the system as it comes to life and can provide feedback along the way. This ensures the final product is what you actually need.

You see running software as it is built, not a single reveal at the end. We typically plan to demo running software to you every 2 to 3 weeks during the build. This regular cycle allows you to steer the project and catch any misunderstandings early, when fixing them is simple.

Before the final handover, your own team gets to test the system. User acceptance testing is run by the people who will use the system every day, against the approved scope. They are the best judges of whether the software works as intended in a real-world setting.

Security is built in from the start, not added as an afterthought. Penetration testing runs before launch at a depth that matches the risk of the system. For projects that use artificial intelligence, we typically plan for an AI security assessment to run before launch whenever the system uses AI.

How long will it take to go live?

We typically plan a build at 6 to 12 weeks from kickoff to live. This timeline allows for proper scoping, design, development, testing, and deployment. The exact duration depends on the specific needs of your project.

Factors that influence the timeline include the number of integrations with your existing systems, the amount of data that needs to be moved from old spreadsheets or software, and whether the system needs to work offline for teams in the field. We identify these factors early on.

Our commitment to you does not end at launch. After the system goes live, we stay on it to provide support and address any issues that come up during the first weeks of real use. We plan for hypercare to run for two months after go-live.

What happens after the project is paid for?

Once the final milestone is paid, you have complete ownership of the system. At handover you own the source code, the data, the documentation and every credential. There is no lock-in, so you can bring in another team later to maintain or extend the software if you choose.

Our estimating model shows that a system we build carries no per-user licence fee. After the initial hypercare period, you pay cloud hosting directly at cost, as our estimating model describes. This transparent model avoids the recurring fees that often come with off-the-shelf software.

If you need changes or new features after the system is live, these are paid for as small projects with their own clear scope and price, according to our estimating model. A monthly support and maintenance plan is optional, and you can decline it, as our estimating model allows, giving you flexibility in how you manage the system long-term.

Key takeaways

• Milestone payments tie what you pay directly to work you have formally approved.
• A fixed project price is only possible with a detailed, written scope agreed upon upfront.
• Regular demonstrations of working software are the best way to track real progress.
• Your own team should run user acceptance testing before you sign off on the final system.
• You should own the source code, data, and all documentation at the end of the project.
• Custom-built software should not come with ongoing per-user license fees.