User roles and workflows
Each role brings its own screens, permissions and tests.
Engagement Models
Milestone based software development pricing and engagement models
Pay for software when it passes the checks you agreed, not when the hours run out. Agnotic Technologies writes down the scope and acceptance checks for each milestone, shows progress in weekly demos and asks you to accept each deliverable before it is invoiced.
Pay for accepted deliverablesScope agreed in writingWeekly demosCode in your accounts
Trusted by global innovators
What is milestone based software development pricing?
Milestone based software development pricing means you pay for each agreed deliverable once it passes the acceptance checks written before work starts, not for hours logged. Agnotic Technologies breaks a build into milestones, prices each one from its written scope, demos progress weekly and invoices a milestone only after you accept it.
The price follows the scope. A milestone with more user roles, integrations or compliance work costs more than one without, and the estimate is shared once that scope is written down.
Milestones are one of several ways to work with Agnotic. The table below shows the other engagement models and when each one fits better.
Step by step
How does a milestone payment work?
The same six steps repeat for every milestone, from the first release to later phases.
Write the milestone down
We agree the features, the definition of done and the acceptance checks for the milestone, and list what is out of scope.
Price it from the scope
The estimate comes from the written scope and the assumptions behind it, and you approve it before any build starts.
Build with weekly demos
You see working software every week, so a misunderstanding is caught while it is still cheap to change.
Run the acceptance checks
When the milestone is complete, the agreed checks are run with your team on the agreed environment.
Accept or list the gaps
You accept the deliverable, or list where it misses the written checks. We fix those and run the checks again.
Invoice and start the next one
The accepted milestone is invoiced and the next milestone starts from its own written scope.
Checklist
What counts as an accepted deliverable?
A milestone is accepted when it meets the checks written before work started. Opinions formed later become change requests, not reasons to hold acceptance.
We use this checklist when writing each milestone, so both sides know what acceptance will look at.
Decision table
Which engagement model fits your project?
Milestones suit work whose scope can be written down. When it cannot, another model fits better. Many clients move between rows as the product grows.
| Engagement model | Fits when | How the cost is set | What you accept |
|---|---|---|---|
| Product discovery sprint | The idea is clear but the scope, architecture and risks are not written down yet | Scoped as its own first milestone, before any build estimate | A written scope, architecture notes, risks and a milestone plan for the build |
| Fixed-scope first release | The features for a first release can be listed with a definition of done | Priced per milestone from the written scope | Each milestone, against acceptance checks written before work starts |
| Dedicated product team | The product needs many releases and the scope will change every sprint | Set by the team's shape, reviewed with you every month | Your product owner accepts each release |
| Staff extension | Your own team leads delivery and needs more engineers or a missing skill | Engineers' time, directed by your team | Your team reviews and accepts the work in its own process |
| Fractional leadership | You need senior technical or product decisions before a full-time hire | A set number of days or hours per week, scaled to your stage | Decisions and documents: architecture, hiring and vendor choices |
A fixed-scope first release often becomes a dedicated team after launch. Milestone pricing can return for any later phase whose scope is stable.
Scope drivers
What drives the cost of a milestone?
We do not publish prices. The estimate for each milestone moves with these factors.
Platforms
Web, iOS and Android each add build and test work, even with shared code.
Integrations
Every external system, such as payments, an EHR or an ERP, is one integration to build and test.
Data migration
Moving records from an old system adds mapping, cleaning and checks.
Compliance requirements
HIPAA-ready engineering, audit logging or data residency add design and test work.
Existing code
Rescuing a prototype starts with a code review that decides what stays and what is rebuilt.
Failure points
Where do milestone contracts go wrong?
Most disputes come from how a milestone was written, not from the code.
Challenge
A milestone defined by a date
Agnotic approach
Each milestone is a deliverable with checks. A date tells you when to expect it, not what you are paying for.
Challenge
Acceptance criteria nobody can test
Agnotic approach
Every check is written so a person on your team can run it and see a pass or a fail.
Challenge
No window for acceptance
Agnotic approach
The contract sets how long the acceptance review takes, so a finished milestone does not wait indefinitely.
Challenge
Changes absorbed silently
Agnotic approach
New ideas go on a change list with an estimate, and you decide whether each replaces scope or waits.
Challenge
Inputs from your side arrive late
Agnotic approach
Content, credentials and decisions the milestone depends on are listed in its scope with the date they are needed.
Challenge
Milestones that are too large
Agnotic approach
Large releases are split, so each milestone can be demoed and accepted on its own.
Who it suits
Who chooses milestone payments?
Buyers who need to know what each payment buys before they approve it.
Founders with a set budget
A first release split into milestones, each approved before the next one starts.
Enterprise teams and procurement
One approved amount per written scope, with acceptance records for every payment.
Teams rescuing a prototype
A code review as the first milestone, then fixed-scope milestones for the production release.
Regulated product teams
Acceptance checks that include security and audit requirements, with evidence kept per milestone.
Teams changing vendors
A handover review first, so the new milestones start from what really exists.
Standards
Which standards do milestone checks use?
Acceptance checks for security and accessibility refer to published standards, chosen per milestone.
NIST SP 800-218OWASP ASVSWCAG 2.2
Facts and sources
What does US federal acquisition guidance say about milestone payments?
The Federal Acquisition Regulation is written for government buyers, but it sets out the same principles a commercial milestone contract relies on.
FAR 32.1002 allows performance-based payments on the basis of performance measured by objective, quantifiable methods, the accomplishment of defined events, or other quantifiable measures of results.
Source: FAR 32.1002, 48 CFR (eCFR)FAR 32.1004 says each event or criterion that triggers a payment, such as a milestone, must be identified in the contract with a description of what counts as successful performance, and that signing the contract or the passage of time are not such events.
Source: FAR 32.1004, 48 CFR (eCFR)Under FAR 46.501, acceptance constitutes acknowledgment that the supplies or services conform with the contract's quality and quantity requirements.
Source: FAR 46.501, 48 CFR (eCFR)
Frequently Asked Questions
It depends on the scope of each milestone: user roles, platforms, integrations, data migration and compliance work. We do not publish prices. We share an estimate once the scope of the first milestone is written down, and you approve it before work starts.
You list where the deliverable misses the written checks. We fix those gaps and run the checks again with your team. The milestone is invoiced once it is accepted.
Yes. New ideas go on a change list. We estimate each one, and you decide whether it replaces something in the milestone or moves to a later one, so the milestone you approved stays intact.
It is a form of it. A fixed price covers a whole scope; milestone pricing splits that scope into deliverables that are accepted and paid one at a time, so neither side carries the whole risk until the end.
Yes. A fixed-scope first release often becomes a dedicated team after launch, when the roadmap changes every sprint. Later phases with a stable scope can go back to milestones.
You do. The code, infrastructure and documentation live in your repositories and cloud accounts throughout, so accepted work stays with you whatever happens next.