Your Best Engineers Should Architect Substrates, Not CRUD Apps
When non-engineers build the long tail of internal tools, scarce engineering talent moves up: design the governed substrate, set patterns, review what ships.
Your most valuable engineers should not be hand-writing the 400th form-over-database app. When non-engineers can describe what they need and get a working internal tool back, the scarce, high-value engineering work moves up the stack: designing the governed substrate everyone builds on, setting the patterns and guardrails, reviewing what lands, and integrating the systems that are genuinely hard. Engineering doesn’t shrink in this world—it relevels. The bottleneck stops being how many CRUD apps a team can ship and starts being how good the foundation underneath all of them is. That’s a better use of the best engineers you have, and it’s where org design should point engineering talent next.
A CRUD app is the most common shape of internal software—create, read, update, delete a few tables behind a form: an approval tracker, a vendor-intake form, an inventory dashboard. There are thousands of them latent in any company, and most never get built because engineering can’t get to them.
TL;DR
- When domain experts can build their own tools, the scarce engineering work moves up the stack—from hand-writing routine apps to designing the foundation everything runs on.
- A “substrate” is the shared foundation an org’s software runs on: the identity system, data layer, deployment path, and logs—the thing engineers build once so everyone else can build on top safely.
- Most engineering time today is spent on the long tail of form-over-database apps, work that is high-volume, low-differentiation, and a poor use of your most expensive talent.
- This isn’t engineers getting replaced—it’s engineers moving to higher-leverage work: architecture, integrations, patterns, and reviewing what the rest of the company ships.
- The common attempt—handing non-engineers an AI coding assistant like Cursor or Claude Code—is a layer mismatch: those tools are excellent for engineers but assume engineering skill, so they relocate the barrier instead of removing it.
- The model only works if what non-engineers build is reviewable by a human who isn’t reading code—which means the source of truth has to be a plain-language plan, not a sprawl of generated files.
- The strategic payoff is leverage: a small senior team can govern hundreds of apps it didn’t write, because it owns the substrate and reviews specs instead of clearing a ticket queue.
Where does engineering’s scarce time actually go?
Into the long tail, mostly—and that’s the problem. Pull apart a typical internal-software backlog and a large share of it is not hard engineering. It’s the approval tracker finance asked for, the onboarding checklist HR wants, the vendor-intake form procurement needs, the dashboard ops keeps rebuilding in spreadsheets. Each one is a form over a few tables with some role logic. None of it is novel. All of it competes for the same engineering hours as the work that actually moves the business.
The demand for these tools is effectively unbounded, and engineering headcount is not. So the long tail loses. The high-value requests get built; the routine ones sit in the backlog until the team that needs them gives up and wires something together in a spreadsheet—the unmet demand that becomes shadow IT. Gartner found that half of business technologists already produce technology capabilities for users beyond their own department, often outside formal IT. The building is already leaking out of engineering. The only question is whether it lands somewhere governed.
Here’s the cost most leaders miss: every hour a senior engineer spends on the 400th form-over-database app is an hour not spent on the substrate, the hard integration, or the architecture decision that compounds. The long tail doesn’t just clog the queue. It pulls your most expensive, most capable people down to the least differentiated work in the building.
What is a substrate, and why should engineers own it?
A substrate is the shared foundation an organization’s software runs on—the identity and auth system, the data layer, the deployment path, the logs and access controls. It’s the thing you build once and everyone else builds on top of. Owning it is the highest-leverage job in the engineering org, because its quality sets a ceiling on everything built above it.
This is the move software engineering already made internally. You don’t make developers faster by hiring more developers to take tickets; you give them a paved road they can ship on without filing one. Gartner predicts that by 2026, 80% of large software-engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools—up from 45% in 2022. The pattern is well understood: a small team builds the substrate, and that substrate multiplies everyone else’s output.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
The new shape of this is extending the substrate past the engineering org to the whole company. The people building on it are no longer only software engineers—they’re the finance analyst, the ops lead, the support manager who each understand a workflow well enough to build the tool for it. The engineer’s job is to make sure that when any of them build, the auth, the data governance, and the deployment are already handled, so what they ship is safe by construction. The substrate is what lets an org decentralize the building while centralizing the seeing—everyone ships on the same foundation, so distribution never costs visibility. That’s architecture work. It’s more valuable than the CRUD app it replaces, and it’s exactly what your best engineers should be doing.
Isn’t “give everyone an AI coding assistant” the same thing?
No—and the gap is the whole argument. The most common attempt at “let everyone build” is to hand every employee an AI coding assistant—Cursor, Claude Code, GitHub Copilot—and expect non-engineers to produce their own tools with it. It underdelivers for a specific, structural reason: those tools operate at the code layer.
Coding agents are excellent—for engineers. They edit files in a project you already own, assume you can read what they produce, run a dev environment, wire up a database, and deploy the result. For someone who already has those skills, that’s a real accelerator, and engineers should keep using them. Point the same tool at a finance analyst and you haven’t removed the barrier to building—you’ve relocated it. The analyst can now generate code they can’t evaluate, run, secure, or ship. The bottleneck moves from “wait for engineering to build it” to “wait for engineering to figure out what this generated code does and whether it’s safe.”
That’s a layer mismatch, not a put-down of the tools. The distinction between a tool that meets an engineer at the code layer and one that meets a non-engineer at the product layer is the difference between an accelerator for people who already build and a way for people who don’t. If the goal is to take the long tail off engineering’s plate, the coding-assistant route doesn’t do it. The code still has to come back to an engineer—just later, and harder to read.
Who reviews the apps non-engineers build?
This is the question that decides whether the whole model works, and it’s where most “everyone can build” stories quietly fall apart. Distributing the building is the easy part. Keeping it governable is the hard part—and governance, in practice, means review. Someone has to be able to look at what a non-engineer built and answer: what data does this touch, who can access it, is it safe to ship?
Now scale that across hundreds of employees, each building tools, each tool a body of code. If review means an engineer reading generated code app by app, the review function becomes the new bottleneck—worse than the old ticket queue, because now the volume is the whole company. No team can staff that. “Everyone builds” without a tractable way to review is just shadow IT with executive sponsorship.
The unlock is changing what gets reviewed. A spec is a plain-language plan for an app—what it does, what data it holds, who can use it—the brief you’d hand a developer, except a compiler builds from it. If the source of truth for each app is that spec rather than the code, then review means reading and approving a plan, not auditing a sprawl of files. A senior engineer can evaluate a plan the way a contract gets reviewed—not by inspecting brick by brick the building it governs. Make the spec the artifact of record, and review scales with engineering judgment instead of engineering typing speed. That’s a job worthy of a senior engineer; reading the 400th generated CRUD app is not.
What does the highest-leverage engineering work actually look like?
It’s the work that doesn’t generalize, doesn’t fit a template, and compounds. When the long tail comes off the plate, what’s left is the work that was always the best use of scarce talent—the org just never had the room to prioritize it.
The contrast is sharpest laid side by side. The left column is where too much senior engineering time goes today. The right column is where it should go.
| Low-leverage (push off the critical path) | High-leverage (where your best engineers belong) | |
|---|---|---|
| Typical work | The 400th form-over-database app | Designing the substrate every app runs on |
| Pattern | Repeats across teams with minor variation | Unique, doesn’t generalize, compounds |
| Integrations | Yet another CRUD form | The hard systems: billing, identity, legacy, real-time data |
| Standards | Each tool reinvents auth and data access | Setting the patterns and guardrails everyone inherits |
| Review | N/A—engineering wrote it | Approving plain-language specs for what others ship |
| Output ceiling | Capped by engineering headcount | Capped by the quality of the foundation—far higher |
| Strategic posture | Reactive backlog clearing | Leverage: govern hundreds of apps you didn’t write |
Read the last row first. Moving up the stack isn’t about doing less. It’s about converting engineering from a function whose output is capped by how many people you can hire into one whose output is capped by how good its substrate, patterns, and review are. That ceiling is far higher—and it’s a more interesting job. Architecture, hard integrations, and the patterns the whole company inherits are the work senior engineers want to do anyway. The long tail was never it.
This is also why this is a releveling, not a downsizing. The substrate gets more important as more people build on it, not less. Someone still has to design it, harden it, and decide what’s allowed to land on it. That someone is your best engineer—now pointed at the work that compounds instead of the work that repeats. It’s the same shift driving the 2027 org chart where everyone builds and a core team owns the substrate.
The turn: what makes the substrate model real
Everything above describes the operating model the winning engineering org needs: the long tail of routine apps built by the people closest to each problem, a governed substrate a small senior team owns underneath all of it, and review done on plans rather than code. The model is sound on paper. It only becomes real if two things are true at once—non-engineers can produce working, governed apps without engineering, and what they produce is reviewable by a human who isn’t reading code.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
That’s what a new category of AI tool—the product agent—is built for. Today the most advanced one is Remy. Someone describes the app they need in plain language; Remy drafts a spec—a readable, plain-language plan—and that spec compiles into a real full-stack app: backend, database, real server-side auth and roles, frontend, and a live deployment. The spec is the source of truth, so a reviewing engineer reads and approves the plan, not the generated code, and changing the app means editing the plan and recompiling rather than hand-maintaining a codebase. A typical full-stack build runs around $30–40 in inference—cheap enough that the long tail is finally worth building.
That spec-as-source-of-truth mechanic is what makes governance and review tractable at company scale. Reviewing hundreds of plain-language plans is a job a senior team can do; auditing hundreds of generated codebases is not. And because every app compiles onto the same governed stack—shared identity, shared data layer, shared logs—the engineers who own the substrate get the other half of their mandate for free: the apps aren’t a hundred islands to audit after the fact, they’re observable by construction.
Remy is a product agent that compiles annotated markdown into a full-stack app—backend, database, frontend, auth, tests, and deployment—in a single step. See goremy.ai. One honest boundary: this is early. Product agents are in open alpha, and enterprise needs like SSO and SAML aren’t there yet. But the org-design point doesn’t wait for the category to finish maturing. The decision to point your best engineers at the substrate—and let the long tail land on it as reviewable specs—is one you make now, so the foundation is ready when the tooling matures around it.
FAQ
Does AI-assisted building make engineers less valuable? No—it makes the most valuable engineering work more valuable. When non-engineers can build the routine long tail, scarce engineering talent moves up to designing the substrate, handling hard integrations, setting patterns, and reviewing what ships. Engineering relevels to higher-leverage work; it doesn’t shrink.
What is a substrate in software terms? The shared foundation an organization’s software runs on—the identity and auth system, the data layer, the deployment path, and the logs and access controls. Engineers build it once so everyone else can build on top of it safely, and its quality sets a ceiling on everything built above.
What’s a CRUD app? An app whose core job is to create, read, update, and delete records—a form over a few database tables, like an approval tracker or a vendor-intake form. It’s the most common shape of internal software and the bulk of the long tail that clogs engineering backlogs.
Why isn’t giving everyone Cursor or Copilot enough? Coding agents operate at the code layer and assume engineering skill. For a non-engineer, that relocates the barrier instead of removing it—they can generate code they can’t evaluate, secure, or ship, which just moves the bottleneck onto an engineer’s review queue. The tools are excellent for engineers, wrong for non-engineers.
Who reviews the apps non-engineers build? A senior engineer or platform team. The model only scales if review is tractable—which means reviewing a plain-language spec describing what the app does and what data it touches, rather than auditing generated code app by app. Reviewing code at company scale would be a worse bottleneck than the old backlog.
What is the highest-leverage work for a senior engineer? Designing and hardening the substrate, integrating the genuinely hard systems, setting the patterns and guardrails the whole company inherits, and reviewing what gets built. This work compounds and doesn’t generalize, which is exactly why it’s a better use of scarce talent than the routine long tail.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Where should an engineering leader start? Decide that the long tail of routine internal tools should be built by the people closest to each workflow, on a governed substrate the engineering org owns—provided what they build is reviewable as a plain-language spec. That single decision frees your best engineers from backlog clearing and points them at the architecture.
The bottom line
The most valuable thing your best engineers can do is not write the 400th CRUD app—it’s build and govern the substrate the whole company builds on. When non-engineers can describe what they need and get a working tool back, engineering relevels: less routine construction, more architecture, hard integrations, pattern-setting, and review. That’s a more strategic engineering org with leverage no headcount-bound team ever had. The catch is review—distributed building only stays governable if a human can approve a plain-language plan instead of auditing a codebase.
That’s the piece a product agent supplies: real full-stack apps compiled from a spec, on one governed stack, so review happens on the plan and the substrate stays the engineer’s domain. If you want to see what that looks like in practice, explore Remy →. For the bigger operating-model picture, read how IT moves up the stack when everyone can build and why your best engineers don’t work in engineering.
