One system I built over my career makes the point better than any argument I could write. A national recruitment platform, live in production: a semantic matching engine that pairs candidates with jobs by meaning rather than by keywords, CVs ingested automatically straight from email, four languages, payments, an installable app, a dedicated server with nightly backups.
A systems integrator would have quoted that as a full team for a year. One person built it. Me - a CEO of 25 years, not a programmer by trade, working with AI tools as my workforce. I am not telling you this to impress anyone. I am telling you because the numbers behind it change decisions you are making this year: development budgets, vendor quotes, and hiring.
The new timelines, as actually measured
These are not an optimistic consultant's estimates. They are times measured on real work, again and again.
A full screen with business logic: hours. A complete module - the CV intake pipeline from email, with every edge case - a day, maybe two. A full system in production: weeks. Not a year. Not quarters. Weeks.
What changed is not that the code went away. It is that writing the code stopped being the bottleneck. The AI writes, and I bring what it cannot: 25 years of management that know exactly what has to happen when a customer does not pay, when an exception is a bug and when it is policy, and which screen nobody actually needs. The expensive part of development was never the typing. It was the decisions.
Which is why a management background, not a technical one, is the advantage in this era. Someone who has run operations, service and finance knows which process is worth building and which is better off killed - and that is exactly the call AI will not make for you.
What this does not mean
Let me take the cheap conclusion off the table. No, this is not an argument for firing your development department. Legacy core systems, complex integrations, security, regulation - all of it still needs people who know the organization in depth. And MIT NANDA found that external tools succeed at twice the rate of internal development, so even in the new era, building everything yourself is not always the answer.
What has changed is the economics of internal systems. All the tools your development department "never gets to" year after year - a management dashboard, a report someone still assembles by hand, an internal system for operations - have moved off the "maybe next year" shelf and onto the "weeks" shelf.
And yes, I know the question a careful CEO asks next: who is accountable for quality when one person builds this fast? The discipline does not disappear, it changes shape. That recruitment platform goes through security reviews, backs up every night, and deploys in a way that does not take the site down in the middle of a working day. The difference is that the controls themselves now take hours to build, not months. Speed without discipline is a gamble. Speed with discipline is an advantage.
Three implications for your decisions
First, the backlog. Pull up the list of internal projects that were shelved because "there is no budget for it". Every one of them was priced on the old development economics. Much of that list can be built today in a tenth of the time, which means the priorities you set are no longer the right ones. The most profitable meeting you hold this month is a second pass over the "deferred" list with 2026 eyes.
Second, pilots. When a working system takes weeks, there is no reason to accept a feasibility deck as the output of a pilot. Ask for a live system running on your own data. A vendor or a consultant who needs a quarter to produce a demo is still working in the old economics, and you are paying the difference.
Third, quotes. Once you know that a screen costs hours and a module costs days, a quote for six months of development reads differently. Not every such quote is padded - real integration takes real time - but you now have a basis for the conversation: ask for a breakdown by screens and modules, and hold it against the timelines above.
The question for your head of development
Not as a provocation, but as a fair question between managers. How much of the team's time goes into new code, and how much into maintenance and meetings? How long does it take from a defined business need to a working screen? And are your developers working with AI tools at the level their own employees already work at home - in a country that leads the world in personal AI adoption according to the Anthropic index, at 4.9 times the expected rate?
If the answers are embarrassing, the problem is almost never the people. It is that the organization has not updated its processes to the new development economics. And unlike most problems that land on a CEO's desk, this one is quick to fix - no revolution, nothing taken apart. It starts with one small proof that shows everyone what is possible.
So here is my offer, as plainly as I can put it: pick one internal process that hurts - a report built by hand, a form that circulates by email, a small system everyone has been waiting two years for. Send it to me and I will come back with a working demo. In weeks? No. In days.
