A SOFTWARE COMPANY, ON ONE TABLE.

Software is the most collaborative thing a small company makes, and the easiest to scatter across a chat, a wiki, a design tool, and a tracker. Marginalia keeps it on one table instead. Everyone has a place at it: a founder, an engineering lead, a designer, a product manager, the engineers, support and QA. The plan belongs to the team, not to whoever has the file open.

The best part of building software together is the thinking, done early and in the open. When the team needed the register to keep working through a dropped connection, they did not write a spec in a vacuum. They put it on a whiteboard, together, and shaped it until they all saw the same thing.

Each note is a person. Marcus's plan, June's constraint that the cashier should never even notice, Priya's gotcha about double-rings, Sam's urgency from three stores that hit it last weekend. The decision is right there on the board, next to the parking lot of what comes later. Nobody had to be in the same room.

A data model is a design decision too, so it goes on a board as well. The Stacks schema, catalog through point of sale, drawn as an entity diagram anyone on the team can open, read, and build on. Not buried in a migration file. On the table, where a new engineer learns the shape of the thing in a minute.

Every piece of Stacks starts as a vision: a page that says why it should exist before anyone builds it. A register that keeps the line moving. Every book accounted for. Readers who come back. Six of them, each a reason the work is worth doing, that a newcomer can read and the team can check the work against later.

A vision is not a slogan you forget on a wall. It carries its own refinement loops, design, build, and feedback, each driven by a real checklist. The register's design is done, the build is most of the way there, the feedback loop has barely opened. The rings are work checked off, not a status someone typed, and the design jam from earlier rides right on the same page.

Under the visions is the actual work: twenty features across seven Stacks codebases, and the work items that built them, spread over two years and the whole team, including the ones two engineers shipped before they moved on. Their work still shows on the board and on the old items. Nothing is lost when someone leaves.

All of that plan produces a real thing: Stacks, the software a bookseller actually rings a sale on. The catalog, ten thousand titles deep. The register. The day's numbers. The drawing and the built product, both on the same table, so the gap between what was meant and what shipped is always in view.

The strategy, the design jams, the data model, two years of work, the team, and the shipped product. Not scattered across a wiki nobody updates, a chat that scrolls away, a design tool only the designer opens, and a tracker that forgets the why. One plan sheet, where a new hire reads the reason, an engineer opens the design, and the owner sees what shipped. Software is the hardest thing to keep on one table. That is exactly why it belongs there.

Software is only one of the things this table holds. A sticker run, a record, a hardware build: each one starts as a why, earns a design, gets made, and ships. Stacks is the proof that even the most tangled craft, the one that loves to scatter across ten tools, fits on a single sheet.