How we ship every week

The studio has one operating rule: ship something every Friday. Everything else — the stack, the tools, the calendar, the things we don't do — exists in service of that rule. This post is the working version of how that actually happens, week to week.

It is not a productivity essay. There are no morning routines and no mention of which font I use in the terminal. It's a description of the unit of work, where it lives, and how it gets out the door.

The unit is a release

A "release" at Elofyn is one thing you can describe in a single sentence without conjunctions. Not "we improved the X and also fixed Y and started on Z" — that's three releases or none. One sentence, one ship.

A few real examples from recent weeks, before they became posts:

• AI Tool Radar now watches Anthropic's pricing page.
• The radar emits an RSS feed of changes from the last 24 hours.
• An 1100-word note on how to read a model card without taking it personally.

Each fits a sentence. Each is finished — not "started", not "in beta", not "rolling out". By Thursday night the release works end-to-end, and by Friday afternoon there is a journal entry that explains it in English. If a release fails the sentence test, it gets split or cut.

The week, top to bottom

Most weeks look the same. They start sparse on purpose: a busy Monday is how Friday gets missed.

Monday morning — choose the unit. I look at the backlog, pick the single release for the week, and write the sentence. The sentence goes at the top of a markdown file in the project repo, and the rest of the week is judged against it. If on Wednesday I'm tempted to add a second feature, the sentence usually tells me no.

Monday afternoon to Wednesday — make the thing. Most weeks this is straight-line code. The stack rarely changes (Next.js, TypeScript, a SQLite file, a Caddy in front of a small GCP VM), so the tooling does not get in the way. When it does, the answer is almost always to pick the boring choice and move on.

Thursday — write the post. I draft the journal entry while the release is still warm in my head. The post is part of the release, not an afterthought — a release that no one can read is not really a release, just a deployment. The post explains what the thing is, who it's for, and how to use it. If the post is hard to write, the release is usually doing too much.

Friday — ship. Merge to main, run the build, push to the VM, publish the post, send the changelog entry. The whole sequence takes under an hour on a calm week. If it takes longer, I take notes on why and try to fix that part of the pipeline before next Friday.

What we cut

The honest reason a weekly cadence works is that we cut almost everything. Friday is non-negotiable, so most of what would otherwise be a "should we…" turns into a "no, not this week."

Some specifics:

• No roadmaps. The backlog exists. It is not promised to anyone. Anything on it might never ship, and we'd rather under-promise than let a list of TODOs become an obligation to a stranger.
• No themes. A "month of accessibility improvements" feels organized; it's actually four releases that have to be the same shape, which is a trap. Better to do the one accessibility fix this week and the next one whenever it earns its slot.
• No retrospectives. A retrospective implies a sprint, and a sprint is the wrong unit. The retrospective at Elofyn is the next post — if a release was wrong, it's the next post's job to explain why.
• No estimates beyond "this week". I can tell you Friday's release with high confidence by Wednesday. I cannot tell you next month's release without lying. So we don't.

The cuts add up. Whatever's left is small enough to finish.

The mechanics

A few things that pay back in time, every week:

The build is fast. bun run build finishes in under ten seconds on a laptop, the test suite in under two. A fast loop is the difference between trying a fix and being afraid to try it. When the loop gets slow, fixing it is a release on its own.

The deploy is one command. Push the branch, the CI runs the same Playwright gate I run locally, and on green it rsyncs the build to the VM and reloads the service. There is no staging environment because the changes that would benefit from one would also fail the gate locally first.

Drafts live in the repo. Posts are MDX files alongside the code, versioned and reviewable in the same diff as the feature they ship. A release and its essay are one pull request. No CMS, no parallel write track.

Here is, roughly, the function that decides which day is "this Friday":

// elofyn ships every week — concretely.
export function thisFridayUTC(today: Date): Date {
  const day = today.getUTCDay();           // 0..6, Sunday..Saturday
  const offset = (5 - day + 7) % 7 || 7;   // always 1..7
  const friday = new Date(today);
  friday.setUTCDate(friday.getUTCDate() + offset);
  friday.setUTCHours(0, 0, 0, 0);
  return friday;
}

It's six lines and it is, somehow, the most-referenced piece of code in the studio. Every changelog timestamp, every release-tag generator, every "is this thing late?" check goes through it. The cadence shows up in the source.

Where this breaks

Two failure modes are worth naming so they don't surprise anyone later.

The week with no release. Some weeks the work doesn't reach the sentence test by Friday. When that happens, the journal gets a "no release this week, here's why" post — short, honest, no apologising. Skipping the post is a worse failure than skipping the release. The beat continues even when the music stops.

The release that turns into three. Occasionally I underestimate, ship a smaller version of the planned thing, and discover the rest is two more releases. That is not a failure — it's the cadence working. The week's release was real; next week's release is the obvious next step. The roadmap shows up in the changelog, after the fact, like it should.

The whole point

A weekly cadence isn't faster than other ways of building software. It's more honest than them. By Friday, either the thing exists or it doesn't; either you can read about it or you can't. The studio's whole posture rests on that, week to week, in print.

If a future Friday goes quiet, the studio has stopped. Until then, we will keep shipping the small thing on time, and writing the post that explains it.