BrickHouse / How we work
Most builds die in the handoff: the vendor invoices, the software lands, nobody uses it, and the problem is still there eighteen months later. The deal structure removes that exit.
3–7%Of attributable revenue · fixed term · agreed before we start
Course 01
One to three weeks inside the process. We watch the work happen, talk to the people doing it, and write down where things stall, double-back or get re-keyed.
You keep the map whether or not we build anything. If the map says the fix is not software, that is what it will say.
Course 02
We build the smallest thing that removes the bottleneck and put it in front of the people who will actually use it, early and unfinished.
Then we correct it until they would complain if we took it away. That is the only completion test that means anything.
Course 03
Instead of one large bill, we take an agreed 3–7% of the revenue the work produces, for a fixed number of years.
If it does not move your numbers, our number stays small. That is the point of the structure, not a side effect of it.
Not every project fits this. Some work is better as a flat fee or a retainer, and we will say so on the first call rather than force a structure that does not suit the job. What we will not do is bill you for a build and then disappear from the outcome.
The part people ask about
A revenue share is only as good as the definition of the revenue. This is where these agreements get argued, so we settle it in writing before any work starts.
Option A
The share applies to a specific product line, customer segment or service the build makes possible. Easiest to measure, easiest to agree, and the most common.
Option B
We agree a pre-build baseline — throughput, quote-to-win rate, jobs closed per week — and the share applies to revenue above it. Fairer when the build lifts existing work rather than opening new work.
Option C
Where the win is cost rather than revenue, the share applies to a documented and agreed saving instead. Same percentage, different denominator.
Option D
Some jobs do not suit a share at all — short builds, one-off migrations, work where attribution would be a fiction. Those are quoted as a fee and we say so upfront.
Questions
Then our number stays small, and that is the deal working as designed. We are taking the risk deliberately — it is what makes us honest about whether a build is worth doing at all.
The share stops. The software is yours, the source is yours, and there is no renewal clause that quietly extends it. If you want us to keep maintaining it after that, it becomes a separate arrangement.
You do, for anything built specifically for you. We keep the right to reuse general-purpose components we wrote — the plumbing, not your business logic.
Only to the measure the share is calculated on, and only in the form we agree in advance. Usually that is a monthly figure from one report, not open access to your accounts.
The map is one to three weeks. The first useful version is usually four to ten weeks after that, depending on how much of the process it touches. We would rather ship something narrow early than something broad late.
Small enough that the owner or operator can make the call, big enough that a bottleneck costs real money. If you are not sure, describe the bottleneck and we will tell you.
One conversation, no deck. Describe the bottleneck in plain language and we will tell you honestly whether it is a build, a process fix, or something you should not spend money on at all.
Start a build