VDD is out: price software by what is verified, not by hours

A few days ago we launched vdd-methodology.org, where I published Verification-Driven Delivery (VDD): an open methodology for estimating, pricing, verifying, and forecasting software delivery in the AI era. The Specification, the Implementation Playbook, spreadsheet templates, and a training presentation are free to download at vdd-methodology.org.

In my previous two articles, I described the problem: hourly billing, Story Points, and fixed bids all break once AI writes most of the code. I promised that a working answer was being built. This is that answer, and this article shows how it works on one real-size example.

This version 1.0 of the VDD methodology is like any first version: some parts may be imprecise or not yet described in enough detail, and I will start work on the next version soon, with a defined plan for additions. Comments, objections, and examples from your own delivery are welcome: they decide what changes next.

The usual answer is more process. What is missing is a unit: something you can count, price, and accept, built for what verification actually costs once generation is nearly free.

VDD replaces billed hours and relative story sizes with a countable unit of verified work. From one set of numbers, it answers four questions about any user story, feature, or product:

1. What will be built: a set of Delivery Bricks.

2. What it will cost: Bricks multiplied by a Price per Brick calibrated on your own delivery history.

3. When it will be delivered: a P50 and P85 range, recalculated from actual throughput.

4. How it will be accepted: through the Independent Verification Gate.

Five terms carry the whole method:

VDD does not replace your team's process. Keep Scrum, Kanban, or an agentic workflow: VDD changes the unit of price, acceptance, and forecast, not the ceremonies.

The story "A customer can register on the portal" is one Delivery Unit of 23 Bricks, priced at $1,219. Here is how that number is built.

Three things in this table matter more than the total:

• Every line is something you can point to in the finished product. Nothing is guessed, and two people counting by the same rules get the same number.

• 10 of the 23 Bricks are for verification. Plan and price verification from the start, not squeeze it in at the end.

• Each category has its own rate. A Brick of AI or computer-vision work and a Brick of CRUD require different expertise and verification, so they aren't priced the same.

The rates here are illustrative and are drawn from the worked example in the Implementation Playbook. Each organization calibrates its own rates based on its delivery history.

With VDD, a change request is a number, not a negotiation. Only the changed part is recounted using the same rules and rates. This is called Re-Bricking.

Suppose the Customer asks to add Google sign-in to the registration story:

The P50 and P85 dates are recalculated with the four new Bricks. The Customer sees the new price and dates before approving the change, and nothing starts before approval. The record keeps the original count and every change, so you can audit any earlier state.

A Delivery Unit counts as delivered only after it passes the Independent Verification Gate: someone who did not build it checks it against its acceptance criteria and confirms it. This applies equally to code written by people and to code generated by AI. An author can't see their own blind spots, so the Gate is mandatory and never skipped for schedule reasons.

In practice, VDD allows two verification models:

Cross-review is a familiar practice, close in spirit to pair programming. The dedicated Verification Engineer is not, and that difference matters more than it looks. Few teams have this as a dedicated role today, but as AI multiplies the volume of code, checking it can no longer be squeezed in between other tasks. A Verification Engineer independently checks someone's actual job, using code-analysis tools and the acceptance criteria, rather than as a line in a process document.

The need for the role can even be calculated. In the team from [the first issue of Production Proves](ссылка на первый выпуск), six engineers ship 62 features a month, with AI spending about 372 of their 1,000 hours on verification and 124 on code review. That's about one full-time Verification Engineer for every six engineers, plus QA for the test cases.

One rule holds in both models: no one performs the final acceptance of work they implemented or changed. Rework after a rejected check is recorded separately and feeds the measured verification effort of each category.

The difference between hours and Story Points is not the size of the number but what it represents:

Detailed comparisons with Story Points, Time & Materials, Function Points, and agentic delivery frameworks are at https://vdd-methodology.org/vdd-compare.

In delivery, VDD runs as a pipeline of four stages:

1. Preparation: requirements become a PRD and user stories with acceptance criteria.

2. Cost and delivery plan: every story is decomposed into Bricks, priced, scheduled, and given its test cases.

3. Execution and control: throughput is tracked every sprint, and every change goes through Re-Bricking.

4. Verification and acceptance: every story passes the Independent Verification Gate before it reaches the Customer.

Everything needed to apply VDD by hand is available now, free:

The license is simple. VDD is free to use inside your organization for any business purpose, including pricing and delivering software for your own clients: no fees, no royalties, no registration. You can adapt Brick categories, rates, and templates to your own data. You need a written agreement only if you earn money from VDD itself, such as training, consulting, audits, or certification for others. The full terms are on the license page.

The first step takes an hour and costs nothing:

1. Download the documents at vdd-methodology.org/download.

2. Run the readiness check from the Playbook. It scores your data and your habits and tells you whether to start now, close one gap first, or wait.

3. Count one delivered story. Take a user story your team has already shipped, count its Bricks using the 12-category rules, and divide its cost by the count. That is your real price per Brick today.

If you buy software rather than build it, step 3 works too: ask your vendor to count a delivered story in Bricks, and compare their price per Brick with what you paid.