Atomios

Another API hub — but built the other way round

Existing hubs — RapidAPI, Zyla, Apify — take heavy fees, give sellers little, and give buyers no real recourse when an API they pay for stops responding. Atomios inverts that: low fees for sellers, and a buyer who is refunded in proportion to the unavailability of the API they bought.

The second bet is about who consumes APIs now. Increasingly it isn't humans, it's agents. So every tool ships as an MCP endpoint with pay-as-you-go pricing, and sellers can package MCP bundles — the marketplace is built for machine consumption, not just a developer copy-pasting a key.

Buyer protection, enforced in the accounting

This is the part I would defend line by line. "Protected" isn't a slogan on a pricing page — it's a settlement path in the code.

When a seller's balance can't cover a refund, a platform fund — financed by the unavailability penalty — covers the gap immediately, and the shortfall is written down as an accounting entry, never silently buried. An assess-before-payout invariant caps the platform's own exposure to its commission.

• 01Availability is measured in basis points from real traffic (successful responses ÷ attempts), excluding Atomios's own downtime so a seller is never penalised for my failures.
• 02Refund = SLA target − availability, prorated over what the buyer actually spent on that listing.
• 03A degressive holdback (5–10% of payouts, held 30–60 days) buffers the exposure, scaled to the seller's track record.
• 04Below 95% availability the listing is hard-stopped: suspended, buyers refunded, penalty applied.

Go, and not only because I like it

The domain is money in integer cents — basis points, refunds, holdbacks, a fund that has to stay solvent — where a floating-point number is a bug waiting to happen. And it is concurrent synthetic health-probing of many third-party upstreams, where bounded goroutines and channel backpressure give me explicit control over load and memory.

So I lead with control and correctness, not raw speed. "Faster than JavaScript" is a claim I won't make without a benchmark; predictable throughput under load is one I can stand behind.

The hard part is the part you can't see

Running a marketplace solo means the expensive surface is invisible: KYC, payouts, a fund that must stay solvent, and the legal apparatus a money-moving platform needs before it can take a single euro — seller and buyer agreements, a DPA, e-invoicing.

None of that shows up as a feature on screen. All of it has to be right before the first transaction, and there is no team to split it with.

One shared core, so the next tool costs almost nothing

Atomios is one hexagonal Go core so that adding a tool costs ≈ 0 at the margin. The architecture isn't a preference — it's a blueprint hardened on my other products and written down as doctrine: strict handler → service → store flow, no cross-module imports, every structuring decision leaving a trace.

Blocking hooks run the build, the vet and structural checks on every edit, so the rules can't quietly decay between sessions. Yes, it's a little over-engineered for a young product — deliberately. It buys a frame my agents can rebuild in hours on the next project, instead of ten weeks of refactoring later.