Ship in weeks, not quarters

A new client asks, almost every time, how long a first version will take. The honest answer used to be a quarter, maybe two, and most of that time went to things that had nothing to do with whether the software actually worked. We’ve cut that down to weeks, and it’s worth explaining what actually changed, because it isn’t just that we type faster.

Small scope, on purpose

The biggest lever isn’t the model. It’s scoping the first version down to the smallest thing that actually tests the real question: will people use this, does the workflow hold up, does the number we’re trying to move actually move. Everything that isn’t load-bearing for that question waits for version two. This was always good practice. It’s just easier to follow now that building the small version doesn’t feel like a waste of a big effort.

Where the model buys back time

Inside that small scope, the model drafts fast: the CRUD screens, the first pass of an API integration, the boilerplate around auth and forms that every project needs and nobody enjoys writing. None of that is where the real thinking happens, so speeding it up doesn’t cost us anything. It buys back days we used to spend on setup, and we spend those days instead on the one or two decisions that actually decide whether the project works.

What doesn’t get faster

Talking to the people who’ll actually use the thing doesn’t get faster, and we don’t let it. A prototype in week two still needs someone real to react to it, and that reaction still takes however long it takes for a person to form an honest opinion. Testing the ugly edge cases doesn’t get faster either. If anything we do more of it, because the time the model buys back goes straight into testing instead of getting absorbed into more features.

What a client should actually expect

A working first version in weeks, not a finished product. Something real enough to react to, narrow enough that we can rebuild the wrong parts without losing months. We’d rather ship something small that’s honest about what it is than something broad that pretends to be finished. The broad version always turns out to have the wrong two decisions baked in, and by then they’re expensive to unmake.

Weeks instead of quarters isn’t a speed trick. It’s what happens when the boring parts of building software stop taking most of the time, and the parts that require an actual decision get the time they were always supposed to have.