Phase 2, Part 3. Final post in the proof series.
Sometime last year I was looking at a feature we'd built in our customer notification system. It had its own page, its own navigation entry, its own onboarding flow, its own help docs. It was, by every visible measure, a real module.
Barely a fraction of customers used it. The rest didn't know it existed.
I'd watched this happen before — at our company and at every freight tech vendor whose admin console I've ever logged into. You build a thing. It goes in the side nav. The marketing page lists it as a module. The sales team adds it to demo decks. And then most of the customers who would benefit from it never click in, because clicking in requires them to leave the surface they actually live in.
So I started building things differently, and the rule that came out of that experience now governs how we ship every new feature: if it's not 100% proven, it doesn't get its own module. It gets embedded into a surface customers already use.
I want to walk through what this means in practice, because the principle is simple but the consequences are interesting.
A traditional new feature at a SaaS company looks like this: scope the feature, design the screens, build the backend, build the frontend, write the docs, train support, add it to onboarding, ship to GA, watch the dashboards to see if anyone uses it. If usage is low, the team's first instinct is usually to add more — more education, more in-app prompts, more sales-led pushes — instead of asking the harder question: did we build the wrong thing, or did we build the right thing in the wrong place?
The embed-first approach inverts this. We build the smallest possible version of the feature and we drop it into an existing surface — the dashboard the user already opens every morning, the shipment detail page they spend their day inside, the email composer they already use. No new nav. No onboarding. No standalone marketing page.
If users start interacting with it, that's the signal that earns it a real module. If they don't, we've spent a fraction of the budget finding out, and we've kept the surface they actually use uncluttered.
This isn't just about engineering economy. It changes what kinds of features we even consider building. The bar for a full module is now: we have evidence customers use this. The bar for an embed is just: we have a hypothesis worth testing. Hypotheses are cheap to ship and cheap to kill. Modules are not. Treating them differently is how you avoid the sprawling product surface that almost every long-running B2B SaaS ends up with.
It pairs with the other rule that governs how we build — the deterministic core, AI at the edge philosophy I've written about before. That rule draws a line between the parts of the system where AI is allowed to make decisions and the parts where it isn't. Embed-first draws a parallel line between experimental features and proven ones. Same discipline, different layer. Experiments live cheap. Proven patterns graduate.
There's a version of this post I could write that turns embed-first into a copyable framework with five steps and a downloadable checklist. I'm deliberately not writing that post. The framework is barely the point. The point is the question every product team should be asking before they kick off the next module: can this ship as a thin layer inside something users already open, instead of as its own thing?
If yes — start there. The full module, if it ever comes, is something you graduate into, not something you start with.
That's the end of the Phase 2 proof series. Back to monthly cadence — market pulse, customer stories, capability deep-dives — from here on.
