I built the whole thing myself

I should say up front why this issue exists eight issues in rather
than first.

Megaphone is about the economics of filling a room, and nobody
arrives at a publication like this wanting to read about the person
publishing it. But the question comes up in every conversation I have —
wait, you built all of that? — and the honest answer is more
useful than the version people assume, so here it is once, in the middle
of the run rather than at the front of it.

What exists

Roll Call is an operating system for events. Underneath it there are
seven product suites and four vertical applications, plus a consumer
discovery marketplace and a clean-energy vertical running on the same
core.

In engineering terms: roughly 180 custom database tables and close to
690 API routes across a suite of plugins. Ticketing, attendee
management, sponsor matching, a persistent attendee layer, a marketing
engine, an AI intelligence layer, and separate applications for venues,
nonprofits, associations, and retail media.

One person wrote it. Two people help part-time. Nobody has been paid
a salary out of it.

The method, plainly

I use AI as the development method, not as a feature I’m
shipping.

That distinction matters more than it sounds. Most people
encountering AI in software are talking about a chatbot bolted onto a
product. What I mean is that the process of building — architecture
decisions, schema design, writing the code, reviewing it, migrating it —
runs through AI collaboration at every step, all day, for years now.

What it actually changes: the cost of trying something. A schema
redesign that would have been a week of work I’d have avoided becomes an
afternoon I’ll do twice. The result isn’t that I write code faster in
some linear sense. It’s that I abandon bad approaches earlier, because
the sunk cost of the bad approach is so much lower.

What it doesn’t change: knowing what to build. Every hard decision in
the last two years has been a product decision, not an engineering one.
AI is extraordinary at “how do I implement this” and no help at all with
“should this exist.”

What broke

Plenty. A partial list, because the wins are less instructive.

The frontend became technical debt faster than the
backend. The data model held up remarkably well. The interface
layer accumulated a legacy JavaScript mess that eventually needed a full
migration plan — not a patch, a strangler-fig replacement done
incrementally so a live platform wouldn’t go down. That was months of
unglamorous work with nothing to show for it.

I built things nobody asked for. Several features
exist because they were interesting to build, not because a user needed
them. Building things is cheap now, which makes it easier to
waste time, not harder. The constraint moved from “can I build this” to
“should I have,” and I was slow to notice the constraint had moved.

Security had to be retrofitted. A security audit
produced a content security policy, a fix for a race condition in credit
deduction, and several other issues that should have been designed in
rather than found later. Speed of building is not speed of thinking.

Readiness became a hiding place. Everything sat
between 92 and 98 percent done for a long stretch. The last few percent
is where you have to talk to people, and I am better at building than I
am at that. It took admitting that out loud to realize the polishing had
stopped being work and started being avoidance.

What I’d tell someone
starting this

Build the backbone before the products. The reason a
second and third and fourth application were possible is that identity,
tenancy, the data spine, and the marketing engine were built once and
inherited. The first product was slow. Everything after was much faster.
If you’re building one thing, this doesn’t apply. If you suspect you’re
building several, it’s the whole game.

Being alone is a compounding cost. Not because the
work is impossible — clearly it isn’t — but because there’s nobody to
tell you that a feature is a distraction, or that you’ve been at 95% for
two months. The failure mode of a solo builder isn’t running out of
capability. It’s running out of correction.

Shipping and selling are different skills and you probably
only have one. I can build a platform. I struggle to cold-open
a conversation about it. That’s not a character flaw to fix by trying
harder; it’s a real gap that needs either a hire or a different
mechanism. Megaphone is the mechanism — an attempt to make the first
contact asynchronously, by being useful in public, so the conversation
starts warm.

Which is, roughly, why you’re reading this.

The uncomfortable part

The thing I’d most want someone in my position to hear: none of the
above matters if nobody buys it.

A large, working, technically impressive platform that no one uses is
a hobby with a database. I’ve spent long enough building that the
building became the identity, and it took a bad week and a blunt
conversation to see it clearly. The number that matters isn’t tables or
routes or suites. It’s how many people are running their events on it,
and that number is small.

So this issue is a status report, not a victory lap. The platform is
real. The proof that anyone wants it is still being gathered — some of
it, publicly, here.