The Week I Chose Not to Build the Feature

In a recent article I wrote about how depth of thinking now has a proportional return — that the cost of honouring careful design has shifted, and that precision pays off in ways it couldn't before.

This is what that looks like in practice.

For the last two months I've been building Flywheel — an AI-assisted operating system for Shift Advisory. It runs the full commercial cycle: capturing signals, building relationships, drafting outreach tailored to a specific client's problem, and closing with a proposal grounded in what the system has learned along the way.

Not a collection of tools. An OS. One where each stage of the cycle informs the next — and where the whole thing gets sharper the longer it runs.

Recently I identified a feature that would directly support a commercial step I want to take. The kind of step that has a cost attached to every week it doesn't happen. The feature was buildable. Nothing was broken. I could probably have shipped it this week.

But while using the system over the past two months, I kept noticing something. Every LLM call was stored as an isolated input and output — a snapshot of a single request. Clean, queryable, inspectable. And completely disconnected from what came before and after it.

That meant I couldn't continue a reasoning thread across turns. I couldn't learn from the arc of a conversation — only from individual responses. The feedback loop I had designed into the system couldn't actually close, because the data model underneath treated every call as if it happened in isolation.

There were others. The primary model was carrying too many concerns. Events were modeled as dependent entities — each one owned by the thing it described. That worked for simple state changes. It broke when LLM calls entered the picture.

An LLM call is not an event of one entity. It touches several simultaneously — the primary record, the conversation, the prompt, the context it was given. A model that forces it to belong to one of them doesn't just create inflexibility. It misrepresents what actually happened.

Shipping the feature on this foundation was possible. But it would have arrived as a lesser version of itself — without the learning the OS had accumulated, without the feedback loops that make each interaction sharper than the last. I would have hit the deadline and missed the point.

Fixing the foundation first means the feature ships with the full benefit of everything the system has learned. The choice was never speed versus quality. It was a lesser outcome sooner, or a fuller outcome shortly after.

So the real decision wasn't: build the feature or fix the architecture.

It was: do I optimise for this week, or for a system that compounds — one where the OS gets sharper over time and that sharpness translates into real commercial outcomes?

Two years ago this would barely have been a discussion. What takes a week now would have taken a month then — and a month was impossible to justify under commercial pressure.

But here is what hasn't changed: a week still feels expensive when every week without commercial traction has a cost. The trade-off pressure is the same. Only the economics of acting on it have shifted.

The principles themselves are not new. Separate concerns. Capture the right abstractions. Design around invariants. Build feedback loops that actually close. Those have always been valuable.

What changed is that acting on them is no longer economically irrational.

So I chose to spend the week fixing the foundation.

Not because architecture matters more than customers. Not because the feature doesn't matter. But because I realised I wasn't deciding about a single feature. I was deciding what the next year of features would be built on.

And if the OS is supposed to compound — if that is the whole point of building it — then the foundation is not a technical concern. It is a commercial one.