Most builders get an app to about 80%... then they stop.
At Matthews more than 15 builder apps are creating real value today. The target for Q1 2027 is about 30 builders running roughly 50 apps. The apps that make it rarely make it alone. Here’s one that almost didn’t.
What does a stall look like?
Our legal team wanted to automate contract generation across the whole deal process. The builders were legal experts, and they got a working version running on their own.
Then they hit storage. Our contracts lived in Box, and the builders had no way to connect the app to it themselves. The only way to keep going was to build locally, generating and storing contracts on their own machines. That’s fine for a demo. Nobody else in the company could use it.
The second stall came right behind the first. With the real work blocked, the team drifted into smaller side explorations. The ideas were interesting, and none of them got the app any closer to launch.
I’ve watched that pattern play out over and over. First comes a technical roadblock the builder can’t solve alone. Then comes exploration that feels like progress.
Who gets them unstuck?
Each stall needed a different kind of help.
The storage problem went to our forward deployed engineers. They connected the app to Box, which the builders couldn’t do on their own, and the app could finally run somewhere the whole team could reach.
The drift went to product. First came education. I’d put together an introduction to R&D that gives everyone the same language for how work gets prioritized, and the legal builders went through it. Then we locked down outcomes and wrote the most minimal requirements we could to satisfy each one, in order of importance.
Both of those roles grew out of the same place. When building first took off at Matthews, a few AI process engineers helped me get my arms around what was happening. As the processes settled, that generic title split into product managers and FDEs, because the two stalls called for two different skill sets.
The product work produced four outcomes:
- 1A first adoptable release, with core features passing user acceptance testing run by Legal.
- 2Agent-facing contract workflows available through our core platform.
- 3All contracts managed from a single location.
- 4Legal generating new contracts across every topic as needed.
Why work the outcomes in order?
We go in order. Outcome 1 is done, and the app is live. Outcome 2 is in progress. The other two wait until it’s finished.
That effort isn’t gating value creation. It’s just the next optimization.
Builders can see all four outcomes, and the pull is to chip away at each of them. Working them in order keeps a team from drifting, because the next thing to build is always obvious.
Storage shows how this plays out. The contracts are still in Box, spread all over it. Moving them into our own storage is outcome 3, and it will make the app better. That effort isn’t gating value creation. It’s just the next optimization.
When is an app done?
We don’t treat any of them as done. Each builder app is an ongoing investment that improves over time. The contract app has one outcome shipped and the second underway, and product and engineering support stays with it until it reaches its full impact.
It’s the easiest part to skip. Hand builders the tools, walk away after the first demo, and the apps sit at 80%.
If you’re opening the door to AI builders at your company, I’d staff this support before you open it. The building starts the moment it’s possible.
