I’ve seen it a hundred times. A founder comes to me, buzzing with excitement, showing off their slick, pixel-perfect app. Every animation is smooth, the color palette is a work of art, and the user experience feels like magic. They’ve spent months, sometimes years, polishing this digital jewel. And I have to be the one to tell them the hard truth.
Your beautiful UI is a lie.
It’s a fantastic, convincing, and often expensive lie, but it’s a lie nonetheless. Because what you’re showing me is just a pretty face. The real product, the thing that will make or break your company, is the engine under the hood. Your API.
I learned this lesson the hard way. At MovieLaLa, we were obsessed with creating a beautiful, engaging experience for movie fans. We poured everything into the UI. We wanted it to be fun, seamless, and visually stunning. And it was. Users loved it. But when it came time to scale, to integrate with partners, to build new features on top of our core platform, we hit a wall. A big, ugly, API-shaped wall.
Our backend was a mess of spaghetti code, an afterthought cobbled together to support the precious UI. Every new integration was a custom, time-sucking project. We couldn’t move fast. We were trapped by our own beautiful prison. When Gfycat acquired us, the first thing they had to do was rebuild the entire infrastructure. It was a painful, expensive, and humbling experience.
With my next company, RemoteTeam, we did the exact opposite. We started with the API. Before we wrote a single line of frontend code, we designed our API. We documented it. We tested it. We treated it like the product it was. Our own web app was just the first customer of our API. And you know what happened? Everything else became easy.
Building our mobile app? Simple. It just consumed the same API. Integrating with Gusto for our acquisition? A breeze. Their engineers were thrilled with our clean, well-documented endpoints. We could build new features in days, not months. We could support enterprise customers with custom needs without rewriting our entire stack. That API-first approach is a huge part of why Gusto acquired us.
The Modern SaaS is API-Driven
Founders get this wrong because they’re still thinking in an old paradigm. They think of their app as a monolithic thing. But in the world of SaaS, and especially AI-powered SaaS, your product isn’t a single interface. It’s a set of capabilities exposed to the world through an API.
Think about the companies I’ve been lucky enough to invest in. Anthropic, OpenAI, Scale AI, Hugging Face. What are they selling? They’re selling APIs. Their web interfaces are just convenient wrappers, demos for the real product. Their entire business is the API. The UI is a marketing tool.
Your users might not ever see your API. They might not even know what an API is. But they will feel it. They’ll feel it in the speed and reliability of your app. They’ll feel it when your app seamlessly integrates with the other tools they use. They’ll feel it when new features appear like magic. And your developers will certainly feel it. A clunky, unreliable, poorly documented API is a tax on every single thing you do. It’s a drag on your velocity, a drain on your morale, and a ticking time bomb for churn.
What Makes a Great API?
So what separates a great API from a terrible one? It’s not about using the latest and greatest technology. It’s about discipline and user empathy. But the user isn’t your end-user, it’s the developer who has to work with your creation.
Here’s my checklist for a world-class API:
Crystal-Clear Documentation: If a developer can’t figure out how to use your API in 10 minutes, you’ve failed. Your docs should be comprehensive, with real-world examples for every endpoint. They should be interactive, allowing developers to make test calls right from the browser. This isn’t a nice-to-have; it’s the front door to your product.
Rock-Solid Reliability: Your API needs to be more reliable than your UI. It should have predictable uptime and performance. When a developer builds on your API, they are betting their own product on your stability. Don’t let them down.
Blazing Speed: A slow API means a slow app. Every millisecond counts. You need to be obsessive about performance, caching, and query optimization. In the age of AI, where a single API call can involve massive computation, this is more important than ever. The costs of running inefficient AI models can kill your margins.
Unwavering Consistency: Your API should have a predictable, logical structure. Naming conventions should be consistent. Error handling should be uniform. A developer should be able to learn the patterns of your API and apply them everywhere. Don’t make them re-learn your quirks with every new endpoint.
The API-First Litmus Test
Want to know if you’re truly an API-first company? Here’s a simple test:
- Can you build a completely new product (e.g., a mobile app, a command-line tool, a third-party integration) using only your public API documentation?
- Is your own web app built on the exact same public API?
- Do you have a dedicated team or owner for your API product?
- Do you have a public status page for your API uptime and performance?
If you answered no to any of these, you have work to do. You’re not an API-first company. You’re a UI-first company with a backend problem.
Stop obsessing over the pixels. Stop tweaking the animations. Stop debating the perfect shade of blue. Go look at your API. Look at your documentation. Look at your response times. That’s your product. That’s your business. A beautiful UI on top of a terrible API is like a sports car with a lawnmower engine. It might look good, but it’s not going to get you very far.
Frequently Asked Questions
How has this view evolved over time?
My thinking on most topics has changed significantly over the years. Early in my career, I held many conventional views that experience proved wrong. I try to update my beliefs when the evidence changes.
What's the most common pushback you get on this?
People often push back by citing exceptions or edge cases. And they're usually right that exceptions exist. But building a strategy around exceptions rather than patterns is a losing game for most founders.
How can I apply this thinking to my own situation?
Start by identifying the core principle behind the opinion, not the specific example. Then ask yourself: does this principle apply to my context? If yes, test it in a small, low-risk way before going all in.