I am a chartered accountant. I have spent about thirty-five years in the profession, I am almost fifty-nine, and I cannot write a single line of code. This year I have built around seventeen working apps. I showed how at the AI in Practice Summit, and if you would rather watch the live build than read about it, the recording is here.
I start there because most firms I speak to are talking about AI without building anything useful with it. They are experimenting, watching demos, reading the headlines. Very few are making the tools that would make their own practice easier. And this is one of the biggest open opportunities any firm has right now.
The reason is simple. The cost of building software has collapsed to near zero. The custom tools I used to pay for as subscriptions in our tech stack, I now build myself in a morning. That moves the question from what a firm can afford to build to what it can imagine.
Plain English in, working software out
Vibe coding means building software by describing what you want in plain English, then guiding the AI step by step. You brief it the way you would brief a junior team member, and it writes the code. The term was coined by Andrej Karpathy, one of the cofounders of OpenAI, in early 2025. It took me six months to jump on board, and I wish I had started sooner.
You never see code, but a few concepts make the whole thing click, and analogies help. Picture a restaurant. The front end is the dining room, the screens and buttons your users see. The back end is the kitchen, where the database, the logic and the security do the real work, and you build the dining room first before wiring it to the kitchen. A database is an organised spreadsheet your app reads from and writes to, authentication is how it knows who has logged in, and CRUD is the four things you do with data: create, read, update and delete. The one to respect is row-level security. Picture a block of flats with two keys. The first gets you through the front door, which is your login. The second opens your own flat, where your valuables sit, and that is what stops one client ever seeing another client's data.
Plan first, build second
The temptation is to dive straight into the build tool and start typing. That is the mistake. The more thinking you do up front, the better the result, so the work splits into three stages: plan, create, then optimise.
The plan stage produces a product requirements document, a PRD. Any software developer would expect one before building anything, because it sets out the purpose, the users, the core features, the data model and the branding. If an app will take me three hours, I happily spend the first forty-five minutes on the PRD, because it makes everything after it faster.
Build the PRD in ChatGPT rather than in the build tool, for one practical reason. Build tools charge credits every time you ask them to do something, so do the thinking where it is free and save the credits for the build. I run a standard prompt from my library and add a paragraph describing the app, and the clever part is that the prompt makes ChatGPT interview me, usually with twenty or thirty clarifying questions. As a non-developer you have rarely thought through half of what a developer needs to know, things like whether the app needs a hidden admin page or whether you might later sell it to other firms. The questions draw those decisions out of you, and then it writes the PRD in seconds.
Let the build tool handle the plumbing
The right tool does the engineering you cannot. For the live build I used Lovable, which I recommend for anyone starting out, because Lovable Cloud bundles a database, AI credits, document storage and proper row-level security into your workspace, so you avoid wiring up a separate database subscription and a separate host. The developer-grade tools like Claude Code and Codex are powerful, yet they feel like a scary room if you have never built software. Lovable does that part for you.
From there, building is a conversation. You attach the PRD, ask it to read the document and build the scaffold, and it lays out the front end, the database schema and the storage in a couple of minutes. There are two modes, plan mode where questions change nothing and build mode where things actually happen, and the habit that serves me best is to ask first and build second. Adding our firm logo was as simple as uploading it, asking for it in the top right of the nav bar, then asking again to make it twice the size when it came out too small.
The app I demonstrated uploads a client's bank statements and invoices, categorises and matches them, flags any bank movement that has no supporting document and writes a month-end review summary with a dashboard. It took about an hour. The same kind of tool takes the year-end close, the crunch every firm is staring down right now, and turns hours of checking into minutes.
The limit is your imagination
That app is one of seventeen. There is a debt advisory tool that took one client from 162 months of repayments down to 94 and saved them £43,000 in interest. A retirement planner I built to answer can I retire yet, then shared. Value pricing tools that build out bronze, silver and gold packages. A financial dashboard from an uploaded profit and loss. Lead pages, a website for my cycling club, a quoting tool for a friend's catering business and an internal HR app my daughter built for expense claims and holiday entitlements.
The binding constraint used to be technical skill. Now it is imagination. If you can picture the tool your firm keeps wishing it had, you can build it, and you can start this week. Watch the full session and the live build here, then open a free account and make something small. I warn you, it is addictive.
