What Comes Next

I do not think this thinking is finished, and I would be suspicious of it if it ever claimed to be. The whole idea began by questioning inherited assumptions. Turning it into a set of unquestionable assumptions would be a particularly efficient way to miss the point.

What I am increasingly confident about is the shift underneath it. Software creation is becoming abundant. That does not make software unimportant. It changes where value sits.

The scarce capability is moving upstream into judgement, noticing the right friction, understanding the real work, choosing the smallest sensible intervention and knowing when the little thing has earned the right to become a big thing.

As I build a company around this work, it has to remember the same lesson. The valuable thing is not the visible output, whether that is an app, a prototype or an impressive bit of AI. It is the judgement that came before it, the ability to notice the right friction, ask the next question and know when the best answer is not software at all.

What compounds is accumulated understanding. Every piece of work should leave behind patterns, questions, mistakes and decisions that make the next one better. Over time that becomes a kind of memory, not a library of code to copy blindly, but a library of shapes I learn to recognise sooner.

A booking, something in the middle and an invoice. A signal that needs to become a prompt. A manual reconciliation that exists because two systems never quite meet. A report that survives because nobody has asked what decision it changes.

The patterns compound and, more importantly, the judgement compounds with them. That matters to me far more than accumulating a catalogue of things I happened to build.

If other people eventually work this way with me, the test I care about is less about what they can build and more about what they notice. The day somebody hears a problem and thinks not 'I know the answer' but 'I know the next question' is probably the day they have really understood it.

And if the best answer is no software at all, they should be delighted. Possibly slightly disappointed for ten seconds, because building things is fun. Then delighted.

I also think the approach has to remain slightly suspicious of itself. The moment it becomes a brand with a preferred answer, it risks repeating the mistake it was created to challenge. If I ever walk into an organisation looking for an AI build before I understand the work, I have failed. If I go looking for a problem that justifies a product I already want to sell, I have failed in a more commercially impressive way, but failed all the same.

The same thing has to remain true when somebody pays us to do this work. Sometimes the valuable outcome will be a prototype. Sometimes it will be a recommendation to buy something mature. Sometimes it will be a process crossed out on a whiteboard and everyone wondering why they had been doing it for six years. I would rather be paid for reaching the right conclusion than for manufacturing more software simply because software is what I happen to know how to make.

What I hope compounds is not a pile of applications but a better ability to recognise those moments. The adventure centre makes the mechanic easier to understand. The forecasting mistake changes the next forecasting conversation. TableTalk changes how I think about pilots, evidence and graduation. The build that loses to a supplier changes how I approach the next procurement. Nothing needs to be wasted if the learning travels.

That is why I am comfortable calling this the full story so far while knowing perfectly well that it is not finished. The thinking should keep being tested against work, contradicted by people who know more than I do and adjusted when the evidence says I have become too fond of my own ideas. A philosophy about learning cheaply should probably be capable of learning too.