Building Apps with AI Without Coding
I want to tell you about two apps I built over the Easter long weekend. Not because they're particularly sophisticated — they're not. But because of what building them represents, and what it says about where we are right now with AI and everyday problem-solving.
One was a work hours tracker for my household. The other was a pocket money management app for my kids. Neither required me to write a single line of code from scratch. Neither required me to know Python, JavaScript, or any other programming language. Both work exactly as designed, solving real problems we actually had.
I'm a CPA who loves Excel and has been building finance tools with AI assistance for the past couple of years. I'm not a developer. I've never been a developer. And that used to mean there was a hard ceiling on what I could build. That ceiling is gone.
Two Problems, Two Weekends, Two Apps
App 1 — The Work Hours Tracker
My wife and I both work. Both of us carry workloads that spill outside standard hours fairly regularly — early calls, evening emails, weekend catch-ups. For a while we had a running joke that neither of us actually knew who worked more. Then it stopped being a joke.
The Problem
I described what I wanted in plain English to an AI tool — the logic, the layout, what it needed to track, how I wanted it to display. Back came a working app. I tested it, found a couple of things that didn't behave quite right, described the problem in plain English, and got the fix back. Repeat a few times. Total time from idea to working product: a few hours over a weekend afternoon.
The result is a simple, clean app that lives on both our phones. We log hours as we go. At the end of the week we can both see the actual picture. The conversations about workload balance are now grounded in data. It's changed the dynamic in a way that a spreadsheet never could — because a spreadsheet requires one person to own it, and this doesn't.
App 2 — The Pocket Money Tracker
The second one started with a question from one of my kids: "Dad, how much do I have?" Followed shortly by: "But you said I'd get extra for doing the bins." Followed shortly by my wife having a different recollection of what we'd agreed to.
The Problem
Same process. I described the logic — how chores would be recorded, how the balance would update, what the display needed to show the kids versus what we needed to see as parents. A working app came back. A few iterations to get the interface right for small hands and short attention spans. Done.
Three weeks in, the pocket money negotiations have essentially stopped. The data is just there. My son now checks his balance the way I check my bank account. My daughter has started strategically completing higher-value chores before requesting purchases. I'm choosing to call this financial literacy in action.
What This Actually Represents
I could have built both of these in Excel. A workbook for the hours tracker, another for the pocket money ledger. They would have worked. But they wouldn't have been apps — they'd have been files that one person owned, that the other person had to be walked through, that couldn't live easily on multiple phones, that felt like spreadsheets because they were spreadsheets.
The thing that AI has changed isn't just that it can write code. It's that the conversation you have to describe what you want — the problem definition, the logic, the rules — is now the programming. The translation layer between "here's what I need" and "here's a working system" is essentially gone.
💡 The Shift That Matters
For as long as software existed, building it required either knowing a programming language or paying someone who did. That created a hard boundary: on one side, people who could build tools; on the other, people who had ideas and needed to either learn to code, hire a developer, or make do with whatever off-the-shelf software most closely matched their need.
That boundary is dissolving. What matters now isn't whether you know Python or JavaScript. It's whether you can think through a problem clearly enough to describe it: what the inputs are, what the rules are, what the output should look like, and what happens at the edges. That's a logic skill. Finance professionals have been developing exactly that skill — in Excel, in process documentation, in financial modelling — for their entire careers.
The programming language barrier is gone. The thinking barrier remains. And that's actually good news for finance people.
The Honest Caveats
I'm not going to pretend this is all frictionless. A few things worth being honest about:
You still need to think clearly. The AI can only build what you can describe. If you're vague about what you want, you get a vague result. The apps I built worked well on the first real attempt because I spent time thinking through the logic before I started. Problem definition is still your job — possibly more so than before, because the execution is now fast enough that ambiguity in the brief shows up quickly.
You still need to test and iterate. Nothing came back perfect first time. Getting from "it works" to "it works well" required several rounds of describing what wasn't quite right and getting fixes back. The iteration cycle is fast — much faster than briefing a developer and waiting for a sprint — but it still exists.
Simple personal apps are a different category from production business systems. The apps I built handle my family's data in low-stakes contexts. Building automation tools for a finance function — payroll processing, compliance monitoring, financial reporting — involves data sensitivity, audit requirements, and error consequences that raise the bar significantly. The same underlying capability applies, but the rigour required scales with the stakes.
Security still matters. Any app that touches real data — especially financial data — needs to be built with appropriate care about where that data goes, who can access it, and what happens if something goes wrong. "I built it in a weekend" and "it handles sensitive data responsibly" aren't mutually exclusive, but they require intentional design, not happy coincidence.
What It Means for Finance Professionals
I started building finance automation tools this way a couple of years ago, initially with some scepticism about how far it would actually go. The pocket money app and the hours tracker are personal examples, but they illustrate a capability that translates directly to professional contexts.
The payroll reconciliation tools, the management reporting frameworks, the compliance monitoring workflows — all of them were built through the same conversation-based process. Describe the logic, get a working foundation, test against known data, iterate until it's right.
The difference in the professional context is that the problem definition work is harder, the testing has to be more rigorous, and the stakes of getting it wrong are real. But the underlying capability — the ability to build custom tools that solve specific problems without needing a developer — is the same.
The finance professionals I see getting the most value from this capability are the ones who've stopped thinking about AI as a chat interface and started thinking about it as a collaborator who can build things. That shift in mental model matters more than any specific tool or technique.
Interested in what this kind of custom tool-building looks like in a professional finance context — without the trial and error of figuring it out from scratch? That's the kind of work PFL does with NDIS providers and SME finance teams.
Talk to PFL →
Comments
Post a Comment