What exactly is a Delivery Brick, and why not just measure in hours or lines of code?

A Delivery Brick is an atomic, objectively countable unit of engineering work — one CRUD operation, one API endpoint, one UI component, and so on, across 12 defined categories. It is never a unit of time or AI compute. Hours and AI-call volume both create a Goodhart's Law problem: if either becomes the basis for pricing, there's a direct incentive to inflate it. Counting objective engineering artifacts removes that incentive — the Brick count doesn't change based on how long something took or how many AI calls it required to produce.

If Brick price differs by category, how is a Delivery Unit's final price actually calculated?

A Delivery Unit's price is the sum of its component Bricks' prices across all applicable categories. Each of the 12 categories has its own Base Unit Rate, calibrated separately, because a Brick in the AI/CV/ML category and one in the CRUD/Data category require different expertise and different levels of verification — pricing them identically would either undervalue rarer expertise or overprice routine work. A Unit combining, say, 8 CRUD Bricks and 3 AI/CV Bricks is priced as (8 × CRUD rate) + (3 × AI/CV rate), not as 11 Bricks at a single blended rate.

How does VDD handle a Customer changing requirements mid-project?

Through Re-Bricking, any requirement change is recorded as an update to the project's Brick list. When the list lives in Git, it appears as a diff to the project's vdd-spec.yaml file and is reviewed like any other code change. Before anyone approves it, both sides see the delta: the change in Bricks and Units, the recalculated P50/P85 dates, and the shift in Independent Verification Effort. A change request becomes a visible number that both sides see at the same time, not a separate negotiation.

Why does VDD give a date range instead of a single delivery date?

Because a single date is a point estimate for what is really a probability distribution, it is almost guaranteed to be wrong in one direction or the other. VDD records the team's weekly Brick throughput. P50 divides the remaining Bricks by the median weekly throughput; P85 divides them by the throughput the team reaches or exceeds in 85% of weeks, leaving margin for sick days, underestimated Bricks, and the blockers that reliably occur on real projects. Both dates are shown together, for example, “P50: March 3, P85: March 17”.

What is the Customer Risk Multiplier, and does it affect the P50 date too?

It's an explicit, documented multiplier applied only to the P85 (guaranteed) date, derived from tracked historical metrics for that specific Customer - how often requirements changed after sign-off, how far actual delivery deviated from the promised P85 on past projects, and how quickly the Customer responded to requests. For a new Customer with no history, the multiplier is 1.0 (no adjustment). It's introduced only starting with a second project with the same Customer and is never estimated on a gut feeling during negotiation. It is never applied to P50 — P50 remains a statistically honest measure of team throughput, uninfluenced by which Customer is asking.

How is the price of a single Brick actually determined, is it based on an engineer's hourly rate?

No. The Base Unit Rate per category is calculated as: total historical revenue from completed, independently verified Units in that category, divided by the total Weighted Bricks delivered in that category over the same period. It answers "what the market actually pays this organization for this type of verified result," not "what an hour of a specific person's time costs." The same Brick, closed by one engineer in 3 hours and by another in 8 hours, is priced identically because the verified result and the guarantee behind it are identical. Pricing by individual speed would mean the same outcome costs the Customer differently depending on who did the work, which directly contradicts the Manifesto: the Customer pays for the result, not the method used to reach it.

What happens to open-ended research work like evaluating which computer-vision approach to use or which AI models, datasets fit best for particular project? Did that can't be decomposed into Bricks upfront?

That work goes through a Research Spike instead of Brick estimation: a fixed, time-boxed allocation, the same mechanism Scrum already uses for exactly this situation. Pretending that open research decomposes into atomic units before the research happens would be dishonest, not just imprecise — the units themselves are unknown until the spike concludes. Once a specific approach is chosen, its implementation (feature engineering, training pipeline, inference endpoint, validation) is decomposed into Bricks as usual under Category 6 and related categories; only the "what will even work" phase sits outside the Brick method.

Does VDD only apply to AI-assisted development, or does it work for traditional coding too?

The methodology is agnostic to how the code was produced. Bricks count finished, verifiable engineering artifacts: a CRUD operation, an endpoint, or a UI component, regardless of whether a human typed every character or an AI generated most of it. VDD is built to price the verification and judgment layer around that artifact, which doesn't shrink just because code generation got faster. A team using no AI tools at all can apply VDD the same way; the method doesn't reference or depend on AI usage anywhere in its counting rules.

How much historical data does an organization need before it can calibrate its own Base Unit Rate?

The Implementation Playbook sets a practical threshold: 15–20 completed projects with recorded user stories, 100+ stories in total, and matching revenue/margin data for each project. Below that threshold, calibration remains possible but must be explicitly labeled as provisional and subject to revision after the first 5–8 independently verified Units delivered per category under the new rates. This reflects the same principle the Playbook applies to complexity modifiers generally, not a one-time exception.

Why is independent verification mandatory rather than optional, and who can perform it?

Self-review has a structural blind spot: the person who built something cannot reliably see their own mistakes. The Independent Verification Gate requires that someone who did not implement the Unit review and confirm it after a fresh read before it counts as delivered — this applies whether the implementation came from a human engineer or an AI agent. A result from a single source, human or AI, is never considered final until an independent party confirms it. This is a direct descendant of Wideband Delphi's requirement for independent consensus rather than a single expert's unchecked judgment, now applied to today's human+AI pairing instead of a panel of human experts.

How does the Independent Verification Gate work in practice?

The Specification allows two models. In peer verification, engineers on the same team review each other's code on a fixed schedule, and a QA engineer performs final acceptance against the test cases. In dedicated verification, a Verification Engineer who writes no feature code reviews every Unit using code-analysis tools, and a QA engineer performs final acceptance. In both models, no one confirms work they implemented or changed. See Specification, Section 5.5.

Does VDD replace Scrum or an agentic delivery framework?

No. Those frameworks organize the team: roles, cadence, and ceremonies. VDD defines the unit of delivery, its price, acceptance criteria, and forecast. You can apply VDD within Scrum, Kanban, or an agentic SDLC; the counting and verification rules remain the same. VDD vs agentic delivery frameworks →

How is VDD different from Function Points?

Function Points measure functional size from the user's perspective, and VDD builds on that lineage. VDD counts engineering artifacts, including the test cases that verify them, prices each category based on the organization's delivery history, and requires independent verification before a Unit is counted as delivered. VDD vs Function Points →

Can I use VDD commercially?

Yes, within your organization, you may use and deliver software to your own Customers free of charge and without registration. Selling VDD itself (training, consulting, audits, certification, tools, or translations) requires a written agreement with Sofycod. See the Licensing & IP Policy.

Can I translate VDD?

For internal use only, yes. Publishing a translation needs Sofycod's prior written consent and the For internal use only, yes. Publishing a translation requires Sofycod's prior written consent and the credit line from the license. We want VDD available in many languages, so write to us.credit line from the license. We want VDD available in many languages, so write to us.