OpenResearch
An open research harness for running structured, repeatable research workflows with open source software and open weights models.
OPEN THE REPO →
DISCOVERY IS A HYPOTHESIS, NOT A PHASE.
And in the new paradigm, useless.
The traditional discovery phase was the consulting industry's most expensive stall tactic. Months of interviews, documentation, and stakeholder alignment before a single line of useful output existed.
THE PROBLEM IS WITH THE ENGAGEMENT MODEL
It isn't the people. There's no shortage of smart practitioners in this industry. The problem is that the engagement model creates the wrong incentives. Long discovery phases billable by the hour reward confusion. Opaque methodology creates dependency. Variable estimates shift risk to the client. Workshops substitute for delivery.
The fundamental dynamic: when an engagement stretches across months with variable scope and a large team, neither side can afford to be honest about early problems. The client has too much invested. The firm has too much invested. The adversarial relationship doesn't begin at the pitch. It sets in around month four, whether anyone wants it to or not. It's structural, not personal.
The result is a compromise where nobody is happy and nobody says so. The engagement ends, the deliverable ships, and both sides are relieved it's over. Nobody wants this, but it is what we all got.
In case you've not noticed, we're living in the future, and in here in the future there's a better model. It's not complicated, but it requires letting go of the idea that larger engagements are safer ones.
WATERMELONS AND GRAPES
A twelve-person engagement with an eighteen-month runway and variable scope is a watermelon. One bad outcome kills the relationship. You have too much invested to absorb scope changes without conflict. The adversarial dynamic is baked in. Not because anyone has bad intentions, but because it used to be the only model that made sense. It was always a bad model, but it was the best we had.
But grapes are different than watermelons. This is where people tend to get mixed up. You see grapes and watermelons and people who have been doing this a long time see Agile. That's not what this is. Agile is taking a watermelon and cutting it up into pieces. This is de-risking the watermelon into the size of a grape, but with the upside of the watermelon. The whole thing. For a grape. So now you can fail fast, succeed fast, and preserve the relationship through rough patches. You keep the bets small, but the delivery value at the watermelon level. When implementation stops being the bottleneck, the queue fills up with things you stopped even pitching because you already knew the answer. Projects that were always worth doing but never worth the cost of doing them.
That's not a side effect. That's the point.
What we're building looks like risk management. It's really a trust model.
You don't build trust by never failing. You build it by making failure survivable.
Smaller risk profiles kill the adversarial dynamic before it starts. When the blast radius of a mistake is one small project instead of an eighteen-month engagement, honesty becomes possible again. The client can surface problems early. The practitioner can absorb course corrections without conflict. Both sides stop managing optics and start solving problems.
This wasn't possible before. AI accelerated development has compressed implementation into trivial tasks. This doesn't mean software is solved, but it does mean that the skills required for it have changed dramatically. The moat in this new paradigm is taste, judgment, and process: knowing what good looks like, describing it precisely before a line of code is written, and holding the line when the path of least resistance is mediocrity.
The firms that survive the next five years will be the ones that got paid for thinking, not for typing.
PROTOTYPE FIRST. ALWAYS.
The prototype is the fastest possible answer to the question that requirements documents can never answer: does this actually solve the problem for the person who has it? That question can only be answered by a human using a system. So we build the system first.
If the first prototype is completely wrong, that's useful information that cost half a day. The discovery phase just completed its actual job: ruling out incorrect assumptions before they compound. By the time a conventional engagement finishes discovery, the project is often done.
Code is a means to an end. What matters is the result it delivers. That distinction shapes everything: what gets built first, what gets measured, and when the engagement is actually complete.
THE THREE PREREQUISITES
Building fast and building correctly at the same time requires three things that are not easy and are not common.
01
PROBLEM DECOMPOSITION
The ability to break a complex, ambiguous problem into specific, small, testable questions that a prototype can answer. Most engagements stall because no one has correctly scoped what the system is supposed to do. Good decomposition is what makes speed possible without accumulating debt.
02
TASTE AND JUDGMENT AT SCALE
Rapid development means making dozens of design decisions per hour. Each one shapes what the system becomes. Speed is only useful if the decisions are good: the right things built in the right order with the right tradeoffs. This is the layer that cannot be automated. Better judgment early means substantially less rework later.
03
AN AI-AUGMENTED DEVELOPMENT METHODOLOGY
The methodology handles implementation. The practitioner handles architecture, judgment, and quality. Coding isn't hard. It's just slow when a human does it, and time spent in implementation is time away from decomposition and judgment, which is where the actual leverage lives. Keep humans in the decision layer.
THE MATH
A twelve-person delivery team is expensive because most of those people are handling coordination, documentation, translation, and implementation. These are the activities that an AI-augmented methodology systematizes. The expertise is concentrated in far fewer people than the headcount suggests.
One practitioner operating this way produces the output of a twelve-person team in approximately one fifth of the time at approximately one tenth of the cost. That is not a projection.
THE WORK IS PUBLIC
We publish our methods, not just our conclusions. Full repos, production-tested outputs, not whitepapers. If you want to see how we think before you talk to us, the code is the honest version.
Multi-Agent Consult
A public exploration of multi-agent consultation patterns and coordination strategies for complex knowledge work.
OPEN THE REPO →THE METHODOLOGY IS NOT THE PITCH. IT IS THE PROOF.
Every engagement that follows this model produces a working artifact before the discovery phase of a conventional engagement would be complete. The fastest way to understand what the work actually looks like is to start.