Your teams are already building... and most of what they’ve built, you’ve never seen.
Someone in finance has a Claude-built tool pulling from a production export. Someone in marketing has a Cursor project that touches customer records. Nobody isolated or reviewed any of it, and there’s no record of who shipped what. Security can’t vouch for tools it has never seen, and every week more of them go live.
Leadership is stuck in a bind. A ban stalls the business and pushes the building further out of sight. Letting everyone build freely leaves engineering holding a hundred tools it never agreed to support.
The way out is to manage the critical systems centrally. That lets the edges of the company fragment and customize as much as they need, and the sprawl stays under control. The hard part is cohesion. Dozens of apps, and eventually hundreds, built by people across the company have to feel like one product and share one set of data, while each one fits the job it was built for.
This framework is for companies starting with little or no product or engineering in house, and it covers the decisions that take them from nothing to a working builder program. If you already run product and engineering teams, most of your builders will be product managers, and I’ll cover that case in separate pieces. The examples come from Matthews, a commercial real estate brokerage, where I direct product for the app ecosystem and co-lead platform strategy.
What did it produce at Matthews?
More than 15builder apps creating real value today
$750Kvendor spend displaced in the program’s first year
$0Salesforce contract today, from $1.3M a year
More than 15 builder apps are creating real value today. Content creation that took weeks now takes minutes, and legal document creation is nearly automated. The builder program displaced $750K in vendor spend in its first year, and the operations teams stayed the same size, even absorbing natural turnover, while their throughput kept growing. The target for Q1 2027 is about 30 builders running roughly 50 apps across 8 portfolios for a company of more than 1,000 people. We’re also moving every app into our native environments.
The builder program runs on a platform we own. We started with a small team hired as a commitment to the change, made up of two product leads, including me, and four engineers. Before the Salesforce migration finished, we’d brought two existing leaders from marketing and operations onto the product team and grown to 11 engineers. Our Salesforce contract was $1.3M a year when we started building the replacement, and renewal would have been $1.9M by the time the last user moved off. Today it’s $0. New brokers used to take months to learn Salesforce. They learn ours in about a day.
Why should an executive care beyond cost?
Because AI threatens the reason people pay you.
Matthews takes a percentage of what its brokers close. Brokers accept that because closing requires things they can’t easily get alone: marketing, legal, and the data and software behind prospecting. AI is making many of those things buildable by one person. Every broker who builds their own pipeline tool has less reason to give up a percentage.
Other businesses face the same problem. An agency justifies its cut with a creative team and media buying, and a producer with a few AI tools can now cover much of that alone.
In each case the moat is expertise and proprietary data, and both matter less if people build their own tools somewhere else. We chose to make Matthews the place where building happens. A broker building on our platform starts with our data and with marketing and legal expertise already inside the tools. A broker building alone starts with a blank page.
Rented software makes the problem worse. It sets your ceiling, since you can’t adopt anything the vendor hasn’t adopted first, and it forces your data into the vendor’s shape. Everything you build in house becomes a proprietary advantage.
| Rented software | Your own platform | |
|---|---|---|
| Who sets the ceiling | The vendor | You |
| Whose shape your data takes | The vendor's | Yours |
| What the work becomes | The vendor's product | A proprietary advantage |
How do you let many people build without sprawl?
Split the company into a core and its edges.
The core is everything that has to be shared and trusted: the system of record, the data, identity, the component library, the compliance and brand rules builders' agents follow as skills, and the shell every app runs inside. The core team, the product and engineering team we hired for the change, owns it, and it changes deliberately.
The edges are the apps. Builders are the subject matter experts in your departments, and they build for the jobs they know best. That fragmentation is the point.
Sprawl starts when the edges begin redefining the core, keeping their own copies of shared data or inventing their own login and interface patterns. The model prevents that by making the core easier to build on than to work around.
Tiers route each effort by how much of the core it touches. Personal projects need no review. Consumer apps read from the core and keep their own data, so they move at the department’s pace, while contributor apps write back to core data on the core team’s timeline. Business critical schema updates are always the core team’s work.
Who owns what?
When anyone can build, ownership is the first thing to break. Teams build the same thing twice, and nobody maintains what shipped last year.
Treat the company as one product organization in which each department is a product area. Every app belongs to a department’s portfolio, and a named portfolio owner is accountable for it. That role goes into the owner’s job description and performance review. Ownership is also a hard gate: an app can’t publish until it has been assigned to a portfolio, so nothing reaches users without an owner. The department carries the long-term cost of everything in its portfolio, which gives it a reason to keep the portfolio lean.
Ownership follows the job a product does, regardless of who built the first version. When ownership is disputed, ask which department would be accountable if the product’s output were wrong or out of date. That department owns it.
Each group of users has an audience sponsor, an executive who approves investment in solving specific problem sets.
How does data stay trustworthy when anyone can create it?
Two apps each keeping their own copy of a client record will drift, and then nobody knows which one is right. We learned this the hard way. Our first plan for replacing Salesforce was to transform its data into the shape we wanted as it synced across. The sync was irregular enough that the two systems drifted apart, and learning that cost much of year one.
The rule we run on: a data concept never lives in more than one place.
Today we run on hub and spoke. Each builder app keeps data only it uses in its own database, and the moment a second app needs that data, it moves into the core, where the core team maintains it and exposes it through the API with scopes. Before a builder designs ANY schema, their AI agent checks the core and the existing builder data for concepts that already exist.
We’re moving toward federated APIs, where each app serves its own data to the others directly. Hub and spoke is where a company should start, and federation is an optimization once the program is running. The rule holds either way, because each data concept still has one owner.
How do many apps feel like one product?
Every app starts from a builder template that carries one shared shell, and the core application carries the same one. At Matthews the app store, the dock, and the apps a new user sees by role run today. The team is building three more pieces into the shell now: one sign-in and profile, a notification center, and an AI assistant.
How do you keep builders from hurting themselves or the core?
Most builders have never secured an app, so the rules arrive with the tools. Sign-in runs through your identity provider (Okta, at Matthews), and write access to core data stays off until someone grants it for a specific app. Compliance and brand rules ship as skills the builder’s agent follows.
Every change happens on an isolated branch, and the portfolio owner approves a plain-language summary before it reaches production.
At Matthews we rebranded to a system AI can generate reliably, so builders produce most on-brand work without a person in Photoshop, and our designers hand-craft the work for our highest-value deals.
Why do builders stall at 80 percent?
At Matthews it all happened at once. The second people could build apps, they were building apps, and I couldn’t keep visibility over all of it by myself. A small group of AI process engineers helped me get my arms around what was happening.
Then I saw the same thing over and over. Builders would get an app to about 80 percent and stall. Some drifted into exploring the next interesting idea. Others hit a technical roadblock they couldn’t get past.
It’s amazing how much builders can do on their own... but an app that stops at 80 percent delivers nothing to users. That pattern made it clear we needed product discipline and education going into every department from a central team, and a similar kind of help on the engineering side.
The process engineers grew into the nomadic product team. It’s a small group of product managers and forward deployed engineers (FDEs) onboarded into the core stack, who work well with stakeholders and move between projects quickly. They stay with each app until it reaches its full impact.
The PMs deal with distraction. A subject matter expert without product experience tends to go too wide too fast, so the PM narrows each release to the smallest one that moves a defined outcome, tests it with users first, and deploys it without disrupting anything people already rely on. New features wait until the current outcome is measured and achieved.
Roadblocks are where the FDEs come in. They get builders through the last stretch, taking on the complex integrations against the core that builders can’t do, and one can be assigned to a portfolio with the same access as its owner.
Both halves protect the core team. Without them, every stalled app and hard integration would land on its engineers, and the program would become the backlog it was meant to relieve.
Where do you start?
- 1Inventory the AI-built tools already running. That tells you what counts as core and what can live at the edge.
- 2Name real portfolio owners and write the role into their job descriptions.
- 3Staff the nomadic product team before you open the program, because the building starts the moment people can build.
Where does the model bend?
- If your system of record is still rented, start by owning it. The builder program at Matthews began after the replacement shipped.
- The nomadic team, the number of sponsors, and whether portfolios map to departments or business units all scale with company size.
- Regulated industries lean harder on compliance skills and may need risk leaders among the sponsors.
- Culture is the hardest part. Matthews is a commercial real estate firm, and the harder half of the work has been moving a services business into operating like a technology company.
- Scaling past this size is its own problem, and it’s the one I’m working on now. The next step I see is a personal development sandbox with no review, which only works if governance lives entirely at the API layer. None of that is live yet, and it will get its own playbook.
If you’re working to get ahead of AI sprawl at your company, I’d like to compare notes.
