Before Mavrin Labs builds anything, you and the team agree four things in writing: where the work stands today, what should be different, how you will read the outcome, and the date you will look at it together. That agreement is what turns a technology project into something you can judge.
Why do projects end without a verdict?
Projects end without a verdict because nobody wrote down what success would look like while there was still time to measure it. The software ships, the invoice clears, everyone moves on, and later the honest answer to whether it paid off is that nobody knows. Nobody captured the figures that would answer it.
The cause is rarely bad faith. Somebody has to take a baseline before the build, sitting with the person who does the work and timing it. Once the new system is running, the old week has gone and no amount of analysis brings it back.
How a result is agreed
The agreement has four parts, and all four go into the scope before any build begins.
-
Baseline, step 1
The team times the work as it runs today and counts how often it runs, with the person who does it, before anything changes.
-
Target, step 2
You set what should be different, in hours back each week or in revenue, in words your own team would recognize.
-
Measure, step 3
You both agree one way of reading the outcome, simple enough that you can take the reading yourself, and who takes it.
-
Review, step 4
You fix the date you will look at the result together, written into the scope before the build begins.
What counts as a measurable result?
A measurable result is a change you could notice without a report: time a task takes each week, time from first enquiry to paid invoice, the share of orders that need a human correction, revenue from customers who come back. Each one can be read the same way before and after, which is the only property that matters.
- Hours back
- The same task, timed the same way, before the build and on the review date.
- Elapsed time
- How long work waits between the stages of a process that crosses several people.
- Error and exception rate
- How often an item needs a person to fix it before it can carry on.
- Revenue held or repeated
- Money that arrives because a follow-up or an invoice went out when it should have.
A number that nobody can take twice is not a measure. If a target cannot survive that test, Mavrin Labs says so during the first step rather than after the build.
An illustrative scenario
What follows is an illustration written for this page. It names no client and contains no figures. A firm processes supplier documents by hand and wants that week back.
- Before the build
- The team sits with the person who does the work, times the task, counts how often it runs, and writes the baseline into the scope with an agreed target and review date.
- On the review date
- The team times the same task the same way, and you read the difference together, including the part of the workflow that still needs a person.
What a result depends on
A result depends on things outside this arrangement as well as inside it. Some of your systems may limit what a workflow can reach. A supplier can change an interface. Demand, staffing and the market move for their own reasons. An estimate made before a build is an estimate, and the honest range around it is part of the agreement rather than a footnote to it.
Mavrin Labs commits to the method and the measurement, and states plainly where the outcome depends on systems it does not control.
What happens at the review?
At the review you take the measurement again and read it together, on the date agreed before the build. Mavrin Labs brings the baseline, the target and the new reading, and says what the team reads into the difference, including the parts that did not work. Nothing about the conversation depends on who remembers what.
You then agree the next step in the same written way: more of the workflow, a different workflow, or nothing further. The process page covers the five steps the build itself follows, and how engagements work covers how scope and the investment are settled around this agreement.
Frequently asked questions
Who measures the result, you or us?
Mavrin Labs measures the result, and you can repeat the reading yourself, which is why the measure has to be simple enough to describe in a sentence. The team records the baseline in the first step and takes the same reading again on the review date. If your own systems already report the number, the agreement says to use your own reading.
What if we have no data to set a baseline from?
No data is the usual starting point, so the baseline gets created from scratch. The team times the work as it actually runs, with the person who does it, and counts how often it runs in a normal week. That timing becomes the baseline, written down and agreed, and it is often the first honest view a business has had of the task.
Can the target change once the work has started?
The target can change once work has started, and the change goes in writing like the original. A build sometimes uncovers a step nobody mentioned, or the business shifts what matters most. At the end of any step you can revise the target, the measure or the review date together, and the review then judges the version you both agreed last.
What does Mavrin Labs commit to, and what stays uncertain?
Mavrin Labs commits to the method rather than to a number: a measured baseline, an agreed target, one way of reading the outcome, and a review on a fixed date whatever it shows. No honest builder promises a result in advance. Parts of any outcome sit with systems, suppliers and markets that nobody in this arrangement controls.
What happens at the review if the target was missed?
At the review you look at the same measurement together and agree the next step from what it shows. A missed target usually has a readable cause: a step still done by hand, a system that blocks part of the workflow, or a target set higher than the baseline supported. The next step is agreed then, in the same written way as the first.
How does this differ from a fixed scope of work?
A fixed scope of work describes what gets built. This agreement describes what should change in your week because of it, which is a different question and the one you actually care about. The scope still exists and still names deliverables, and the measurable result sits beside it as the test both sides apply afterwards.
Last updated
Which hours would you take back first?
Send Mavrin Labs one workflow that is costing you the most time, and the reply comes back by email from the people who would build the fix.
Start a conversation