Verification-Driven Delivery
We deliver using the Verification-Driven Delivery (VDD) Methodology, which we developed and published openly. With VDD, every user story has a price agreed upon before work starts, every change request is priced before it is approved, and delivery dates are given as P50 and P85 ranges rather than a single guess.
The billable hour is dead
AI compresses development time several times over. But the value was never in writing code faster: it is in independent verification and expert judgment, and those don't speed up with generation.
The same feature can take one team 4 hours and another 8. If you pay by the hour, you pay for the slower path. If you pay by Story Points, you pay for a number nobody outside the team can check. Either way, the work that protects you, checking what was built, is the first thing cut when the budget gets tight.
So we changed what we sell. You pay for a counted list of work, priced before it starts and accepted only after someone who didn't build it has checked it.
“Selling hours in the AI era is like selling candles in the age of electricity: technically possible, but why, except perhaps for décor and nostalgia.”
Alexander Lipanov, PhD, Applied Mathematics,
CTO at SOFYCOD
Hours reward slowness
The faster AI makes a team, the less it earns. Hourly billing works against the very speed you are paying for.
Story Points can't price work
They are relative to one team and meaningless across projects. They were built for sprint planning, not for budgets.
Unverified AI code is debt
Code generated fast and checked by no one ships fast, then comes back as rework you pay for twice.
From idea to verified delivery
Our Delivery Toolkit
Four stages, one continuous pipeline, run on tools we built for VDD. Some are software, others are the spreadsheets from the VDD Playbook or predefined AI skills.
Preparation
Your idea becomes a complete PRD, user stories with acceptance criteria, an infrastructure specification and the right AI methods.
BrickScope: From idea to a full PRD, enriched with compliance and domain requirements.
StorySplit: From PRD to user stories with acceptance criteria.
InfraBlueprint: From PRD to an infrastructure specification.
ModelLens: Recommends AI, ML, or computer-vision methods and datasets for each task.
Cost & delivery plan
Every story is decomposed into Delivery Bricks across 12 categories, priced, scheduled and given its test cases.
Brick Estimator: Breaks each user story into Delivery Bricks across the 12 categories.
Brick Price Determiner: Calibrates the Base Unit Rate of each category from our delivery history.
Forecaster: P50 and P85 delivery dates from weekly Brick throughput.
TestForge: Generates test cases from acceptance criteria.
Execution & control
Stories move into your backlog, milestones are scheduled, and throughput is tracked every sprint. Every change goes through Re-Bricking.
Backlog push: Stories, Bricks and test cases into Jira
Forecaster: Dates recalculated after every sprint
Re-Bricking: Each change is recounted and priced before approval
Verification & acceptance
Code review and quality checks for security, reliability, performance, and maintainability. Then every story passes the gate.
Verification Gate: Independent sign-off by an engineer who didn't build the story
Traceability: Every check is traced to its user story and to the code that implements it
Our Delivery Process in Action
The diagram shows the same four stages as in a pipeline: requirements are captured and prepared. The VDD processing engine turns user stories into priced Bricks and test cases. The work is executed and controlled sprint by sprint, and every story is verified before it reaches you.
One way to price everything
We build every price the same way, whether it is for one feature or a whole product. A user story is broken into Delivery Bricks, countable units of engineering work; each Brick is priced by its category; and the test cases that will verify the story are counted from the start, not added at the end.
One user story, start to finish
Here is a typical story, counted and priced. Every line is something you can point to in the finished product.
In the example above illustrative rates from the VDD Implementation Playbook are used. We price customers' projects using our calibrated rates.
Changes without surprises
Requirements change. With VDD, a change is not a negotiation: we recount only what changed, and you see the new price and dates before you say yes.
A change is a number, not a negotiation
We don't recount the whole story. We count only what was added or removed, by the same rules, and price it at the same category rates.
We count the added or removed Bricks.
We price them and recalculate the P50 and P85 dates.
You approve or decline. Nothing starts before you approve.
Rework is on us. If a story fails verification, we don't bill for fixes. You pay for verified results, not for our mistakes.
How VDD fits your process
You don't have to change how your team works. Keep Scrum, Kanban or your own agentic workflow: we bring the unit of delivery, its price, its verification and its forecast.
Hours
Story Points
Delivery Bricks (VDD)
What you pay for
Time spent
Relative effort
Counted, verified work
Known before work starts
No
No
Yes, per user story
Who checks the result
Usually the same team
The same team
An engineer who didn't build it (see VDD Specification for details)
Comparable across vendors
No
No
Yes
See the full comparisons at vdd-methodology.org/compare →
What our customers ask first
What if requirements change during the project?
We recount only the changed part of the story. You see the change in Bricks, price and dates before you approve it.
What if a story fails verification? Do I pay for the rework?
No. The story goes back to our engineers, and the rework is not billed. You pay only for verified Delivery Units.
How does independent verification work in practice?
We agree on one of two models with you at the start of the project. Peer verification: team engineers review each other's code on a fixed schedule (for example, every Wednesday and Friday), and a QA engineer runs final acceptance against the test cases. Dedicated Verification Engineer: one engineer, who writes no feature code, reviews all code, runs it through code-analysis tools, and hands it to QA for acceptance. In both models, no one ever confirms their own work.
Do we have to change how our team works?
No. VDD changes how work is priced, accepted, and forecast, not your ceremonies. It works alongside Scrum, Kanban, or your own process.
How do we know your rates are fair?
Each category's rate is calibrated on revenue from our own completed, verified projects, not on hourly wages, and recalibrated at least twice a year.
Can we compare your price with another vendor's?
Yes, on work you have already paid for. Take a user story your current vendor delivered and count its Bricks: the counting rules are public at vdd-methodology.org, or we can count it for you free of charge. Divide what you paid for that story by its number of Bricks, and you get your real price per Brick. Compare it with ours. The Brick count follows public rules, so it is the same whoever counts it; only the price per Brick differs.t vdd-methodology.org.
