

Compressed timelines usually mean corners cut. Occasionally they mean the opposite, and it is worth understanding when.
Every client has been told that fast and good are opposites. It is usually sound advice, because fast normally means somebody skipped the testing.
But there is a version of quicker that improves the work, and it has to do with what happens in the gap between deciding something and seeing it.
You agree a direction in a meeting on Tuesday. It gets built over the following fortnight. By the time you see it, you have half forgotten the reasoning, the person who built it interpreted two things differently to how you meant them, and the fix now costs more than the original decision did.
That gap is where most quality gets lost on a project. Not through incompetence. Through the slow decay of intent across time and handovers.
Most quality is not lost in the building. It is lost in the waiting.
When you can see a decision the same day it is made, you are still holding the reasoning. You spot the misreading immediately, while it is a five minute correction rather than a fortnight of rework.
You also get to be wrong cheaply, which is the underrated one. Most good design involves building something, looking at it, and realising it is not quite right. When each cycle costs a fortnight you get one attempt and you talk yourself into it. When it costs a day you get four, and the fourth is materially better.
It does not mean skipping the thinking at the front. Discovery still takes as long as it takes, because understanding a business is not a thing that compresses. If anything we spend proportionally more time there now, because it is the part that determines whether the fast bit is aimed at the right target.
A project that arrives quickly and solves the wrong problem is worse than a slow one, not better. Speed is only a virtue once the aim is right.
When you are assessing a timeline, ask how often you will see working progress rather than how many weeks the whole thing takes. Frequent beats short. Frequent is what stops a build drifting away from what you asked for.

The bottleneck in a project was never how fast anyone could type. It was knowing which of several plausible answers was the right one.
We build on WordPress and will carry on doing it. But a lot of businesses are running an operational system on a publishing tool, and eventually it shows.
How we build has changed considerably in the last couple of years. What it costs has not, and I want to be straight about why that is.