Self-test · July 2026
I Ran My Own Sprint for 21 Days and Missed One of Four Goals
I build a product meant to get developers to finish their projects. In July I went through it myself, as a participant, for 21 days. I missed one of four goal criteria.
What those 21 days were spent on: I was building betapair.dev— a curated circle where developers test each other's unfinished products. One delivers structured feedback, the other returns it. Not a platform and not a marketplace: I did the matching by hand. That is why the goal criteria further down talk about a landing page, about candidates, and about reciprocal feedback exchanges.
The obvious move is not to write about the miss. An accountability product whose founder falls short of their own goal is not a good sales story. But the miss is the part that demonstrates something — and the success report would have been the part that demonstrates nothing.
What has to be said first
This was a self-test, not a customer outcome. I was operator and participant at the same time. Nobody paid for it. There is no testimonial, and as of today no paying customer has completed a full sprint.
Reading this as proof that the product works overstates it. What it does establish is narrower and still not nothing: that the mechanism runs end to end under real use rather than merely passing in a staging environment — and that running it surfaces things about itself that no test had found.
The goal was fixed before day one
In MVP Builder the sprint goal is written during the intro call and stored at acceptance. After that it can only be corrected downward, never upward. Every milestone review measures against that stored wording — not against a later summary of it, and not against whatever has since become convenient.
My sprint had a goal with four checkable criteria. On Day 21 I assessed each one separately against the stored wording:
① Public landing page with intake in both directions, in two languages — met.
② At least 15 candidates contacted, with an internal scoring sheet — met, 16.
③ At least 3 completed reciprocal feedback exchanges, each within 48 hours — missed: 2 of 3.
④ Willingness-to-pay question asked for real — met, with a disclosed limitation.
Two clearly met, one met with a caveat, one missed.
Why the third exchange never happened
Two exchanges completed fully: in both cases I went first — delivered before receiving — and in both cases the return came back without me chasing it. Once the same day, once three days later.
The third contact did not respond to the initial approach, and did not respond to a follow-up either. That closed it under my own rule: one follow-up per contact, then never again. A second nudge might have saved the criterion and would have broken the rule.
I kept the rule and missed the criterion. That is a description, not an excuse: the miss follows from a rule deliberately honoured, and it is still a miss. That is exactly how it appears in the proof I submitted — not as "substantially met."
Which is the only reason this piece exists. A frozen goal is worth precisely what it costs to miss it. Had I rounded two of three up to a checkmark, I would have proved that the enforcement is decoration.
The fourth criterion was the more uncomfortable one
Criterion ④ required the willingness-to-pay question to be asked for real — explicitly accepting "a paying yes or a documented honest no" as a result.
What came out was a no by null signal: the question was never put to a person, because nobody ever appeared to whom my own rules allowed it to be put. The option sat passively in the intake form from Day 16 onward. Response: zero enquiries.
By the wording of the goal, that is a pass. Honestly assessed, it is weaker evidence than an offer made and declined. Willingness to pay is therefore neither established nor refuted — it was not tested. That is what the proof says, instead of recording a clean checkmark.
What using it found that testing did not
The unexpected return was not in the sprint result but in the product itself. As a participant inside your own system you see things an operator never sees:
- Three faults in the system that generates and sends the daily prompts. They surfaced at the end of a sprint — a place nobody had simply ever reached before.
- A data-protection defect that had been live for about three and a half months. Found on the first real form run by an outsider, not by an audit.
- A qualification requirement only the wrong people got to see. It appeared at exactly one point in the funnel — visible only to those who had already disqualified themselves in the quiz. Anyone who needed to read it never passed it.
That last one is the one I keep coming back to. A filter that only reaches people who have already identified themselves is not filtering. While you are building it, though, it feels exactly like one that does.
None of the three would have been caught by a test. All three came from use, and from someone else's eyes.
What I take from it
The most useful finding has nothing to do with the goal: both exchanges that happened came inbound, from a single public post, and both through going first. Cold outreach to more than a dozen candidates stayed essentially silent.
Going first converts existing interest. It does not create any. That is a less comfortable result than "more outreach would have helped," and it is what the data says.
Where this actually stands
One completed sprint, run by the founder. No paying customer who has completed one. No testimonial. Willingness to pay untested.
That is the honest position in August 2026. The public log carries all 21 days individually, each with the finding of that day — including the days where the finding was that waiting looks like work.
If you have a project that has been sitting at 80% for months: five clicks tell you which module would fit. Then a free intro call — one that ends in a decision, even when that decision is a no with a reason.
Which module fits me? →Frequently Asked Questions
Did the founder of MVP Builder complete a sprint?
Yes. Between 5 and 25 July 2026 the founder ran the full 21-day Silver sprint as a participant inside the live product, working on a separate product of their own (betapair.dev, a curated circle where developers test each other's unfinished products). The sprint closed on 26 July 2026 with the final proof submitted and reviewed against the goal frozen at acceptance. This is a self-test, not a customer outcome. As of August 2026 no paying customer has completed a full sprint and there is no testimonial.
What does a self-test prove and what does it not prove?
It proves the mechanism runs end to end under real use: daily prompts generated from actual check-in history, milestone enforcement at Day 13 and Day 21, a deadline that suspends the sprint when proof is missing, and a human review of the final submission. It does not prove that the product is worth paying for, that it works for someone who is not its author, or that anyone would recommend it. Those require a customer, and there is not one yet.
Why publish a missed goal instead of a success story?
Because the missed goal is the more informative result. A sprint goal that is frozen at acceptance and cannot be revised upward afterwards is only meaningful if a shortfall is actually recorded as a shortfall. Reporting three of four criteria as "substantially met" would have quietly demonstrated that the enforcement is decorative. The miss is the evidence that it is not.
What was the goal that was missed?
The sprint goal required at least three completed reciprocal feedback exchanges between developers within 48 hours each. Two were completed. The third contact went silent after a single follow-up, and an internal rule permits only one follow-up per contact and no further attempts. The miss was therefore the direct result of a rule the sprint refused to break, which does not make it less of a miss.
What defects did the self-test find in MVP Builder itself?
Three faults in the system that generates and sends the daily prompts, a data-protection defect that had been live for roughly three and a half months, and a qualification requirement that was only ever displayed to visitors who had already disqualified themselves. None of these were found by automated tests. All were found by using the product as a participant rather than maintaining it as an owner.
Why does a sprint goal get frozen at acceptance?
Because a goal that can be edited during the sprint stops being a commitment and becomes a description of whatever happened. In MVP Builder the goal is written down during the intro call, stored at acceptance, and can afterwards only be corrected downward, never upward. Every milestone review is measured against that stored wording rather than against a later summary of it.
What is MVP Builder?
MVP Builder is a guided sprint over 13, 21 or 30 days for developers with full-time jobs who keep almost finishing their side projects. Every evening a prompt for the next day is generated from the project context and the previous check-in, and at each milestone a human reads what was actually delivered before the sprint continues. Entry point is a five-question click quiz at mvpbuilder.io/go followed by a free 30-minute intro call.
Sources
- Public build log, Sprint #2, Days 1–21 (July 2026) — github.com/energetekk/30-Tage-Finish-Sprint-Oeffentlicher-Log
- The product built during the sprint — betapair.dev
- Sprint completed 26 July 2026; Silver module, 21 days, started 5 July 2026.