The Builder Playbook

This playbook is for the executive trying to solve the AI sprawl problem. Each phase names the decision you own, common pitfalls, and practical examples from Matthews that show why it matters. The Builder Framework covers the benefits of allowing subject matter experts to build using AI. The step by step for the person running the program is in the program lead’s guide.

Related

The Builder Framework

How to decide what your company controls centrally and what it lets people build for themselves, now that everyone can build software.

My team and I ran a version of this at Matthews, a commercial real estate brokerage of more than 1,000 people. I call out what we’re currently building as in flight. I mark what we’d do next time as Recommended.

Phase 0. Own the core before you open building

The decision: whether to own your system of record or keep building around a vendor that owns it. If a vendor owns the core, every app waits on the vendor’s roadmap and pricing.

Builders need a core to build on. That means one home for the records your business runs on, one sign-in, and rules for who can see which data. Control who sees which data at the data layer, with row-level security tied to each user’s sign-in. Once people can build, they control the application layer, so access rules can’t live there. Every app reaches core data through your API.

At Matthews we replaced Salesforce with software we built. It took three years to build, and the contract was cancelled in year four. We started with two product leads and four engineers. By early 2026 we had 11 engineers.

We lost most of year one to the migration. We tried to reshape Salesforce’s data as it synced to improve the experience. The sync was irregular, so the transforms threw constant errors and the two systems drifted apart. We switched to mirroring Salesforce’s structure until the last user was off, then refactored. If you’re migrating, mirror first and refactor after cutover. You’ll give up some experience and capability in the short term, but it makes migration possible. You can optimize once you’ve achieved migration.

Set one rule before anyone builds: a data concept never lives in more than one place. The executive sponsor’s mandate should commit each department to paying for the tools it owns.

Adaptation point

If replacing your system of record is years away, you can still open personal projects and a limited consumer tier against the data you can expose safely. Apps that write to core data wait until you own the write paths.

You’ll know it’s working when you control the roadmap for your core data. A new app should also sign in as the user and see only what that user is allowed to see. We handle this through Okta authentication and a PKCE API.

Phase 1. Staff support and name owners first

The decision: who supports the builders, and who owns what they build.

Settle both before the first builder starts. Otherwise nobody owns what gets built, and every hard question lands on the core team.

Start with the team that supports builders.

At Matthews I watched builders get apps to about 80 percent and then stall. Some chased the next interesting idea. Others hit a technical roadblock. An app that stops there delivers nothing to users. The PMs handle the first problem and the FDEs handle the second. We have this team at Matthews now. Next time we’d staff it first. Recommended.

Then name a portfolio owner in each department. The department assigns the owner rather than taking a volunteer. Put the role in their job description and performance review. The seat stays with the department, so name a backup. The owner decides the outcomes, the milestones, and what gets built next.

Records and apps are placed differently. A record belongs to the department that owns the data. An app belongs to the portfolio most invested in the function it performs, even when it uses another department’s records. At Matthews legal owns contract records, but our vendor management app sits with operations, because optimizing vendor spend is their job. This keeps departments from building the same thing and fighting over who owns it.

You’ll know it’s working when every portfolio owner can say what they’re accountable for. The nomadic team should also handle a builder’s integration without pulling in the core team.

Phase 2. Make the sanctioned path the easiest one

The decision: how much of the shared foundation to build before you open the program.

People route around a sanctioned path that’s harder than building alone. The rails are what every app gets for free. A template starts each app with the company’s components and one shared top bar. Skills teach builders’ AI agents your brand, security, and data rules.

At Matthews the internal app store and the dock are live. The dock is where people pin the apps they use most. We’re still building one sign-in across every app, a shared notification center, and an AI assistant.

Two rules belong in the rails from the start. Builders never set up their own environments. The nomadic team provisions them. Write access to core data is off by default.

Put one question on the registration form: would this app replace something you pay for? At Matthews the answers feed our running total of displaced vendor spend. Vendor displacement is a signal, but it isn’t the biggest outcome. Most value will likely come from growing throughput without growing headcount.

You’ll know it’s working when a registered app goes live without a ticket outside the program. A change to the template should also reach every app that uses it.

Phase 3. Find the people already building

The decision: who builds first, and how you bring in the people already building on their own.

Your first builders are department experts with real operational needs and no product experience. Start with departments whose owners are ready to review work and whose tools touch the least sensitive data. Regulated functions may need their skills written first.

Some of your people are already building without you. Announce the program before registration opens and ask them to come forward. At Matthews we announced while the store and workspaces were still being built. Early work landed in the right portfolio with support behind it. Then have the nomadic team and security take an inventory of the AI-built tools already in use and give each one a portfolio. Recommended.

Apps are moving into our native environments now, and migration has been relatively easy. The original code base goes into the environment as context the agent can rebuild from. Most apps migrate within a handful of prompts.

Not every app is worth supporting. Every app you bring in needs an executive sponsor. Any app without a prioritized business purpose will add bulk without adding value. At Matthews more than 15 builder apps are creating real value today. The expectation for Q1 2027 is about 30 builders running roughly 50 apps across 8 portfolios.

