The long bill for cheap software

AT A previous company where I ran the IT department, a colleague built more than 200 applications on a low-code platform. It was an impressive feat of citizen development, but his transfer to another unit left my team responsible for the applications without the resources to support them. The applications collected private employee data, which was stored in multiple locations without a record of where it was kept. Several applications also performed similar functions, so we had to untangle the duplication and track down the data and clean it up. The applications had been easier to create than to inherit. I think about that experience when I hear how easily we can now build software with artificial intelligence. I can see the appeal. If you have spent months waiting for a small improvement to a system you use daily, being able to make it yourself is liberating.

The commitment needed

But once people depend on what you have built, you have made a commitment that extends well beyond getting it to work. We have been here before. Gartner is widely credited with coining “citizen developer” in 2009, a term that became associated with low-code and no-code platforms.

These let people assemble applications using visual tools and ready-made components, bringing development closer to the people who understood the work. Gartner warned even then that some applications needed formal IT management. Its September 2026 guidance on AI citizen development returns to ownership and support after launch. Seventeen years later, we are still working out who inherits the keys. With AI, you can take a more direct route from describing a problem to having something to try. Suppose you run a sales team and want an application to track renewals. By the afternoon, a coding tool has produced something that imports your spreadsheet, flags approaching renewals and drafts reminders. By Friday, your team is using it. A useful idea has escaped the backlog and acquired a login screen. Then finance asks why your renewal figures differ from theirs. Your tracker includes customers who have agreed to renew, while finance’s contract report includes only signed agreements. Both figures may be useful, but they measure different things. Before asking AI to change the calculation, someone must agree what the dashboard is supposed to show. Once you have resolved that, the application might serve you well for a year. Then your company introduces usage-based pricing, enters a market with a different currency or acquires a business with different contract terms.

Your tracker still performs its original calculations perfectly, yet gives you an increasingly incomplete picture. Nothing has broken, but the software needs to change. Meanwhile, the world around it has been moving too. Your accounting provider might change how other software connects to its service, or new data-handling requirements might affect what you can retain.

Keeping the application useful means revisiting decisions that were perfectly sensible when you made them. Of course, AI can help make these changes too. But someone must decide which changes the business needs, understand what happens to existing records, and check the results. That is the work I would budget for, along with repairs. Each revision also needs checking for security, however quickly the code arrives. In security firm Veracode’s 2026 tests, roughly 44 per cent of AI code-generation tasks introduced a security flaw.

The figure describes tested tasks, rather than deployed business applications, but it shows why seeing your application run successfully is only the beginning of establishing that it is safe. Taken together, these demands explain why the business team benefiting from an application needs to help direct and fund its future. IT can work out how to change the system, but sales must explain how its new contracts should work. Forwarding the application to IT does not forward that knowledge, however many senior managers you copy into the e-mail. That still leaves plenty of room to experiment. A temporary tool that reformats a file needs less scrutiny than a system recording promises to customers. The useful questions are who depends on it and what happens if it gets something wrong. An afternoon’s coding can create years of obligations, so the build time is a poor guide to the responsibility involved. For me, the useful test is whether my colleagues’ working week improves. Replacing three spreadsheets and removing a weekly meeting sound promising. Saving five minutes on data entry while adding an hour of Friday reconciliation leaves them with more work. That means understanding the whole process before declaring a saving. Talking to the people using the application about that work also helps you decide what to change next. They may need fewer steps, clearer figures or one shared application to replace several duplicates. Continual evolution can mean removing features and closing applications, especially as you learn which tools people actually use. For those decisions to lead anywhere, the application needs an owner with time and resources to act. The owner also needs a record of where its data lives and who can access it, so a change of owner does not trigger a search for undocumented stores of personal data.

The budget should cover retirement too, including moving the records you need and cleaning up the rest. Otherwise, you acquire a museum of promising ideas, all requiring password resets. I welcome cheaper software that lets people tackle frustrations previously too small to justify a project. The catch is that we may soon afford to build more applications than we can sensibly look after. Choosing what to keep, improve or close needs the same management attention as approving something new. The colleague who built those 200 applications showed what individual initiative could achieve. We had failed to budget for what followed.

As building gets cheaper, more of our attention will go towards deciding what deserves to stay and adapting it as the business changes. The code may arrive in an afternoon. The bill, however, includes years of decisions about what happens next.

The writer works in Singapore’s public service and has been in the tech industry for more than 30 years.