Two Weeks, No Spec: Shipping the CEO's Workflow Tool in One

This is part 8 of the Musaned series. Part 7 covered Voucher Query. This story is different: less architecture, more adrenaline.

One day the request landed: upper management needed a tool to manage business processes — tracking memos and voting on decisions — and they needed it in two weeks. The user list went all the way up to the CEO. The requirements documentation? There wasn't any. No workflow diagrams, no field lists, no sign-off criteria. Just the deadline and the expectation.

Ambiguity is the real deadline killer

Here's what I believe after that fortnight: a two-week deadline doesn't kill projects. Two weeks of building the wrong thing kills projects. With no spec, my first move wasn't code — it was extracting the shape of the workflow from the people who lived it. Not in requirement-gathering meetings (there was no time), but in short, pointed conversations: what does a memo look like today? Who sees it next? What does "approved" actually mean — one signature or five? What happens when someone disagrees?

A few hours of that beat a month of documentation, because I wasn't asking people to imagine a system. I was asking them to describe what they already did in email threads and hallway conversations. The system was already running — on paper and patience. My job was to move it into software without breaking its logic.

Ship the spine, not the octopus

The scope decision that made one-week delivery possible: build the spine of the process and nothing else. A memo enters. It circulates to the right people, in the right order. They see it, discuss it, vote. The decision is recorded, visibly and permanently. That's it — that was version one.

Every tempting extra — delegation rules, deadline escalations, statistics dashboards, template libraries — went on a list titled "after they trust it." Filament made the spine fast to build (screens, forms, and tables in days, as covered in part 2), and the identity and RBAC foundation from part 3 meant "only the right executives can see and vote on this" was configuration, not a new subsystem. This is where platform thinking pays off: the one-week miracle was only possible because the boring infrastructure already existed.

Launching to the toughest audience

Executives are an unforgiving user base — they won't file bug reports or tolerate workarounds. If the tool wastes their time once, it's dead, and its reputation with it. So the launch bar wasn't "feature-complete"; it was "never embarrassing." Everything the spine did, it did reliably, quickly, and legibly. A week after the request, the tool was live. It launched a week early — and the requests that followed came from usage, which is the best requirements document there is.

What I took from it

• Missing specs are extracted, not awaited. The workflow always exists — in inboxes and habits. Go read it.

• Scope is the only variable you fully control. Deadlines and users were fixed; the spine-only scope was my decision, and it was the one that mattered.

• Platforms buy speed when it counts. Identity, permissions, deployment — none of it was built that week, and all of it was why that week was enough.

Next in the series: inside the BPM tool — how memos, votes, and auditable decisions actually work.