METIS LABS
Ask five people on a project what "done" means and you will often get five answers. The developer means the features are built. The ops lead means the old spreadsheet is gone. The owner means the thing pays for itself. Everyone is working hard, and yet no one can say whether the project is winning or losing. That gap is where budgets quietly disappear.
So before we build anything, we agree on one number. Not a backlog, not a feature list, one measurable outcome that tells us whether the software is doing its job. We write it down, we put it in front of you every week, and we let it decide what we build next.
Why one number, not ten
It is tempting to track everything. Load times, sign-ups, error rates, hours saved, tickets closed. Measure ten things and you will always find one going up, which means you can always tell yourself the project is fine. That is comfortable and useless.
One number forces a real conversation up front. If the goal is "cut the time we spend processing orders," we have to ask what that time is today, who spends it, and what a good result would be. Sometimes that conversation reveals the software was never the answer. That is a cheap thing to learn in a meeting and an expensive thing to learn six months in.
The number also has to be yours, in your terms. Story points and sprint velocity measure how busy we are. They do not measure whether your business is better off. "We process an order in under two minutes instead of fifteen" is something you can feel. "We closed 40 story points" is not.
How we pick it
We start from the problem and what it costs you now. If a manual process eats a day a week, we put a rough figure on that day: whose time, what it is worth, what else they could be doing. That baseline is the honest starting line. Without it, any improvement later is just a story.
Then we agree on the target and the deadline in the same sentence. "Get invoice handling from three days to same-day by the end of the pilot" is a number you can hold us to. If we hit it, the project worked. If we do not, we have a real problem to talk about, not a vague feeling that things are behind.
A few rules we hold to when setting it:
- It has to be measurable with data you already trust. If you cannot see it in a report today, we agree how we will measure it before we build.
- It has to be one you would repeat to your accountant. If a number would not survive that conversation, it is the wrong number.
- It gets revisited, not gamed. If the world changes and the number stops mattering, we change it together, in the open, rather than quietly hitting a target that no longer means anything.
What it changes, week to week
Once the number is set, prioritisation gets easier and less political. Every feature request has to answer one question: does this move the number? A nice-to-have that does not is easy to park without an argument, because the argument was already had when we agreed the goal.
It also changes how we cut scope, and we always cut scope. When time gets tight, the number tells us what to protect and what to drop. We keep the parts that move it and we set aside the parts that do not, instead of shipping everything at half quality. You can see this play out in how we built Brandhub, where keeping the core outcome in view mattered more than a long feature list.
And it keeps us honest. We show you the number every week alongside a working demo, not a status report. If it is not moving, you find out early, while there is still time and budget to change course. That is the whole point of building in the open: no surprises at the end, because the one thing that matters has been on the table the whole time.
Start with the number
If you are about to commission software and no one has named the number yet, that is the first thing to fix, whether or not you build with us. Decide what success looks like in a figure you would defend out loud, and let that drive the work.
If you want help turning a fuzzy goal into a number you can measure, get in touch. We would rather spend an hour getting that right than a quarter finding out we built the wrong thing well.