I recently built a small expenses claim application as a practical way to test an AI-assisted development workflow against a familiar business process.

Expenses are deliberately ordinary, which makes them useful. The process has enough real complexity to be interesting: users, claims, receipts, approvals, policy checks, audit trails, exceptions, and reporting. It is not glamorous software, but it is exactly the kind of internal workflow where organisations spend a lot of time and money.

The build made a few things obvious. AI can help move from idea to first version quickly, but the hard work remains in deciding what the process should be, which controls matter, how edge cases should be handled, and what evidence is needed for review or audit.

This is where the falling cost of code generation becomes interesting. If a small team can build a usable first version quickly, then more internal processes become candidates for software. The question changes from “can we afford to build this?” to “is this the right thing to build, and what controls does it need?”

That is where technology leadership becomes less about tools and more about operating judgment. A working prototype is useful, but it is only one part of the decision. The better question is whether the process is simpler, safer, easier to support, and better aligned to how people actually work.

In that sense, the technology is not the whole story. AI may reduce the friction of creating software, but organisations still need to understand the process, the policy, the data, the risk, and the people who will live with the result.