Live report: at this speed, you don't theorize. You eliminate.

From April 15 to April 30. Two weeks. Solo. Plus an AI.

This is a live report — not a retrospective.

The earlier posts in this series have been about shape: the contract, the pattern, the twenty-four years of building alone. This one is about what happens when an AI is added to that shape and the speed changes.

I'm writing this while still inside it. The shape held. The speed didn't.

What I built

Two weeks. One person. Here's the list, flat and unromantic:

API gateway: Zuplo, five services unified behind one public API
Custom domains: gw.ldxhub.io for production, gw.portal.ldxhub.io for the developer portal
DevPortal: API reference auto-generated, plus introduction, per-service guides, pricing, MCP setup, "use anywhere"
Auth: Auth0 with Google OAuth, GitHub OAuth, and email — sign-up to first call in roughly thirty seconds
Free tier: 25,000 credits per month, no credit card required
Billing: a unified credit system, $0.0001 per credit, four plans (Free, Starter $15, Standard $50, Pro $150), overage billed at the same rate
Stripe integration: connected for paid plan subscriptions and overage settlement
Async metering pipeline: a separate path that fires credit consumption after a job finishes (minutes or longer after 202 Accepted), batched to the gateway's billing API
Five services published: StructFlow, RefineLoop, RenderOCR, CastDoc, ExtractDoc
Four channels integrated: n8n nodes (verified, on the marketplace), Dify plugin (verified, multilingual), MCP for AI assistants like Claude Desktop, plus the direct API
Marketing pages: four product pages on the corporate LP (ldxlab.io/ldxhub, plus per-service pages), each linking to the developer portal
Eight scheduled articles on dev.to and Zenn, covering the design philosophy. This one is article five.

That's the surface. None of it is glamorous. All of it had to be done.

The shape held

The shape from the earlier posts didn't change.

Jobs go in. The API holds the work. The API retries through whatever needs retrying. The API reports when there's a real result to report. The same shape that ran the music platform in 2003 and the e-book platform from 2006 to 2014, now wrapping a structured-extraction service and four others.

What changed was the speed within it.

What sped up, what didn't

Sped up:

API design iteration — every interface lived through three or four shapes before settling
Documentation in four languages (English, Japanese, Chinese, Portuguese) — because the marketplace plugins required it and there was no time to do it sequentially
Edge-case verbalization — "what happens if the input is missing both inputs and file_id?" — answered in writing the same hour the question came up
Marketplace plugin onboarding (n8n, Dify) — submission, review, version bumps
Migrations, fixtures, sanity checks

Didn't change:

Decisions about the billing structure
Where to draw the integration boundary (which engines, which surfaces)
What to ship and what to skip
What stays in the legacy internal API and what becomes a public service

The AI didn't replace judgment. It replaced most of the typing.

(Most. The wrappers that bridge the public services to the legacy internal API — those I typed myself. They were small, they were boring, and they were exactly the shape I had in my head from twenty-four years of doing this. Faster to type than to explain.)

What was hardest

The piece I almost gave up on was the credit metering for async jobs.

Most API gateways meter on the request — easy. What I needed was: meter when the job finishes, which is minutes (or much longer) after the request returns 202 Accepted.

I evaluated two gateways. Both could do async reporting on paper. The first one I took all the way through — the API was there, the docs were there, but the UI and the operational behavior had a rough edge to it that I couldn't quite ignore. I wanted the second one. So I went back.

The second gateway was where I wanted to land. But when I got there, I wasn't sure whether the async metering I needed was actually possible. The documentation was thin in exactly that spot. I tried their support bot. The bot didn't know either. Then a human came on, and the human walked me through how to fire metering events from the job-completion side, batched.

It worked.

That's the only piece of this build where I didn't know whether it was possible until someone on the other side confirmed it was. I want to remember that. Twenty-four years of building alone, and the fastest path through this particular unknown wasn't to figure it out alone — it was to ask, and to have the other side answer well.

(There was also a smaller stumble with Stripe. I assumed I'd need to configure something on the Stripe side to make the gateway's billing flow work. I spent a while looking for that something. There wasn't one. The gateway handled it end-to-end and Stripe just received what it received. Sometimes the answer to "how do I integrate this?" is "you already did.")

The decision volume

This is the part that surprised me.

The output increased dramatically. I expected that. What I didn't expect: the volume of decisions and branches multiplied with it. Each one had to be closed individually — there's no way around that. Closing each decision was also faster, so none of them became the bottleneck.

But the fatigue is different.

I've been building things alone for twenty-four years. I know what tired feels like. This is something else. The speed compresses everything — the questions, the answers, the small course corrections — into a window where nothing has time to settle. You're never in a phase. You're always at the seam.

Here's something I didn't expect from twenty-four years of solo work: I never used to worry about missing a branch. The volume of decisions was always within what one head could hold. Now, with the output multiplied, there's a new fear — that something I should have considered slipped past while I was closing five other things. The path keeps moving and the adjacent branches keep widening, and I want to see them all before I commit. That fear didn't exist before. It's not crippling. It's just present.

I don't have a clean answer for what to do about that. I'm reporting it because it seems important and it isn't in the AI-tooling articles I've read.

Elimination, not theory

Here's the part I want to keep.

At this speed, you don't theorize. You eliminate.

There isn't time to model out every option, weigh tradeoffs in a meeting, or build a deck. You hold a thing in your hand for an hour, see whether it survives contact with the next thing, and either keep it or remove it. What survives is what you didn't have time to argue with.

This isn't a productivity claim. It's a description.

When the friction is low enough — when typing is no longer the rate-limiter — the way decisions get made shifts. They get made by elimination, by what a thing fails to support, rather than by what a thing might enable. The negative case becomes louder than the positive case. You stop asking "what if we add this?" and start asking "what does this make it harder to remove later?"

I don't know if this generalizes. I know it's what happened in these two weeks.