Taste at scale
Why the hardest part of building products stayed human when everything else got automated.
The agency model was always a headcount problem. More clients meant more people. Margins stayed thin because the work couldn’t scale faster than the team. Every studio I watched operate ran into the same ceiling: the work was good, the growth was slow, and the business was fragile.
I built Nirmata to see whether one person with the right tools and judgment could do what used to require a team of eight.
The answer is yes. With a few things worth saying out loud.
The economics changed
Software used to be expensive to build. Three things collapsed at roughly the same time: the cost of execution, the cost of coordination, and the cost of custom software. When those three things were expensive, you needed specialists for each, and a project manager to stitch them together. When they got cheap, the specialists became overhead.
AI writing code is the obvious story. The less obvious one is what that does to project economics. . A custom interface that used to require two weeks of a senior developer’s time can come together in days. A design system that would have needed a dedicated sprint now gets built alongside the thing it governs.
The friction between design and development, the handoff cost that every agency has tried and failed to eliminate, shrinks to almost nothing when one person is handling both ends with AI in the loop.
That’s the mechanical case for Nirmata. Design and development as a single continuous process, owned by one studio, delivered at a pace the traditional model structurally can’t match.
Where product work actually breaks
Most product work fails at the boundary between disciplines. The designer doesn’t understand what’s expensive to build. The developer doesn’t know which edge cases the design was trying to solve. The PM is translating between them and losing signal in both directions. By the time something ships, it’s a negotiated object, shaped more by coordination cost than by the original intent.
Whoever can hold design, engineering, and product decisions in the same head and act on all three without waiting for a meeting will outshine a committee every time.
What gets cheaper is execution. What stays expensive is knowing what to build, why it matters, and whether the thing you shipped is actually working.
Coding agents accelerate shipping, which puts pressure on the part that teams have always struggled with most. That part has stayed stubbornly manual, even as everything around it gets automated. A ticket manager who creates tasks and tracks status is overhead in this model. Judgment isn’t.
A studio that controls the full cycle removes most of the translation steps. The thinking that shapes the design is the same thinking that decides how it gets built. That continuity shows up in the work.
What the freed space is for
The design founder era is partly about aesthetics and partly about this. Founders who can hold the visual and the technical in the same head reliably build things that feel coherent. The interface and the system underneath it are solving the same problem, in the same register.
When agents handle the implementation, something shifts. The cognitive overhead of writing code drops out, and the mental space it occupied goes somewhere else. For me, it goes toward the psychology of what gets built. Why does this pattern create anxiety? Why does this flow cause people to abandon? What does this decision cost the user versus what it earns the product?
I’ve spent years building a library of over a hundred psychological principles that apply directly to product decisions, documented at 1984.design. Loss aversion, cognitive load, the peak-end rule, decision fatigue. Applied directly, they separate a feature that serves users from one that extracts from them.
Dark patterns (aka deceptive patterns) exist because most builders never slow down enough to ask whether what they’re shipping is actually good for the person on the other end. Coding with agents creates that space. The speed is a side effect. The more important thing is what you can think about while the code gets written.
The caution
YC’s Spring 2026 request list named it: AI-native agencies running at software-level margins, same output, none of the coordination cost. A model that treats headcount as a variable, not a fixed input. Nirmata was built on that assumption before the framing existed.
AI-written code still needs someone accountable for what it does. Security, reliability, IP, those don’t disappear because the code came fast. I treat oversight as part of the work, not something you add at the end.
What remains
AI absorbed the execution layer. What’s left is editorial work: knowing what to build, recognizing when it’s right, deciding when to stop.
The design bar will keep rising alongside this. Builders who ship more can iterate faster, which means the gap between good taste and no taste compounds over time. AI also improves its own design output, so even companies for whom design wasn’t a priority will get access to better defaults.
The premium moves entirely to taste, the ability to recognize what works, what doesn’t, and why.
A one-person studio doing the full cycle lives in that space. Which problems are worth solving. Which tradeoffs to accept. How to hold a coherent vision from the first conversation to the thing that ships. AI handles the rest.
That’s why I’m building Nirmata.
Thanks for reading.
— B.
🤝thank you ,