February 2026
The biggest challenge in the next 12 months? What NOT to build.
That was the paradox. AI made building so easy that the constraint had flipped. The hard part wasn't creating software anymore — it was deciding which software was worth creating.
The Thesis
Sometime in February 2026, I put into words something I'd been feeling for months: "Build over buy is just the future, I think."
The argument was simple but far-reaching. The big standard software packages we all know — the ERPs, the CRMs, the project management tools — were built in a world where custom software was expensive and slow. Buying was rational because building was painful.
AI changed that equation. When building is fast and cheap, the calculus flips. Why buy an inflexible package from a vendor who doesn't understand your specific needs when you can build exactly what you want in a fraction of the time?
I could see it in my own work at Context&: "I can see how flexible it is to build with AI and how fast it goes. I can see how inflexible it is when a piece of standard software enters the machinery, how complex it is to have multiple vendors coordinate because these big standard software packages typically require specialized people to work with them."
This wasn't an abstract argument. It was what I was living every day — the contrast between the agility of AI-built custom solutions and the rigidity of enterprise software packages.
The Umbraco Day
One day crystallized the thesis perfectly. I walked into the office with zero knowledge of Umbraco — a content management system I'd never worked with — and walked out that evening with a working AI assistant plugin for it.
Together with colleagues Andreas and Rune, we spent the day hacking. I brought AI coding expertise. They brought deep Umbraco knowledge. We installed Claude Code on a few laptops and started prompting.
By end of day, we had:
- A React/Vue component that integrated with Umbraco's backoffice
- An AI assistant that could help users with their Umbraco setup
- A foundation that could become a real product
Was it polished? No. Was it production-ready? Not even close. But we'd gone from zero to functional prototype in a single day, in a technology stack I didn't know that morning. That's the build-over-buy argument in action.
We couldn't decide on a name. "Umbraco Copilot?" "ContentHelper?" I joked about "Context& AiVen" and expected to get told off for it. The naming debate was more fun than the coding.
From Individual to Team
February also brought a clearer view of something I'd been noticing: the shift from individual productivity to team productivity.
I wrote a longer reflection post: "2025 was the year where many organizations had frontrunners running ahead of time and playing with AI, seeing a huge engineering boost in output. But the organization as a whole hasn't seen a significant performance boost."
The data was clear from my own experience. As an individual, I was dramatically more productive with AI. My colleagues were starting to get there. But the team as a whole? The organization? That was a different challenge entirely.
"2026 will be the year it moves from the individual to the team delivering with AI. I'm already seeing it with my colleagues as it becomes more mainstream and OK that we use the tool. More and more people are getting their magic moment and starting to use it actively."
This prediction felt solid because I was watching it happen in real time.
The 10x Developer (Now 1000x)
The "10x developer" meme had been around for decades — the idea that the best developers are 10 times more productive than average ones. I posted my updated take: "I also believe 10x devs exist — it's just 1000x now."
Provocative? Yes. But the math worked if you squinted. A developer who deeply understood AI tooling, had refined their prompts and workflows over 14 months, had built up libraries of ADRs and context files, and knew when to use which model — that developer was producing output at a rate that would have been physically impossible for any individual a year ago.
The gap between "developer who uses AI effectively" and "developer who doesn't use AI" was wider than the gap between the mythical 10x developer and a 1x developer had ever been.
Docker Volumes and Project Isolation
A technical discovery that mattered more than it sounds: using Docker volumes to maintain per-project Claude configuration.
The problem was context pollution. When you're working on multiple projects with AI, the AI's memory and context from one project could leak into another. Docker volumes let me isolate each project's AI context — its rules, its ADRs, its conversation history — keeping everything clean and project-specific.
I posted about it thinking it was a minor technical note. It turned out to be one of my more engaged posts. Developers dealing with the same problem immediately recognized the solution.
Planning Mode
One mindset shift I publicly admitted: I'd been wrong about planning.
"You have to remember to say it when you discover you've been wrong :) I've never really used planning mode, and now I can see the value."
For months, I'd been in pure "act mode" — prompt, code, ship, repeat. Planning felt like overhead, like a return to waterfall thinking. But as projects grew more complex and agents became more capable, I realized that good planning front-loaded the thinking that made agent execution reliable.
Plan mode wasn't waterfall. It was architecture. And architecture was the one thing that became more valuable as AI took over more of the implementation.
What If I Could Give You 3x?
The consulting pitch crystallized: "What if I could give you 3 times as much for your money? Shouldn't you at least consider it?"
This was the build-over-buy argument distilled to its business essence. If AI-assisted development meant I could build three custom features in the time and budget that one off-the-shelf feature used to cost, the ROI calculation for custom development changed fundamentally.
Not every client was ready to hear it. The risk aversion in enterprise IT is real and often justified. But the conversation was starting. And the proof points were accumulating.