A year at AI speed
I will not name a single one of them. The patterns are the same anyway.
When I left my last security engineering role, I did not go straight back to a job. I built an intelligent multi-cloud management platform and took it through the Y Combinator application. I did not join the batch, but the process dropped me into a network of founders, and for the next year I advised and consulted for early-stage startups, several of them pre-launch.
I am not going to name one of them. Not the companies, not what they were building, not who. That discretion is not a disclaimer at the bottom of this piece, it is the whole reason founders let me into the room in the first place. But the patterns I saw repeated across nearly every team, and patterns are safe to share. So here is the year, told entirely in patterns.
The short version: the tools moved so fast that no specific tool was ever the advantage. The only durable edge was discipline, and almost nobody had it on purpose.
The pace was the first shock
I came in expecting the hard part to be the technology. It was the speed of the technology changing underneath everyone. What a team built on in the middle of 2025 was stale by early 2026. New models, new frameworks, new defaults, every few weeks.
The teams that struggled had married a snapshot. They wired their product tightly to a specific model's quirks or a specific tool's way of doing things, and when that thing moved, they were stranded, rebuilding plumbing instead of shipping features. The teams that held up had done something subtle: they owned the structure and treated the model as a swappable component. The AI was an engine they could replace, not a foundation they had poured concrete around. When the engine changed, and it always did, they swapped it and kept moving.
The lesson I took: at this pace, betting on any single tool is the bet that ages worst. Build for the rate of change.
The same wall, every time
The other thing I saw on repeat was a wall, and it always showed up in the same place. The first few weeks were magic. A working prototype in days, a demo that landed, real excitement. Then the work stopped being features and started being architecture, and the whole thing slowed to a crawl that nobody could quite explain.
I have written about the shape of that wall before, in Two kinds of holes and in Build it twice on purpose. Watching it happen to team after team is what convinced me it is not bad luck or a bad model. It is the predictable result of mistaking a prototype for a product. The teams that got past the wall treated their fast first build as validation they could throw away, not a foundation they had to defend.
The thing that actually separated them
It was not the model. It was not the framework, the funding, or the founder's pedigree. The teams that compounded all had one thing in common: a single human holding the shape of the system in their head, making the structural calls on purpose, and keeping every AI answer accountable to that shape.
The teams that drifted were missing exactly that person. The code was a sequence of individually reasonable answers with nobody responsible for how they fit together, and it turned into a big ball of mud no matter how capable the underlying model was. The model never decided who made it. The presence of a steward did. That single observation is the spine of how I build now.
Why the silence is the point
I said I would not name anyone, so let me be clear about why. These founders showed me pre-launch products, raw numbers, things that could move a deal or a valuation, because they trusted it would stay in the room. An advisor who tells war stories with names attached is an advisor nobody tells anything real. The discretion is the product.
It is also exactly how we run client work at Social Dolphin Services. The lesson travels, the specifics never do. If you are reading this and wondering whether I would talk about your project somewhere, the answer is sitting right in front of you: this is a whole year of work, and I just told you almost nothing about any of it.
Why it turned into a firm
That year is the reason SDS exists. I kept watching teams hit the same wall, and I kept being the person who could see it coming and help them around it. At some point the pattern was loud enough that I stopped treating it as a series of favors and made it deliberate: a firm that brings the production discipline most teams only learn the hard way, after the demo, when the rebuild is expensive.
And I did not start by selling it. I built a set of my own products first, so the playbook was proven on my own time and my own dime before I ever brought it to a client.
What this is not
- Not a critique of any of those teams. Building a rough prototype fast is the right experiment, not a failure. The only misstep is mistaking the prototype for the product, and most of them did not.
- Not a humblebrag about access. The access is meaningless. The patterns are the entire point.
- Not a list of names. Now or ever.
One-sentence takeaway
After a year advising AI-era startups, the lesson is that no tool is the advantage, because the tools change too fast: the durable edge is a human holding the architecture and the discipline to carry a validated prototype to production on purpose.
Talk to us
If you are building fast with AI and can feel the wall coming, that is the moment a second set of eyes is worth the most. Send us where you are. We will tell you straight what is validation worth keeping and what needs rebuilding before it quietly becomes the product, and it stays between us. That is a useful hour whether or not we end up working together.
We do not take every engagement, and we will tell you on the call whether we are the right partner.