Selling an API as a Solo Developer

You built a small service that does one annoying thing well. Maybe it turns messy addresses into clean structured data, or converts a document, or wraps a model with logic that took you a week to get right. Your instinct is to bolt a UI onto it and call it an app. Slow down. If your customer is another developer, the product might not be a screen at all. It might be an endpoint. Selling the raw capability as an API can be one of the cleanest solo businesses there is, because you skip the entire job of designing an interface for humans and sell the thing itself.

This guide is about doing that on purpose: what makes an API worth paying for, how the money actually flows, how to price it without getting wrecked by your own infra bill, and the part almost nobody mentions until it hits them, the day someone's production system depends on you.

Where does the money actually come from?#

The money comes from a developer trading dollars for time and reliability they would otherwise have to produce themselves. Here is the chain.

Developer has a problem inside their own product
        |
        v
Building the solution in-house = days of work + ongoing maintenance
        |
        v
They find your API (docs, marketplace, a colleague, search)
        |
        v
They test it in an afternoon and it just works
        |
        v
They wire it into their app (you are now a dependency)
        |
        v
Every call they make = metered usage or a subscription tier
        |
        v
They keep paying because ripping you out costs more than staying
        |
        v
Recurring revenue that compounds as their usage grows

Notice where the value sits. It is not in the individual API call, which might cost you a fraction of a cent to serve. It is in the days of work the developer did not have to do, plus the maintenance they never have to think about again. That gap between what it is worth to them and what it costs you to run is your margin, and for a well-built API it can be wide. If the idea that money comes from value delivered, not effort spent, is still fuzzy, where does online money come from lays out the foundation.

The concrete move: write one sentence naming the exact task your API removes and roughly how long that task takes a developer to build and maintain themselves. That sentence is your value, and everything else prices off it.

What makes an API actually worth paying for#

Not every capability is worth money as an API. Developers are skeptical and capable, and they will not pay for something they can npm-install in five minutes. The APIs people pay for tend to share a few traits, and it is worth being honest about whether yours has them.

It does something genuinely hard or annoying. Real-time data that is a pain to source, a model that took real work to tune, parsing with a thousand edge cases, an integration that is miserable to authenticate against. If a junior dev could rebuild your endpoint over a weekend, you do not have a product, you have a tutorial.

It has clean, reliable output. A big part of what a developer buys is not having to sanitize, validate, and second-guess your response. Consistent shapes, sane defaults, sensible errors, and data they can trust are worth a premium. Garbage they have to clean up defeats the point of paying you.

It saves real, measurable dev time. The clearer the time saving, the easier the sale. "This replaces the three days you would spend building address validation and the ongoing job of keeping it accurate" is a pitch a developer understands instantly.

It is reliable and boring in the best way. Developers do not want excitement from a dependency. They want an endpoint that returns fast, returns correctly, and is up when they call it. Reliability is arguably the feature.

The concrete move: score your idea against these four honestly. If it fails the "could a competent dev rebuild this in a weekend" test, either find the hard part you are actually solving or pick a different project. How to build a micro-SaaS has more on choosing a problem worth solving.

How it works: usage pricing vs seat pricing#

This is where APIs differ from most SaaS. The core question is what you charge for.

Seat pricing (per user) is the default for software with a UI, because value scales with the number of humans logging in. It mostly does not fit an API. Your customer is a machine calling an endpoint. There are no seats, and "per developer on the team" is easy to game and unrelated to how much value they extract.

Usage pricing fits an API naturally, because usage is the value. A customer making a million calls a month is getting far more out of you, and costing you far more to serve, than one making a thousand. Meter the thing that tracks value: API calls, records processed, tokens, minutes of compute, whichever unit maps cleanly to both the customer's benefit and your cost.

