Your Best Developers Don't Work in IT

Somewhere in your company there is a ticket like this one.

It was created in March 2023. It asks for something modest: one screen with the numbers a team looks at every week. The priority is "Medium" and has never changed. The assignee field is empty. Underneath, the person who opened it has asked three times, politely, whether it is still on the roadmap. The last of those questions was in June 2026. Nobody answered.

Meanwhile, that team rebuilds the same report by hand in a spreadsheet every Monday morning.

Nobody in this story did anything wrong. The IT department is not lazy — it is busy with things that genuinely matter more than one dashboard. The person who opened the ticket is not demanding — they just gave up. The process worked exactly as designed. That's the problem worth looking at.

The translation tax

Here is how internal software is normally created.

Someone has a need. They translate that need into a written request, converting professional knowledge into words that someone from a different profession will have to interpret. The request enters a queue, where it competes with everything else IT is responsible for — and most of that is more critical. Months later, someone who does not do that job builds a tool for people who do, based on a document written by someone who does not build software. The result is an approximation. By the time it arrives, the process it was built for has changed. And asking for a correction means starting again at step one.

Every handoff in that chain costs information. We built the chain anyway, because for fifty years there was no alternative: the person with the need couldn't build, and the person who could build didn't have the need.

That constraint no longer holds. AI-assisted development has made it realistic for a competent professional without a programming background to build working internal tools. Not every tool, and not without supervision — we'll come back to that. But the constraint that justified the whole chain is gone, and a process built around a constraint that no longer exists is just overhead.

The customer has been inside the building all along

Internal software has customers. We just don't call them that. We call them users, or "the business," as though they were a department making demands rather than the people the product exists to serve.

Look at who they actually are. They are professionals with ten or twenty years in their domain. They know their process better than anyone else in the company. They know which three numbers belong on one screen and why the fourth is noise. They know the exceptions, the edge cases, and the small daily frictions that never survive a requirements document because they sound too trivial to write down.

In commercial software, you spend enormous effort trying to understand your customer that well. In internal software, that understanding is already sitting at a desk on the second floor. For decades we have been throwing it away in translation.

Now that person can build the thing themselves. Directly. The middleman disappears — and we say that with respect, because the middleman was never the problem. The translation was.

This is not about replacing your IT department

Every time this comes up, someone hears "fire the developers." That is the wrong conclusion, and acting on it is how companies get this badly wrong.

In this model, IT does not shrink. It moves up the stack. The job stops being "write every piece of software in the company" and becomes "make it possible for everyone else to write software safely." Concretely, that means four things.

**Own the foundation.** Architecture, environments, data access, deployment, authentication. Nobody in marketing should be inventing how a tool connects to the data warehouse. Set that up properly once, and everything built on top inherits it.

**Set the boundaries.** Decide explicitly what employees may build and what they may not. Which data can be touched, what must never leave a given system, where a tool may run. Written down, not assumed.

**Review what gets built.** Not every change, but a real checkpoint before anything touches shared data or becomes load-bearing for a team's work.

**Teach.** This becomes the largest part of the role, and the most valuable. Your developers already know what good looks like. Transferring that judgment to twenty domain experts multiplies it in a way that writing the eleventh internal dashboard this quarter never will.

Honestly, that is a more interesting job than the one most internal developers have today.

What goes wrong, and how to avoid it

We would rather tell you the failure modes up front than have you discover them.

**Shadow IT with better tooling.** Roll this out with enthusiasm and no rules, and in a year you will have two hundred tools nobody knows about, touching data nobody approved. The answer is governance, set before the first tool is built — not after.

**The bus factor.** A tool built by one person is a dependency on that person. Standards, documentation and explicit ownership have to be part of the model from day one, or you are generating technical debt very efficiently.

**Building the wrong things.** Anything touching money, personal data, regulated processes or production systems stays with professionals. The useful test is not "can AI build this?" but "what happens if this is quietly wrong for three months?" If the answer is serious, it is not a candidate.

**Starting too big.** The failure pattern is a company-wide programme announced at a town hall. The pattern that works is one team, one real problem, one tool, six weeks — then show the result to everyone else.

A company that skips these will have a bad experience and conclude the whole idea doesn't work. It wasn't the idea.

How to start

If you want to test this without betting anything significant on it, the sequence is straightforward.

Pick one department with a visible backlog problem — the team with the Monday-morning spreadsheet is usually the right candidate. Choose two or three people in it who are respected by their colleagues and curious rather than technical. Have IT prepare the foundation and write down the boundaries before anyone builds anything. Let those people build one tool they personally need, with a developer available for questions and a review before it goes live. Then measure the only things that matter: did it get used, what did it replace, and how long did it take compared to the ticket it came from.

Within two months you will know whether this works in your organisation. That is a much smaller question than "should we transform how we build software," and it is answerable.

Where we come in

This is what YourLastDev does. We set up the professional architecture and the rules first — the foundation, the boundaries, the review process — and then we train the people who already have the domain knowledge to build on top of it themselves.

The name is the thesis. The goal is to be the last developer you hire for this category of work, and the first AI trainer you bring in instead.

The expert in your business is already on your payroll. They have been describing the tool they need for three years, in a ticket nobody has answered.

It is probably time to let them build it.