Designing for API-First From Day One

I started NOGnet because I kept watching event organizers cobble together four different tools to run one meeting: a survey form for talk submissions, a spreadsheet for sponsor invoices, an ad hoc Slack channel for the program committee, a Doodle poll nobody trusts anymore. The obvious move was one platform that replaces all of it. I didn't build that. I built one platform, but built it so no NOG has to install the whole thing to get anything out of it.

Every module, profiles, the meeting tool, sponsor support, program-committee workflows, has to work as something you can pull out and bolt onto whatever a NOG already runs. Most operator groups already have a website, usually old, maintained by whoever on the mailing list had the patience that year. Asking them to migrate their whole online presence for a slightly better sponsor dashboard is a big ask for a small win. So each module exposes itself as an API plus a set of embeddable pieces, and a NOG can take just the meeting scheduler and ignore everything else.

Why I'd rather be a spare part

The reasoning is simple, if a little deflating to say out loud: unused software is worthless, and half-adopted software isn't much better. Offer a monolith and a NOG has to choose between replacing everything or using nothing. Most will pick nothing, which is the sane call on their end. Nobody wants to bet their community's only public presence on a side project one guy runs after hours. Asking someone to embed a single widget for sponsor logos is a much smaller ask. Getting used piece by piece across a few NOGs is realistic. Getting adopted wholesale by anyone is not, and I made peace with that early.

Designing for that costs more than it looks like it should. Mid-feature, it's tempting to reach for a shortcut that only works if you assume the whole app is running underneath it, like a shared session object, or a frontend component that quietly expects three other components to already be mounted on the page. Every shortcut like that is a tax you're deferring, and the interest is not kind. I've ripped out a "temporary" cross-module dependency in the meeting tool more than once, telling myself I'd clean it up before extraction got necessary, and then it got necessary sooner than planned.

The actual discipline is unglamorous. Each module owns its own data model. Each one talks to the outside world through a documented API, even when the outside world is just another module I wrote last month. Each ships with an embed path that assumes zero trust in the host page's CSS or JavaScript, because the host page is probably a fifteen-year-old WordPress theme and I don't get to complain about that. I version the API even though I'm the only consumer right now, because in six months I won't remember what I meant either.

The tax on being solo

None of this is free. A monolith builds faster when you're one person. Skip the API contract, skip the embed sandboxing, skip writing docs for an audience of nobody yet, and the feature ships today instead of in three days. I'd guess, with no real data behind it, that building modules this way adds a meaningful chunk of time up front compared to wiring features straight into a shared app. Some evenings that feels like a bad trade, especially when a NOG asks for something small and I know I could hack it in directly in an hour.

I keep doing it anyway, because platforms that bet everything on full adoption tend to end up with one or two committed users and nowhere else to go. I'd rather have the sponsor widget running on a handful of NOG sites than own the whole stack on exactly one. Whether that bet pays off, I won't know for a while yet. Ask me again once a few more NOGs have actually tried embedding something.