The Best First AI Project Is the One Nobody Asked For

Every engineering team has a list of internal tools they’d love to build but never will. An admin dashboard that would save the ops team hours every week. A configuration editor that currently requires someone to run raw SQL against the database. A reporting tool that three people want but no customer is paying for.

These projects sit at the bottom of the backlog because they’re not revenue-generating. No customer is clamouring for them. They’re genuinely useful, but they’ll never survive a prioritisation meeting against feature requests from paying clients.

Here’s why that backlog is your best AI adoption strategy.

The two objections you’ll hear

When you suggest that your engineering team start using AI to build software, expect pushback. It usually comes in two flavours.

The first: “It won’t work with our codebase.” This is the brownfield objection. In software engineering, a “greenfield” project is something built from scratch on clean ground. “Brownfield” is the opposite: an existing system with accumulated complexity, dependencies, and history. Engineers who’ve seen AI demos building shiny new apps from nothing assume it falls apart when faced with real-world, messy, established codebases.

The second: “It’s more trouble than it’s worth.” The assumption here is that you’ll spend more time fixing AI-generated mistakes than you would have spent writing the code yourself.

Both objections are understandable. Both are increasingly wrong. But arguing the point in the abstract won’t convince anyone. You need a practical demonstration.

Why internal tools are perfect

An internal admin tool is the ideal first AI project for several reasons.

It’s genuinely useful. This isn’t a toy demo or a proof of concept that gets shown once and then forgotten. Someone actually needs this tool, and they’ll use it daily.

It’s low-stakes. If it takes a bit longer than expected, or the first version needs refinement, nobody’s contract is at risk. There are no customer SLAs, no regulatory requirements, no board presentation riding on it.

It’s bounded. Admin tools have clear inputs and outputs. Display this data. Filter by these criteria. Edit these records. Save. The scope is naturally contained in a way that makes it manageable as a first outing.

And here’s the part that tends to surprise people: AI doesn’t just build the basic version. It builds the version you’d actually want but would never have the budget for. Type-ahead search. Server-side filtering and pagination. Drag-and-drop reordering. Data export. These are the features that normally get cut because they take a developer two days each and nobody can justify the time. With AI, they’re part of the first pass.

Better still, AI will suggest features you hadn’t thought of. Give it a clear brief and it will come back with sensible additions: things an experienced developer would recommend if they had the time to think about it, which they usually don’t.

What actually happens

I did this recently with an engineer who was openly sceptical about AI coding. Not hostile, but firmly in the “it’s more trouble than it’s worth” camp. They’d used AI autocomplete in their IDE and found it occasionally helpful, mostly annoying.

We picked an internal tool from the backlog. Something that would save the team real time but had never been prioritised. Built the whole thing in a day. Not a rough prototype. A working, tested, deployed system with features that would have taken a week or more by hand.

The reaction wasn’t “that’s clever.” It was “I didn’t know it could do this.” They’d understood that AI could write functions and suggest code completions. They hadn’t grasped that it could build systems: handle architecture decisions, write comprehensive tests, structure a codebase, and produce something genuinely production-worthy.

That shift in understanding is worth more than any slide deck or strategy document. Once someone has experienced it firsthand, the conversation changes entirely.

What to do next

Pick something from your team’s internal tools backlog. Something that’s been sitting there for months because it never wins the prioritisation argument. Give one or two engineers a day to build it with AI.

Don’t prescribe how they do it. But if they’re open to guidance, point them towards the companion article for engineers, which walks through the practical approach: how to brief the AI, how to iterate on designs, and why treating it as proper engineering produces far better results than just prompting for code.

The worst case is that they spend a day and learn something. The best case is that they build something useful and come back with a fundamentally different understanding of what’s now possible.

Either way, you’ve spent one day. Against the scale of the shift that’s happening in software development, that’s an extraordinary return on investment.

This article is part of a broader series on AI-assisted development. If you’re looking for a deeper dive into the economics, risks, and strategic implications, start there.