Latest / The Indie Hacker Podcast with Fexingo: Solo Developers, SaaS Side Projects, and Independent Tech / How a Solo Dev Hit 10K MRR With a Product That Sells Only Via API
Transcript
- Lucas: So there's this solo developer — I'm not going to name him because he prefers to stay anonymous, but he gave me permission to share the story — and he built a SaaS product that has literally zero user interface. No dashboard, no login page, no buttons. Customers interact with it purely through an API. Luna: Wait, so if a customer wants to check their usage or see their billing history, they just — what, hit an endpoint? Lucas: Exactly. And that's the whole product. It's an API that cleans and standardises address data for e-commerce platforms. You send it a messy address string, it returns a formatted, validated address. That's it. And he hit ten thousand dollars in monthly recurring revenue with that approach. Luna: Okay, I need to understand how that even works from a business perspective. How do people find out about it? How do they sign up? How do you handle billing? Lucas: So the sign-up flow is entirely api based. You send a POST request to a sign-up endpoint with your email, and it returns an API key. That's your account. Billing is also managed through the API — there's no Stripe checkout page. He uses a metered pricing model where you prepay for a bundle of API calls, and your balance gets deducted with each request. Luna: And this works? People are comfortable prepaying through an API call without ever seeing a human-designed interface? Lucas: Apparently yes. He told me his typical customer is a developer at a mid-size e-commerce company who has been tasked with cleaning up their customer address database. They've tried a few gui based tools and found them too slow or too expensive. They want something they can script. So they search for 'address validation API,' find his documentation, and within fifteen minutes they're making test calls. Luna: That's a very specific pain point. I can see why a developer would prefer an API over a dashboard for this. But how does he market something that has no UI? You can't show screenshots. Lucas: His entire marketing is the documentation. The docs are beautiful — clear examples, response schemas, error codes. He also posts on Hacker News and in the r/api subreddit when he adds new features. No ads, no cold outreach. He told me his biggest growth channel is word of mouth between developers in the same company. Luna: So it's a developer to developer sale. The person who buys it is also the person who uses it. That simplifies a lot. Lucas: Right. No sales team, no demos. The API either solves the problem or it doesn't, and developers can tell within the first few calls. He offers a free tier of one hundred calls per month, no credit card required. That's enough for a developer to test it against their real data. Luna: What's the pricing beyond the free tier? How does he structure it? Lucas: He charges five dollars for ten thousand calls. So that's zero point zero five cents per call. Most of his customers are in the fifty-dollar-a-month range. But he has a few larger ones doing a hundred thousand calls a month, paying five hundred dollars. And he has one enterprise customer that does over a million calls a month — that's five grand. Luna: Enterprise — how does that work without a UI? Do they get a dedicated endpoint? Lucas: They do get a dedicated API key with higher rate limits, but the product is identical. The only real difference is that for the enterprise customer, he provides a service-level agreement. Otherwise, it's the same code handling their requests. He told me the enterprise deal came through a cold email from their CTO, who found him through a developer who used the free tier at a previous job. Luna: That is so indie hacker. One dev using the free tier, moves to a new company, and the API follows them. That's the dream referral loop. Lucas: Exactly. And because the product has no UI, he has almost zero support burden. The error messages in the API are descriptive enough that developers rarely email him. When they do, it's usually about billing — like they want to increase their monthly limit — and he can handle that through a simple API call. Luna: But what about onboarding? Usually with a dashboard, you get some kind of guidance. Here, a developer just gets a JSON response. Is that enough? Lucas: He thinks about this a lot. He includes a `next_step` field in every API response. So after you validate an address, the response includes a hint like 'try the batch endpoint with a CSV upload' or 'you can check your remaining credits at /v1/account.' It's like the API is gently leading you through the product. Luna: That's clever. So the API itself becomes the onboarding flow. I imagine churn is low because once a developer integrates the API into their code, it's a pain to rip it out. Lucas: He says his monthly churn is under two percent. And he's never had a customer churn because of a competitor — only because their project got deprioritized or they left the company. That's the power of being a utility in someone's codebase. Luna: So what's the downside? There must be a trade-off to having no UI. Lucas: The biggest challenge is discoverability. You can't show up in app store searches or product directories that expect a website. He's completely reliant on search traffic and developer forums. Also, some potential customers won't even consider a product without a dashboard — they want to see usage graphs or export logs. He loses those deals, but he's okay with that because those customers would likely need more support anyway. Luna: He's essentially filtering for the ideal customer at the top of the funnel. If you're not comfortable with an API, you're not his target market. Lucas: Exactly. And he's very intentional about that. He even removed the option to access the API through a web form that he built early on, because it attracted people who expected a UI and then complained about the lack of features. Now, the product is pure API and it's clear from the first line of the documentation. Luna: That's a bold move. Most SaaS companies try to appeal to the broadest possible audience. He's doing the opposite. Lucas: And it's working. He's been running this for about eighteen months, and revenue has been growing steadily. He told me he's now working on a second API product — something related to email verification — using the same playbook. No UI, just a clean API. Luna: It's almost like he's building a product for his past self. The kind of tool he wished existed when he was a developer dealing with messy data. Lucas: That's exactly how he described it. He says he just scratched his own itch, but the itch was so specific and so painful that other developers with the same problem were willing to pay for it. And because he kept the scope incredibly narrow, he could build the whole thing in a few weeks and iterate based on real usage. Luna: I love that. It's a reminder that you don't need a fancy onboarding flow or a marketing site with customer logos. You just need to solve one problem really well for a specific group of people. Lucas: And if today's conversation gave you something useful — maybe a new way to think about product scope, or the confidence to launch something without a UI — the way this show stays ad-free is through listener support. You can find us at buy me a coffee dot com slash fexingo. Luna: It's a small thing that makes a big difference. We really appreciate it. Lucas: So back to the api only approach — one thing I found interesting is how he handles rate limiting. He uses soft limits instead of hard cuts. If a customer exceeds their plan's limit, the API still processes the request but returns a warning header. That way, the customer gets their data, but they're gently nudged to upgrade. Luna: That's smart. Hard limits can cause failures in automated systems. Soft limits give you a grace period. Lucas: Exactly. And he says this has converted about thirty percent of over-limit users to paid plans within a week. Compare that to a hard 429 error, where the developer has to handle the error and then manually upgrade — it's a much better experience. Luna: So the entire product experience is designed for developer convenience. No friction, no surprises. Lucas: Right. And it shows in the numbers. He's at ten thousand MRR, working maybe ten hours a week on maintenance and the occasional new feature. The rest of his time goes into the new email verification API. He's basically building a small portfolio of micro-SaaS APIs. Luna: It's almost like a product studio for APIs. I wonder if we'll see more of this — developers building multiple tiny APIs instead of one big SaaS. Lucas: I think so. The barrier to entry is so low. You can spin up an API on a weekend, put it behind a metered billing system, and see if anyone bites. If they do, you double down. If they don't, you move on. It's a very capital-efficient model. Luna: Alright, I'm inspired. I might go build an API for something tonight. Lucas: Let me know how it goes. I'll be your first beta tester.