In practice, most solo API businesses use a hybrid: tiered subscriptions with usage baked in. A flat monthly fee gets the customer a bucket of usage (say, 10,000 calls), higher tiers get bigger buckets, then overage or a jump to the next tier once they blow past it. This gives you predictable recurring revenue (the flat fee) while still scaling with value (the tiers and overage), and it is easier for customers to budget than a pure pay-as-you-go meter. The general pricing logic, value-based thinking, anchoring, and why cheap is often harder to sell, all applies here, and how to price your SaaS is worth reading alongside this.

The concrete move: pick the single unit that best tracks both customer value and your cost to serve, then build three tiers around buckets of that unit with the plan you want most people on sitting in the middle.

A clearly hypothetical worked example#

Here is the margin math that makes an API attractive. Every number below is invented to show the shape of the thing. It is not earnings, not typical, and not a promise.

Imagine an API that does one useful transformation. Your real cost to serve a call is dominated by infrastructure: compute, a bit of bandwidth, maybe a third-party service you call behind the scenes. Say that lands at $0.0004 per call, all in (hypothetical).

Say you price a middle tier at $49 a month for 100,000 calls, which is $0.00049 per call at the cap. That looks like almost no margin, and this is the trap beginners fall into. Look at it monthly instead.

Middle tier: $49/month for 100,000 calls
-----------------------------------------
Revenue if they use the full bucket:   $49.00
Your infra cost at $0.0004 x 100,000:   $40.00
Gross margin:                            $9.00  (about 18%)

That is a bad business. You are one traffic spike from serving calls at a loss, and support eats the rest. Now price the way value justifies, because the customer is saving days of dev work, not buying calls by weight:

Middle tier: $99/month for 50,000 calls
-----------------------------------------
Revenue:                                $99.00
Your infra cost at $0.0004 x 50,000:    $20.00
Gross margin:                            $79.00  (about 80%)

Same product, same code, a price set on value rather than on cost plus a hair. The second version has room to absorb a heavy user, fund support, and survive an infra price change. This is the whole game with a usage product: your cost per unit is tiny, so pricing just above cost builds a fragile treadmill, and pricing on the value delivered builds something that actually pays you. For how these margins stack into a real revenue number over time, what gets a SaaS to 10k MRR walks the path.

The concrete move: build this table for your own API. Estimate honest per-call infra cost, then set tier prices so your gross margin sits comfortably high. If you cannot keep margin healthy, your infra is too expensive or your price is too timid.

What you need and what it costs#

You need less than you think to start, and the temptation to over-build the platform is strong. Resist it.

Required: the working service, an API gateway or framework that handles auth (API keys at minimum), rate limiting so one customer cannot melt your infra, a metering system that counts usage accurately, and a payment processor. Stripe handles metered and subscription billing, or a merchant of record like Paddle or Lemon Squeezy handles billing plus sales tax and VAT, which matters the moment you sell internationally. You also need documentation, which for an API is not optional marketing fluff. Docs are the product surface. A developer decides whether to buy based on whether your docs let them make a successful call in a few minutes.

Optional and useful: a self-serve dashboard where customers see usage and rotate keys, client libraries in a couple of popular languages, and a status page. Nice to have, not now: SDKs in every language, an interactive API explorer, webhooks, granular per-endpoint pricing. Solo devs love building billing and dashboard infrastructure because it is a satisfying problem. That instinct will happily eat a month you should spend getting customers.

The real ongoing cost is not the tools. It is infrastructure that scales with usage (fine, because they pay you more too) and your own time on support and uptime. Budget for both honestly.

The concrete move: ship with API-key auth, rate limiting, accurate metering, Stripe, and genuinely good docs. Skip everything else until a paying customer asks for it.

How long it takes#

Building the endpoint is often the fast part, especially if the hard logic already exists from whatever side project spawned it. The slower parts are the ones that make it a product rather than a demo: solid metering, docs a stranger can follow, auth that does not leak keys, and rate limiting that protects you.

Getting the first paying developers takes longer than getting the code live, because developers try before they trust. Expect a cycle where someone reads the docs, tests on a free tier, sits on it for a while, then wires it in once they trust it will stay up. That is slower than a consumer impulse buy. Do not read early silence as failure; read it as developers doing their due diligence, which is exactly the behavior you want in customers who then stick around.

