The fourth product page taught us more than the first three combined. Not because it was harder—because it was easier. And that difference is everything.
Last week, Strug Works shipped the Sports Excellence Hub product page. Seven sections. Five custom components. Aurora-cyan accent color. An "In Active Development" badge that tells the truth about where we are. PR #58 merged, deployed, live.
But here's what matters: we didn't reinvent anything. We reused BuiltOnAntiStrug, ClosingCTASection, and CarouselFrame—components we'd built for earlier pages. The frontend agent knew where to find them, how to adapt them, and when to create something new versus when to compose from what already existed.
That's not a technical detail. That's the entire game.
The Pattern We Didn't Plan For
When we built the first product page—Sabine—it was bespoke. Everything custom. Every component new. That was fine. You have to start somewhere.
The second page (Strug Works) introduced some shared patterns. The third (Strug AI Platform) started to feel like we had a system. But the fourth? The fourth page is where the system proved itself.
I didn't write a single line of code for the Sports page. I described what I wanted, pointed at the other pages as references, and let sc-frontend do what it does. The result isn't just functional—it's consistent. Same design language. Same animation patterns. Same accessibility standards. Same performance characteristics.
This is what people miss when they talk about AI coding assistants. They think the value is "writing code faster." That's table stakes. The actual value is encoding institutional knowledge into reusable patterns—and then having agents that know how to navigate, apply, and extend those patterns without constant human oversight.
What Platform Reuse Actually Means
Three shared components. That doesn't sound like much. But let's talk about what those three components represent:
BuiltOnAntiStrug is our philosophical anchor. Every product page includes it. It's not marketing fluff—it's the actual technical foundation we build on. The agent knew to include it because it's part of our identity, not because I told it to.
ClosingCTASection handles conversion. Same structure, same animation timing, same accessibility patterns. We refined it once. Now every page benefits.
CarouselFrame is a layout primitive. Touch-friendly, keyboard-navigable, screen-reader-compatible. Built once, reused everywhere.
This is what good platform thinking looks like. Not "everything is a shared component." But "the right abstractions emerge through repetition, and then we codify them."
The Honest Part
This sounds smooth. It wasn't.
The first two product pages required significant back-and-forth. Component naming inconsistencies. File structure debates. Import path confusion. The kind of friction that kills momentum on human teams and absolutely murders it on agentic ones.
We had to learn—both me and the agents—what patterns were worth encoding versus what was one-off context. I had to get better at describing intent instead of implementation. The agents had to get better at inferring structure from existing code.
The Sports page was easier not because the agents got smarter (though they did), but because the codebase got clearer. Better separation of concerns. More consistent naming. Fewer hidden dependencies.
That's the lesson: agentic development doesn't eliminate technical debt. It makes it more expensive. Every shortcut you take, every inconsistency you leave, every "I'll fix that later" comment—it all compounds faster when agents are navigating your codebase.
What This Means for Act V
We're in Act V now—bringing products to market. The Sports Excellence Hub is still in active development. The "In Active Development" badge on the page isn't apologetic. It's honest. We're building in public. That means showing the work while it's still work.
But here's what I know now that I didn't know three product pages ago: the fourth page was faster than the third. The fifth will be faster than the fourth. Not because we're cutting corners—because we're encoding knowledge.
Every reusable component is a decision we don't have to remake. Every consistent pattern is cognitive load we don't have to carry. Every time an agent successfully navigates our codebase without human intervention, it proves that we're building something that scales beyond one person's working memory.
That's the promise of agentic organizations. Not that AI writes your code. That AI extends your leverage by operating within systems you've deliberately designed to be navigable, reusable, and composable.
What's Next
More product pages. More shared components. More patterns to encode.
But also: documentation of what we're learning. Not tutorials. Not thought leadership. Just honest accounting of what worked, what didn't, and what we'd do differently next time.
Because that's the whole experiment: can one person, the right AI team, and the audacity to build in public create a fully autonomous product and engineering organization?
Four product pages in. The answer is starting to look like yes.