When the interface stops mattering Feb 19
Beside my regular job, I’ve been building software solo for a long time. One person, own codebase, shipping features, fixing bugs, talking to users — the whole deal. And for most of that time, the interface was everything. The UI was the product. You’d spend hours agonizing over a button label, a modal flow, a color choice. If someone couldn’t figure out how to use it within ten seconds, you lost them.
That mental model is quietly breaking down, and I think it’s one of the most interesting shifts happening in software right now.
The interface used to be the gatekeeper
Think about what an interface really does. It sits between your user and the actual capability of your product. The capability is the valuable thing — the data, the logic, the integration, the thing you spent months building. The interface is just the door.
For most of software history, the door had to be beautiful, obvious, and polished. If the door was confusing, users bounced. If it was ugly, they didn’t trust you. The interface shaped the entire perception of quality.
So we designed. We iterated. We A/B tested shades of blue on a CTA button. We rewrote onboarding flows five times. We hired designers. We obsessed.
And it made sense — because that was the only way in.
Now there are a thousand doors
With AI coding tools and agents becoming genuinely good, the interface layer is fragmenting fast. Users can now spin up a custom tool that taps your API and shows them exactly what they need in exactly the way they want it — in an afternoon. No designer required. No waiting for a feature request to climb your backlog. Just “vibe code” it.
I’ve done this myself, more times than I can count. Someone asks for a feature in knipsmig.com that’s too niche for the core product — the kind of thing that matters deeply to three event photographers on the planet. Old me would have filed it as “won’t do” and moved on. New me thinks: does the API support this? Can they, or I, just build a thin client on top? Often the answer is yes.
The broader point is this: as a SaaS builder, you no longer control how your product will be consumed. An AI agent might hit your API on behalf of a user who never opens your app. Someone might build a wrapper that serves a niche you never thought of. A power user might write their own dashboard because yours doesn’t show the one metric they care about.
That’s not a threat. That’s your product becoming infrastructure.
What actually holds its value
When I think about knipsmig, the thing that’s genuinely hard to replicate isn’t the UI. It’s the upload pipeline, the photo processing, the smart sharing logic, the event structure, the data model behind a digital photobook. Those things took time to figure out and refine. The interface on top of it? Honestly, I could rebuild that in a week with a decent AI assistant.
This reframes how I think about where to invest. If your competitive moat is a clever UI, that moat is getting shallower by the month. If your moat is the underlying capability — the data, the integrations, the domain logic — that’s much harder to replicate.
It also changes what a good API means. I’ve always put a lot of effort into the APIs because, first of all I’m a developer myself and love a nice API but also because it just makes it possible to make fewer core features .. and I love a slim core. I think of it as one of the primary surfaces of the product even more today. It’s how AI agents will interact with your service. It’s how power users will extend it. It’s how the next wave of “interfaces” — whatever they look like — will connect to what you’ve built.
Build the capability. Let the interfaces be disposable.
I’m 48 and have been shipping software since I was a teenager. I’ve watched a lot of “the next big thing” come and go. But this one feels different, because it’s not replacing what we do — it’s changing the layer at which we compete.
If you’re building a SaaS product, make the service rock solid. Document the API obsessively. Think about what your product’s unique capability really is, stripped of any interface. Then build that as durably as you can.
The UI? Ship it, improve it, keep it functional. But don’t mistake it for the product. In 2026, it increasingly isn’t.
Someone could fork your interface tomorrow. They can’t fork ten years of domain expertise and the data that comes with it.