Why six weeks, and when it is the wrong answer

Six weeks is the number on our homepage, so it is worth being precise about what it means.

It is a real delivery window for a scoped project that a traditional team would size at four to six months. It is not a claim that every project is a six-week project, and the moment it gets sold that way it stops being useful to anybody.

Look at what we have actually shipped and the range is wider than the headline. Ammpli took seven weeks. ContentMorph took eight. NewsletterJet took nine. Partic took sixteen and Matrix took twenty-two. Every one of those beat what the same scope would have cost a conventional team, and only two of them are near the number we lead with.

Where the time actually goes

Take a twenty-six week estimate apart and the build is rarely the largest piece.

Scoping and approval. Four to eight weeks in most organisations, almost none of it spent thinking.
Environment and access setup. Two to four weeks, repeated per project.
Integration scaffolding. A large fraction of the build, and the most mechanical part of it.
Test coverage. Usually the thing that gets cut, and the reason the last three weeks slip.
The actual novel work. Often three or four weeks.

The novel work is the part that needs experienced human judgement. Almost everything around it is either organisational latency or mechanical production. Those are the two things we attack.

Matrix is the clearest illustration. It connects to Salesforce, HubSpot, Stripe, NetSuite, Postgres, MySQL, MongoDB, Snowflake, BigQuery, Redshift, S3, Drive and SharePoint, plus a per-customer internal API surface. Written by hand, that connector layer is most of a year on its own. Generated against a specification and corrected by engineers, it stopped being the schedule. What remained as the schedule was the query planner, the access-control model and the evaluation harness, which is exactly as it should be.

What we compress, and how

Scoping runs in days because an engineer is in the room from the first conversation rather than after the proposal is signed. Environment setup is close to free because it is a standing capability, not a per-client build. Integration scaffolding and test generation are agent work with human correction, which is roughly an order of magnitude faster than writing them by hand and considerably more thorough.

What we do not compress is architecture, failure semantics, and the judgement calls about what to leave out. Those still take as long as they take, and trying to speed them up is how you get a system that demos beautifully and pages at 3am.

Weekly is the number that does the work

The six-week claim is a marketing number. The weekly cadence is the operational one, and it is what actually protects a date.

On Outra we shipped to the analyst team every week from week two. They were the domain experts and the end users at the same time, which meant the specification written in week one was wrong in ways only they could see. Roughly a third of what eventually shipped was not in that original scope, and it displaced things that were. Eleven weeks of their feedback was worth more than any amount of up-front analysis.

That is only possible because working software arrives weekly. A project that reveals itself at a milestone review in month three has one chance to be right.

When six weeks is the wrong answer

Three conditions make us say no to a compressed fixed-price window:

The scope is genuinely unknown. If nobody can describe the current system, characterising it is the project. Do that first, as a managed team, then talk about dates.
The decisions have not been made. No delivery method survives a client who cannot say which of two options they want. Speed makes this worse, not better; you arrive at the decision point sooner.
The constraint is not engineering. If the real bottleneck is procurement, a regulator, or a third party's release calendar, then delivering in six weeks buys you nothing except an idle team.

We would rather lose the fixed-price conversation and win a managed-team one than agree to a date that only holds if nothing surprises anyone. For those cases we run three and six-month engagements instead, with the loop and the weekly cadence intact and the scope allowed to move.

The number that matters more

Six weeks is the headline. The number we actually watch is how much of the delivery a client's own engineers can run when we leave. A six-week project that produces a system nobody in-house understands is a twelve-month problem with a good launch party.