We kept building features while the product was elsewhere
A month spent on lesson content rather than software revealed which half of the build anyone would actually miss. The answer was not the half we had been optimising.
Algodyne
By the second month of the study platform the software was in reasonable shape. Courses, modules, progress, filtering, an analytics view, an admin surface. It looked like a product because it had the shape of one.
Then a month went almost entirely into content — writing and rewriting explanations, restructuring modules, building mock exams question by question with the reasoning attached. Very little of it touched the application. It was the most productive month of the project.
The test that settles it
The question worth asking of any build is which half a user would notice if it vanished overnight. Remove the analytics page from a study platform and a candidate preparing for an exam next month does not notice. Remove the explanations behind the answers and there is no product at all — there is a quiz.
That test is uncomfortable because it usually indicts the work that felt most like engineering. Filtering, sorting, pagination and dashboards are satisfying to build, legible as progress, and easy to demonstrate. They are also, in this category, the part any competent team ships in a fortnight.
The work nobody wants is the work that is worth doing. That is not a moral point. It is an observation about where the return sits when the software layer has been commoditised out from under you.
Reduce surface area, never depth
The correction was not to build less. It was to build less broadly and more completely. Fewer modules, each finished to a standard we would defend, rather than a full syllabus at a quality that would need redoing.
Narrow is what makes completeness affordable. A shallow build across the whole syllabus and a complete build of a third of it cost roughly the same, and only one of them can be put in front of a real candidate and measured. The other can only be demonstrated.
This is the observation that later hardened into a rule about scope: cut the surface, hold the depth. At the time it was just the realisation that a month of unglamorous writing had moved the product further than the previous two months of features.
What it implies about tooling
If the differentiating work is content, domain reasoning, and editorial judgment, then the software around it should be as close to free as possible. Not minimal — the platform still has to be good — but not the place where scarce attention goes.
That conclusion is what eventually made shared infrastructure obviously correct rather than theoretically nice. If every venture needs a competent, unremarkable application layer, and the differentiation lives elsewhere, then building that layer once and reusing it is not an optimisation. It is the only allocation of effort that makes sense.