The concrete move: give yourself a realistic runway and treat the first few weeks as a trust-building period, not a referendum. Keep the API up, answer every question fast, and let the quiet early adopters convert on their own timeline.

What beginners get wrong#

The mistakes here are consistent, which means you can dodge them.

Underpricing against infra cost. Covered above, and it is the big one. Pricing a hair over your per-call cost feels safe and quietly builds a business with no margin to absorb a heavy user or a support ticket.

Treating docs as an afterthought. For an API, weak docs are a broken storefront. If a developer cannot make a successful call quickly, they leave, and you never even see them. How to build a micro-SaaS touches on this, but for an API it is existential.

Underestimating the dependency burden. The day you take money, you have promised uptime. A hobby project that flakes out on weekends cannot be someone's production dependency. If you are not ready to treat reliability as the job, you are not ready to charge.

Building for scale you do not have. Elaborate multi-region infrastructure and every SDK under the sun before a single paying customer is procrastination dressed as engineering. Serve real customers first, then harden.

Ignoring distribution entirely. "If I build a good endpoint, developers will find it" is the same build-it-and-they-will-come fantasy as everywhere else. Developers have to hear about you first, and distribution channels for a new SaaS is where that starts.

The concrete move: find the one you are about to do, and fix it before launch rather than after your first angry incident.

How I would start#

If I were selling an API as a solo dev today, here is the exact sequence I would follow.

1. Nail down the one hard thing. Write the single sentence describing the painful task my API removes and how long it takes a developer to build and maintain themselves. If I cannot make that painful and specific, I pick a better problem.
2. Ship the smallest real version. One or two endpoints, API-key auth, rate limiting, and accurate metering from day one. Metering is not a later feature; if I cannot count usage correctly I cannot bill correctly.
3. Write docs a stranger can follow. A quickstart that gets someone to a successful call in under five minutes, clear examples, and honest error descriptions. I would test this on a developer who has never seen the product.
4. Price on value, not cost. Three tiers built around buckets of my usage unit, margin kept comfortably high, the plan I want most people on in the middle, and the number set a notch higher than feels comfortable.
5. Put it where developers already look. List it on a marketplace like RapidAPI to borrow their discovery and billing, and write about the specific problem it solves where developers search for it. Marketplaces and integrations are real distribution, and partnerships and integrations as distribution goes deeper on becoming the easy default inside tools people already use.
6. Get the first ten paying developers by hand. Reach the people who have this exact problem, help them integrate personally, and treat their feedback as the roadmap. Get your first customers is the playbook for this stage.
7. Then, and only then, invest in reliability and polish. Once real money depends on the API, uptime, monitoring, a status page, and more client libraries earn their keep.

What I would not do#

I would not price just above my per-call cost, because a fragile low-margin usage business is a slow way to lose. I would not launch without accurate metering, because unbillable usage is money I will never recover. I would not treat docs as something to write later, because for an API the docs are the sales page. I would not promise an SLA I cannot keep on solo infrastructure, because a broken promise to a developer travels fast. I would not build client libraries for eight languages before proving anyone wants the API in one. And I would not take a customer's money while secretly hoping nothing breaks over the weekend, because the moment I charge, being reliable stops being optional.

The bottom line#

Selling an API is one of the cleaner solo-dev businesses because the customer is a developer who understands exactly what they are buying: time they do not have to spend and a problem they do not have to own. You skip building a human interface and sell the capability itself, priced on usage that scales with the value you deliver, and the margin can be excellent because your cost per call is tiny while the work you saved them is large.

The trade is responsibility. The instant someone wires you into their stack, your uptime is their uptime and your bug is their incident. Price for that, support for that, and build for that, and you have a recurring business that grows as your customers grow. Treat it like a weekend toy and it will punish you at the worst possible hour. If you are still deciding what to build, how making money online works frames the bigger picture. But if you have already built the hard thing, the endpoint might be the whole business, and the fastest thing you can do today is write the sentence that names what it is worth.