Design for N, ship for 1

The principle: build the seam that lets a system extend to many cases, but implement and ship only the one case you need today. The extension stays a config change later, not a rewrite. Most systems fail the opposite way. They either hard-code the single case, so the second one forces a rewrite, or they over-build an abstraction for cases that never arrive.

Two systems I shipped run on this rule. Here is what it looks like in production, with numbers.

A brand-attribution pipeline that stayed cheap while it stayed correct

A brand-intelligence mobile app had to attribute every social post to the right brand from a single raw, unfiltered stream. The obvious correct approach, a wide groupBy over dirty upstream identities, was expensive enough to drain the very stream it read from. Accurate or cheap was easy; accurate and cheap on live data was the job.

The shipped design routes each message by the prefix of a per-message tag into a role bucket (own brand, competitor, topic) instead of paying for a heavy groupBy. The part that matters for N: when the routing map is empty, the pipeline falls back to the legacy path, so the feature opens behind a config flag and is fully backward compatible. One pull attributed 3,725 posts at 99% accuracy and computed about 16.7M in total reach; a live probe measured prefix attribution at 97%, with roughly 600 backend tests green. The new routing shipped without a rewrite and without breaking the path already in production.

That is design for N, ship for 1: the prefix router can carry many routing rules, but it went live with one, behind a flag, with the old behavior one config value away.

One event stream behind two protocols

KickForge is a developer toolkit for the Kick live-streaming platform. The platform splits reading and writing across two different protocols: chat arrives over a Pusher WebSocket, while sending a message needs a user token from OAuth 2.1 with PKCE over REST. A working bot has to speak both at once and, ideally, hide that from the person building on top.

The design unifies both protocols behind a shared EventBus. Reads connect out to the Pusher WebSocket, writes go through the OAuth PKCE exchange, and both publish to and consume from one bus, so a library consumer sees a single stream of events and never learns that reads and writes travel different paths. Because the read side dials out instead of waiting on inbound webhooks, there is no webhook server and no public URL to expose: the whole setup collapses to a pip install plus an auth command, about two minutes to a running bot in three steps. It ships as five modular packages (core, bot, clip, gsi, overlay) under one PyPI package, v0.3.0 live.

The EventBus is the N seam. Today it carries Kick's two protocols and five packages; the same shape extends to another platform or another event source without the consumers on top changing.

The common move

Both systems put the variability behind one seam and shipped a single path through it:

• A routing or dispatch point (the prefix router, the EventBus) where new cases plug in as data or new publishers, not as new branches through the core.
• A safe default: an empty routing map falls back to legacy, a new protocol is just another publisher on the bus. The system degrades to what already worked.
• One path built and tested now. N is designed for, not built. No speculative abstraction waits for cases that never come.

The difference between a demo and a system

The gap between a prototype and a system that survives contact with production is mostly this discipline. A prototype hard-codes case 1, case 2 triggers a rewrite, and the rewrite is where correctness and uptime go to die. Over-engineering fails the other way, spending weeks on an abstraction for imagined cases while the one real case ships late and buggy.

Design for N, ship for 1 is the middle path a buyer is actually paying for: today's feature lands correct, cheap, and on time, and next quarter's feature is a config change instead of an incident. That is the difference between code that demos and a system that holds up under real constraints: real money, real time, real stakes.