In my last post I argued that AI is an amplifier, not a brain. That it works best when paired with people who already know how to think, structure and judge. I still believe that.

But there's a follow-on that I didn't get to, and it's been nagging at me since.

If AI makes it genuinely quick to build functional software — not toy demos, but actual working tools — then something changes for small teams. Something that matters.

They may be able to stop buying software that was built for everyone.

The generalisation tax

Most of the software small teams use was never designed for them. It was designed for a market. That's a different thing.

A project tracker built for a market has to support every possible workflow: scrum, kanban, waterfall, some hybrid nobody asked for, and a settings page with forty toggles. A reporting tool built for a market has to cover every possible data shape, which means it covers none of them particularly well. A holiday-booking system built for a market has to handle shift patterns, regional leave policies, and approval chains six levels deep.

If you're a team of eight people who just need to see who's off next week, that's a lot of weight to carry.

I've worked in large studios where the tooling bill ran into hundreds of thousands a year, and half the conversations about those tools were about working around them. Not with them. Around them. Custom fields nobody used. Integrations that almost worked. Dashboards that answered questions nobody was asking.

The pitch is always that it "does everything". The reality, in my experience, is that it doesn't quite do what teams actually need, so they either work around it or change the way they work to fit the tool.

What's changed

The bottleneck used to be implementation; more and more, it's understanding what you actually need.

The reason this matters now is that AI has collapsed the cost of building simple, purpose-built software.

I don't mean the kind of software that needs a team of engineers and a six-month roadmap. I mean the kind of tool that solves one specific problem for one specific group of people:

These aren't complex systems. They're the kind of thing that a person with domain knowledge and access to AI can build in an afternoon. Not a developer. A person who understands the problem.

That's the shift as I see it: the bottleneck used to be implementation; more and more, it's understanding what you actually need.

I've been doing this

The hard part was never the code. The hard part was the thinking.

I should be specific, because I'm wary of writing about this in the abstract.

Over the past few months, while running my job search and thinking about how I work, I've built several small tools for myself:

None of these took more than a few hours. None of them required me to write code from scratch. What they did require was knowing why I was building them in the first place, what "good enough" looked like, and being able to describe the problem clearly enough that AI could help me build the solution.

That's the bit that often gets lost in the conversation about AI and tooling. The interesting difficulty isn't just writing code; it's deciding what to build, why it matters, and how it should behave.

Why this matters for small teams

Now there's a third option: build exactly what you need.

Large companies can afford to buy Jira and spend six months customising it. They can hire consultants to configure a CRM. They can absorb the cost of tools that do too much, because they have the budget and the headcount to manage the overhead.

Small teams can't. And until recently, they had two choices: use the bloated tool and live with the friction, or go without and manage everything in spreadsheets and email. In big organisations, those small teams still have to feed data into the official systems, and that won't change. What can change is how they work day to day. They can build tools that fit them, as long as those tools can produce the data the larger, enterprise-grade stack expects.

Now there's a third option: build exactly what you need.

A team lead who understands how their team works can sit down with AI and produce a working tool that fits their process. Not a prototype. Not a wireframe. A thing people can use the next day.

This isn't about replacing developers. Developers build systems that need to scale, integrate, handle edge cases and survive contact with thousands of users. That work isn't going anywhere.

This is about the long tail of internal tools that were never worth hiring a developer for, but were always worth having. The tools that sat in the gap between "we need something" and "we can't justify the cost".

AI has, in many cases, closed that gap.

The person who matters

The people who quietly built the spreadsheet everyone actually uses now have a much higher ceiling.

I think there's a role emerging here that doesn't have a job title yet. It's the person in a team who:

That person isn't necessarily technical. They're domain-literate. They know what the team needs because they live in it every day. AI handles the implementation. They handle the thinking.

In my experience, this person has always existed in teams. They're the one who builds the spreadsheet everyone actually uses. The one who creates the shared doc that becomes the real source of truth. The one who quietly solves problems that the official tools make harder.

The difference now is that their ceiling is higher. Instead of a clever spreadsheet, they can build a proper tool. Instead of a workaround, they can build the thing that should have existed in the first place.

The catch

At team scale these tools are hugely useful; at enterprise scale you still need proper engineering, security and governance.

I should be honest about the limits.

These tools are small and specific. They don't scale to hundreds of users. They don't have enterprise security. They won't replace your CRM or your finance system. At team scale these are hugely useful; at enterprise scale you still need proper engineering, security and governance.

They also need someone who genuinely understands the problem. AI is very good at building what you describe. It is not good at figuring out what you should have described instead. If your process is unclear, AI will faithfully build you a tool for an unclear process.

And there's a maintenance question. Software that nobody maintains eventually breaks or becomes stale. If the person who built it leaves, does the tool go with them?

These are real considerations. But they apply to spreadsheets and shared docs too, and nobody treats those as reasons not to build them.

What I think this means

I think we're at the start of a shift where small teams become more capable, not by buying bigger software, but by building smaller software that actually fits.

That's true inside large organisations, where teams can work in a way that suits them while still feeding data into the official systems. It's also true for early-stage startups, which can move faster and carry less tooling overhead at the beginning by building just enough of what they need, instead of adopting heavyweight platforms too early.

The companies selling generalised tools aren't going to disappear. But their grip on teams who only ever needed 10% of the features might loosen. And the people who can bridge the gap between "what we need" and "what AI can build" are going to become quietly indispensable.

That's not really a prediction about technology. It's a prediction about people. The same kind of people who were always good at this. The ones who understood the problem, cared about the team, and built things that worked.

They just have better tools now.