In 1995, on an unpaid student placement at a Leeds teaching hospital, I co-built a Windows application to help paediatricians make decisions about asthma medication in children. The application was sold to a pharmaceutical company. We heard the figure was £20,000. My co-developer and I received £200 each, after the IT manager argued our case with the consultant who held the proceeds. The £200 was welcome. My daughter had been born a few months before the placement started. I worked at a supermarket on every day I was not at the hospital. My future wife held down two jobs. We were living on bursaries, student loans, and shifts. £200 mattered.
I tell the story because the arithmetic of how I built software in 1995 says something useful about what is happening to the same kind of software now.
What it took to ship something useful in 1995
Two students. Borland Delphi 1.0. A fat-client Windows application. A consultant who knew the question worth answering. An IT manager who put a development environment in front of us and let us go. Months of work in the gaps between paid shifts and lectures. No version control discipline anyone would recognise today. No tests. No formal user research, although the clinicians were down the corridor.
The product worked. It addressed a live clinical question about inhaled corticosteroids and growth suppression in children, written about in the Lancet the same year. The buyer had a clear commercial interest in tools quantifying the trade-offs around their products. The economics added up.
The thing about getting a clinical application built in 1995 is what it required to assemble. You needed a hospital with an IT budget, a consultant willing to sponsor the work, an IT manager who knew where to find Delphi licences, and two students prepared to fit the build around supermarket shifts because the placement itself paid nothing. The institution was the precondition. Without the institution, no software. The students were inputs to a process owned by people with seniority and a budget code.
A year later, after another year on bursaries and student loans, I got my first paid software job at JLA in Ripponden. The work was hard, the discipline was real, and the lesson from the hospital build carried straight into it. Software in the mid-1990s rewarded the people willing to put the hours in across whatever stack was in front of them, regardless of whether the hours were paid or not.
What it takes to ship something useful in 2026
Last month I built two production-grade applications for the social housing sector. One is a tenant rights and repairs companion grounded in housing legislation. The other links Ombudsman case data to provider dashboards using national address-level identifiers. Both took less than two weeks of evenings and weekends. I wrote them, end to end, working alongside Claude Code at the command line.
The arithmetic has inverted. I no longer need a hospital with an IT budget, a consultant sponsor, or an institution to grant me access to development tools. The development tools sit on my laptop. The legislation I needed to ground the tenant product in was published in the open. The address data was available under an Ordnance Survey licence. Version control, testing, architecture decisions, the data protection impact assessment, the deployment pipeline: all of these are within reach of one person with twenty-five years of cross-domain experience and a willingness to think out loud with an AI.
What did not change is the willingness to put the hours in. Both housing products were built in evenings and weekends, alongside the day job, in the same way the asthma application was built around supermarket shifts thirty years earlier. The tools removed the institutional precondition. They did not remove the requirement to do the work.
Why breadth is now the multiplier
The thing I was historically penalised for in my career, being a generalist who had touched architecture, data governance, user research, benefits management, development, and testing, has turned out to be the asset. Specialists struggle to direct AI coding sessions because they know one part of the picture deeply and have to delegate the rest. Generalists know enough about each part to ask the right next question and recognise when an answer is wrong.
In 1995, breadth was a liability. It signalled you had not committed to a discipline. The student labour market for software work expected you to specialise early and deeply, because the cost of context-switching across architecture, code, data, and testing was carried by the individual. In 2026, the AI carries the cost of switching. What it cannot do is choose which question to ask next, or know when an answer is structurally wrong rather than locally plausible. Twenty-five years of cross-domain work produced exactly the judgement needed for the choosing and the knowing. It was useless when institutions wanted specialists. It is decisive now.
This is the inversion worth taking seriously if you are a senior technical or executive reader. The breadth your organisation discounted, in hiring and promotion decisions over the last fifteen years, is now the breadth required to direct AI to ship product at the speed practitioners are starting to demonstrate. The people you have been routing around as generalists are the people who would build the product directly if they were given the room.
What this means for who builds public-sector software
If a hospital does not need an IT budget, a consultant sponsor, or two students working through supermarket shifts to build a working clinical application, who gets to build software for the public sector? And on whose terms?
For social housing, the public sector domain I work in now, the answer is changing in real time. The sector has spent years waiting for vendors and large consultancies to deliver products meeting the needs of tenants and providers. Most have been expensive, slow to arrive, and indifferent to the specifics of legislation like Awaab's Law. There is now another option: practitioners with domain experience building what is needed directly, in weeks rather than years, at a cost requiring no procurement framework to absorb.
The same shift is starting to play out across govtech, clinical software, and any sector where the gap between what users need and what vendors deliver has been wide for a long time. The economic precondition has dissolved. The remaining preconditions are domain experience, breadth, and willingness to do the work.
I built clinical software for £200 in 1995, between supermarket shifts, on borrowed evenings, because the build was worth doing and the money helped. I built two housing products for nothing in 2026, on borrowed evenings again, because the build is worth doing. The hours are the constant. What changed is the force multiplier on each hour, and the cross-domain breadth required to direct it.
The next question, for anyone running an organisation, is whether your assumptions about who builds software, how long it takes, and what it costs are still calibrated to 1995, or to 2026.