SDK-First Development

Most software products belong to recognizable operational categories long before custom features enter the conversation. CRMs, ERPs, inventory systems, portals, and dashboards share most of the same architectural DNA: authentication, permissions, CRUD, reporting, notifications, workflows, admin tooling.

The industry historically treated endless reinvention of these foundations as normal because implementation was expensive. AI inverts that equation — the unsexy, tedious work teams delayed is now the easiest to scaffold, which makes it some of the highest-leverage investment available.

The shape of the argument is easiest to see in a concrete product category. Consider what a CRM actually is, structurally.

Those three layers are the CRM’s shared DNA. Every serious CRM in the market has them, regardless of brand. They are not where competition happens; they are the table stakes that make competition possible.

Above the shared DNA sits a fourth layer where competition happens: brand and product-specific GTM features, UX polish, conversational interfaces, novel data and AI/ML innovations. This is where the business wins or loses. But Layer 4 only earns its keep when Layers 1–3 have solid coverage early on — otherwise differentiation pays the foundation tax on every feature, and the team never reaches the work that wins.

In an Agile sense, the higher in the pyramid, the more tolerance for ephemeral experimentation and A/B testing — Layer 4 does not need to be as grounded as Layer 1, but Layer 4 is allowed to be loose because the layers below it are strong.

Iteration should happen more frequently, the higher up in the pyramid.

Another way to look at it: separate the codebase from traditional workflow, and what is left? Product. The codebase ends up acting as a custom-built machine that ingests organization-specific specs — closer to a CAD-driven manufacturing system than the artisanal artifact teams have historically treated it as. The SDK foundation is the CAD printer; the product is what feeds it. This split can also become the boundary between two Architecture Groups (Chapter 1) — one governing the foundation, one governing the product — closer to the platform-engineering pattern Team Topologies names than the conventional monolithic team. This example metaphor isn’t a rule, but merely an interesting reframing of how to look at the core codebase.

Restruct™ promotes waterfall SDK-first development: foundations up front, with patience, revisioning the base increasingly less so that Layer 4 product iteration can move exponentially faster. The winning product is still the differentiated one — but its differentiation survives because its roots were thought out before its branches.

Weeds have strong roots but produce nothing. Flowers are fragile. You need an oak: deep roots holding up a tall canopy. Oaks used to take a generation to grow, which is why teams settled for flowers. AI changes the timeline — the oak still needs to be an oak, but growing one is now within reach. That mindset is how reliable product growth happens.