I built terminal by myself. Not as a philosophy. It was the fastest way to find out whether the idea worked, and nobody had to be convinced of anything before it existed.
That was the right call for a first version. It is a bad shape for anything that has to last.
What is the risk in a one-person system?
The same thing that makes it fast. A system with one carrier holds its context in one head: the schema, and the reasons a decision looked obvious at the time. Documentation is always one step behind the thing it describes.
That is not hypothetical, and it belongs on the risk register rather than in the small print. Capability and dependency are the same sentence, not two.
The exits that do not work
Working more hours. Moves the ceiling by maybe twenty per cent and moves the risk not at all.
Writing more documentation. Better, still insufficient. Documentation captures what a system does. It does not capture why an alternative was rejected, which is exactly what someone needs when they have to make the next decision.
Hiring. Correct in principle and slower than it sounds. A second person needs the domain knowledge that took five years to accumulate, and the onboarding happens while the system keeps running.
The exit that does
Systematising the approach rather than the output. Not "here is how the platform works" but "here is how I decide what to build, in what order, and what I refuse to do."
Reconnaissance before building. Two instances, one plans and one executes. A named go for every irreversible action. A database that enforces integrity and nothing else. Measurement through logging rather than restriction.
Those rules transfer in an afternoon. The system they produced took ten months.
Which is why the team matters more than the build
Day to day I lead a marketing team of five and direct several agencies, and that is the part of the work that scales. terminal was a proof, not a template.
I tell other companies that the people who should build their AI already work for them. I first had to learn that about myself. The domain knowledge is the expensive part, and it is already in the building. The method is the cheap part, and it can be taught. Getting that the wrong way round is how you end up with a single point of failure, whether that point is a consultant or yourself.
What holding that responsibly looks like, concretely and not as a promise, is in the two decisions that made this possible.