You’ll know it’s working when the people already building come forward before registration opens. Each first builder should also have a portfolio owner ready to review their work.

Phase 4. Builders register ideas before code is written

The decision: what an app has to pass before users see it.

Builders ship too much too soon and duplicate existing data when there’s no single path to production. At Matthews every app moves through four stages.

Stage	What has to be true to move on
Idea	The idea is registered, the nomadic team agrees it should be an app, and the first outcome is defined
Alpha	The app has its own environment, and its agent has checked for data that already exists
Beta	A small test audience has used a minimal release
Production	The portfolio owner and audience sponsor have signed off, and the code has passed review

Registration comes before code, every time. The nomadic team can’t help anyone build the right thing if it finds out after the fact. Before building starts, the portfolio owner defines the impact the app should have and the milestones that mark progress. A builder can explore an idea that isn’t next in Claude Design, but no code gets written until it’s next in priority. At Matthews milestones are captured in Linear, where progress toward them is tracked. No app publishes without a named owner, whatever else it has passed.

Keep releases small, and hold the next feature until the current outcome is measured and achieved.

You’ll know it’s working when every live app has an owner, and no app’s data duplicates a concept that already lives somewhere else.

Phase 5. Review the program before it decays

The decision: how often the program gets reviewed, and who retires what.

Without review, a program decays. Duplicates creep in, access outlives its purpose, and apps stay live after people stop opening them. Portfolio owners review usage and overlap on a regular schedule. They retire what they don’t need, and retired apps lose access at once. The core team checks for data concepts living in two places. Security reviews write access and repeats the sweep for tools nobody registered. Recommended.

At Matthews we lock an app into an audience’s preset dock only when the role can’t work without it. An overcrowded locked dock takes choice away from users and hurts the experience.

You’ll know it’s working when each sweep finds fewer unregistered tools than the last.

Phase 6. Measure how the work changes

The decision: what counts as success.

Counting shipped apps says nothing about whether the program works. Measure the change in the work. Track each app’s key metrics. At Matthews PostHog shows activity, and builder dashboards show metrics queried from the database. Most outcomes will be about time or how well a process runs. Some are financial, like a vendor contract an app replaces, and finance validates those.

	At Matthews
Legal document creation	Nearly automated
Operations teams	The same size, while their throughput kept growing
Vendor spend displaced by builder apps, validated by finance	$750K in the first year

Adoption matters more than delivery. An app nobody opens still costs its portfolio to maintain.

You’ll know it’s working when each portfolio can show progress on the outcome it defined at the start. Finance should also have validated every financial outcome, starting with displaced vendor contracts.

Phase 7. Bring builder data into the platform

In progress

The decision: when builder data stops living only in separate apps and becomes part of the platform.

Start on hub and spoke. The core team runs a core database as the hub. Each builder app keeps data only it uses in its own database. Data moves into the core once a second app needs it. We run this way at Matthews today.

Promoting data to the core database eventually becomes a bottleneck for the core team. Builder data also sits outside the reach of your AI tools. The solution is a data fabric. Every app’s data becomes part of the platform and the context layer, which is the shared data your AI tools read before they answer or build. At Matthews we’re building a combination of federated APIs and change data capture (CDC) streamed through Kafka. Federated APIs will carry most of it. Reserve CDC for data tied to business continuity, where resiliency comes first. CDC keeps copies, so the one-place rule changes slightly. Each concept still has one schema, and every copy stays in sync with it. Your stack can differ. The goal is builder data that reaches the platform and context layer as it changes. The network-wide data check has already prevented redundancy without limiting data sharing.

	Hub and spoke	Data fabric
When to run it	From day one	Once the program is running and the payoff is clear
Where shared data lives	Promoted into the core database	One schema per concept, available across the platform and context layer
The one-place rule	In force	One schema per concept, with any copies kept in sync

You’ll know it’s working when a builder’s agent can find any existing data concept in the context layer. The promotion backlog should also stop growing.

Questions to ask your team

1. 1Who controls the roadmap for our system of record?
2. 2Who does a builder call when their app stalls?
3. 3Does every live app have a named owner?
4. 4How many apps went live last quarter before anyone registered them?
5. 5What have we stopped paying for because of something our people built, and has finance checked it?
6. 6Where does the same data live in two places?

The phases in one table

Phase	The decision	Done when
0. Own the core	Own your system of record	No vendor sits between you and your core data
1. Support and owners	Staff the nomadic team and name portfolio owners	Every portfolio has an accountable owner
2. Rails	Build the shared foundation first	An app goes live without a ticket outside the program
3. First builders	Choose the first cohort and find who’s already building	Existing builders have come forward
4. Lifecycle	Set the gates before users see an app	Every live app has an owner and no duplicate data
5. Review	Set the review cadence and who retires apps	Unregistered tools found per sweep keeps falling
6. Measure	Measure how the work changes, with finance validating savings	Each portfolio reports an outcome change
7. Data fabric · In progress	Bring builder data into the platform once the program runs	Agents find any data concept in the context layer

If you’re standing up something like this, I’d like to hear how it goes.