What I Learned Shipping AgentsUp — and Shutting It Down

AgentsUp was a marketplace for AI agents. The idea was straightforward: instead of hiring a person for a repeatable task — QA testing, writing a requirements document — you'd hire an agent to do it.

We built it on Django and Next.js and ran it from November 2024 to September 2025. Then we shut it down.

The idea wasn't the problem

I still think the premise holds. Plenty of work is well-specified, repetitive, and doesn't need a human in the loop for every run. That's a real gap.

What killed us was everything we built around that premise.

We optimized for a marketplace we didn't have yet

A marketplace has two sides, and we built for both before either existed. Agent publishing flows. Ratings. Discovery and search. Payout logic. Categories for agents nobody had listed yet.

Every one of those was a defensible decision on its own. Together they meant that on the day we launched, the surface area was enormous and the number of actual agents was small. We'd built the mall before we had the shops.

The tell was in our own velocity. Shipping any change meant touching the publishing flow, the discovery layer, and the billing path. A feature that should have taken a day took a week, because the system had too many things that had to stay true at once.

Complexity compounds quietly

Nobody makes a single decision that ruins a codebase. You make forty reasonable ones, and the fortieth is the one where you realize you can't move anymore.

Looking back, the moments that hurt most were the ones where we said "we'll need this eventually, so let's build it properly now." Almost none of those eventualities arrived. What arrived instead was the maintenance cost of code serving a future that never showed up.

If I'd cut the marketplace mechanics entirely and shipped a single agent that did one job well, we'd have learned more in a month than we did in ten.

What I do differently now

Ship the narrow version first. Not the MVP-in-name-only that still has five subsystems — the genuinely narrow one. One agent. One task. One user type.

Let the second use case justify the abstraction. The first time you need something, write it inline. The second time, you'll actually know what the shared shape is. Guessing at it the first time is how you get abstractions that fit nothing.

Watch your own shipping speed as a signal. When small changes start taking days, that's the system telling you it's overbuilt. I noticed this on AgentsUp months before I acted on it.

Decide what you're not building, in writing. Ambiguity about scope resolves toward more, every time, unless you've written down that you're not doing it.

Was it worth it?

Yes — though I'd have preferred learning it cheaper.

We built something real, put it in front of people, and got a clear answer. The answer was no, and the reason was our own doing rather than the market's. That's the more useful kind of failure, because it's the kind you can actually correct for next time.

I'm applying most of this directly to Seenable AI: one input, one obvious output, and a deliberately short list of things it refuses to do.

We learn, and we move.