Four weeks to something running.
Not four weeks to a prototype, and not four weeks to a demo environment. Four weeks to your team using it on live jobs, with your real data in it.
How the four weeks run.
Every build follows this. The content changes; the shape does not.
-
Week 1
Map the bottleneck
We follow the work through your business and find where it stops. Who is holding it in their head. What breaks when that person is out. You keep the map whether or not we build anything.
A written map of the process, and one named bottleneck
-
Weeks 2–3
Build the core
The one thing that unblocks the most, built first. Working software running on your real data, reviewed with you twice a week. No demo environments and no mock data.
The core system, in your data, in review
-
Week 4
In production
Your team runs it on live jobs. We sit with them and fix what reality finds. Training is doing the actual work with us in the room, not a video library nobody opens.
Live, on real jobs, with your team on it
-
Ongoing
Extend
The next build attaches to the same record. You decide the order and the pace, based on what is hurting now rather than what was on a roadmap in March.
The next build, when you say so
Four rules we hold ourselves to.
-
Your data from day one
No demo environment, no mock records. If it cannot survive your real job names and your real edge cases, it is not built yet.
-
Twice-weekly review, not a reveal
You see it while it is ugly. A build that surprises you in week four was being built wrong in week two.
-
Training is doing the work
We sit with your team while they run live jobs through it. Not a video library that nobody opens after the first week.
-
We say no out loud
If week one finds that the problem is not software, we tell you and you keep the map. That answer is cheaper than the alternative.
The questions we get asked.
- Why four weeks and not four months?
- Because a build that takes four months is answering questions nobody asked yet. We build the one thing that unblocks the most, put it in front of your crew, and let reality decide what comes second.
- What do you need from us?
- Roughly two hours in week one to walk the process, then about thirty minutes twice a week for review. In week four we need your team actually using it on live jobs. That is the whole ask.
- What if week one says the bottleneck is not software?
- Then we say so and you keep the map. It happens. A hiring problem or a pricing problem does not get better with a dashboard on top of it.
- Who owns the code?
- You do, along with the data. It is an asset on your side of the table, not a seat you rent.
- What happens after week four?
- The system runs. When the next bottleneck shows up, the next build attaches to the same record. You decide the order and the pace.
3 of 4 build slots taken this quarter. 1 open.
Four builds per quarter.
Real engineering takes real hours. We cap the book so every build gets the team it needs, and so the fourth client of the quarter gets the same attention as the first. When the slots are gone, they are gone until next quarter.