Replacing Poor-Fit SaaS with Software Built for the Work
How I replaced parts of QuickBooks with a focused internal tool built around how The Arts Hub actually works.
We were paying for QuickBooks and using a narrow slice of it badly.
The workflow never felt designed for us. Importing and identifying transactions took too much effort. The categories did not map to the way we operate. Producing a useful year-end report needed more interpretation than it should have. We were carrying a large accounting product to do a small job it was not shaped for.
QuickBooks was only one example of a wider pattern. Like most small organisations, The Arts Hub had accumulated software one problem at a time. We needed somewhere for team members to keep their details. Then timesheets. Then payment tracking, task assignments, bank categorisation, year-end reporting. Each requirement could justify another subscription, and none of them looked expensive on its own.
That is how vendor sprawl begins. It rarely arrives as one bad decision. It arrives as a series of reasonable ones.
So I asked a different question. What if I built one platform to do these jobs properly, instead of renting several that each did one of them badly?
Vendor sprawl is an operational problem, not a budget one
The subscription cost is the part everyone notices, and it is the smallest part.
Every additional product brings its own user directory, its own login, its own data store, its own privacy relationship, its own export format and its own way of failing. The real cost is the time spent moving information between systems and working out which one holds the current version of a record. For a small organisation, that overhead is disproportionate. A tool bought to save time becomes one more place to check, maintain and explain.
The aim was never to rebuild QuickBooks. It was to build the small set of workflows we actually use into a single staff portal of our own.
Starting with the workflow, not the product
I built the portal from scratch, starting with the simplest thing: somewhere for team members to maintain their own contact, tax and payment details. From there it grew to cover the rest of the operational work: timesheet submission, administrative review, and the statuses that go with it (paid, approved, queried), through to payment dates and references. Hourly rates are captured as snapshots, so historical pay records stay accurate even when a rate later changes. On top of that sits a small internal task system with assignments and due dates, and a set of notifications that fire when a timesheet is submitted, queried or paid.
The security decision worth calling out is a small one. When a team member changes their own payment details, the system raises a warning that requires independent verification before anything is trusted. That single rule is the sort of thing a general-purpose SaaS product rarely lets you shape to your own risk.
None of this meant a separate product for timesheets, tasks, staff records and banking. It meant one platform, built around the real work.
Using Claude to understand the accounts
Before building anything for banking, I used Claude to read through the existing accounts and transaction data.
That surfaced the categories we had actually used, how income and expenses appeared in the bank exports, which suppliers and descriptions recurred, where personal or non-allowable spending sat, and how the previous profit-and-loss report was structured. It also flagged the places where the source data needed a human to look properly.
The point was not to ask an AI to do the accounts. It was to analyse what already existed and settle on a practical data model. Financial records still need evidence, judgement and review. AI is good at spotting patterns. It should not be quietly making tax decisions.
Using Codex to build the replacement
The portal itself was built this way, and I used Codex the same way to add the banking tool inside it. It is deliberately narrower than QuickBooks and does only what we need: import bank statement CSVs, protect the original evidence, catch duplicate and overlapping imports, suggest categories from rules and past decisions, and require a human to review every transaction before it counts. From there it separates business from personal and allowable from non-allowable spending, matches team payments to approved timesheets, and produces an evidence ledger and year-end report.
What it deliberately does not do matters just as much. It is not a bank connection. It cannot move money and it does not hold online-banking credentials. Transactions are imported by hand from Barclays. Sensitive narratives and original statements are encrypted. Account numbers and sort codes in the newer exports are discarded, because the tool has no reason to keep them.
A custom internal tool should have fewer privileges than a broad SaaS product, not more.
Categorisation that learns from what you already decided
The most tedious part of accounting software is categorising the same familiar transactions over and over.
The tool cuts that work two ways. Rules recognise recurring descriptions, so a workspace subscription, a venue cost or a production supplier can be suggested a category automatically. And the category selector surfaces whatever you chose last time for the same normalised description, so if a supplier was filed under performance licences before, that option is right there on the next review.
In both cases it only ever suggests. Nothing is marked as reviewed until a person confirms it. The system assists and the administrator decides, which stops one wrong assumption from quietly becoming a year of wrong accounts.
A tax-return report built around the real data
Our old profit-and-loss report showed income, a few broad expense headings and net income. Usable, but it hid its own reasoning.
The replacement keeps that familiar shape and makes the decisions visible underneath it. For each expense heading it shows the total reviewed spending, how much of it is being treated as allowable, how much is not being claimed, and how many transactions sit behind the figure. It then works out a provisional taxable profit, before capital allowances and year-end adjustments.
Just as importantly, it is honest about what bank transactions alone cannot tell you: capital purchases, stock and work in progress, debtors and creditors, cash activity outside the imported accounts, private use of business goods, and the business-use split on mixed expenses. The report prints or saves as a PDF, with the full evidence ledger exported alongside it. It is a preparation tool. It is not a tax submission and it is not a substitute for professional advice.
Notifications without another vendor
The portal sends its notifications through our existing Google Workspace domain. Team members are emailed when they are added or when a timesheet changes status. Administrators are notified about submissions, task assignments and payment-detail changes.
Before turning welcome emails on, I sent test copies through the live relay and checked the wording, and left the feature switched off in production until delivery was confirmed. That kept us from taking on yet another transactional-email provider, another bill and another copy of staff contact data.
Security is the reason to do it carefully, not the reason to avoid it
Building your own tool for staff and financial data only makes sense if it is at least as well protected as the product it replaces. That was a condition, not an afterthought.
The portal is never exposed directly to the public internet. It sits behind a Cloudflare tunnel, so there are no open inbound ports on the server for anyone to find or probe. Access requires multi-factor authentication, so a leaked or guessed password is not enough on its own to get in. Sensitive data is encrypted at rest, so the records that matter are not sitting in plain text on disk. Backups are encrypted too, which is the part people forget until they need it. Taken together with the choices already described, holding no banking credentials, discarding account and sort codes, requiring review before anything counts, the tool ends up with a smaller attack surface than the spread of SaaS accounts it replaced.
That is the quiet advantage of a narrow internal tool. It only holds what it needs, and it only does what you built it to do.
What the AI actually contributed
It would be easy, and wrong, to say AI built our accounting system.
Claude helped analyse the existing accounts and sharpen the problem. Codex did the engineering across the whole platform, the staff portal and the banking tool alike: it read the repository, wrote the code, migrations and tests, updated the documentation, committed the work, deployed it and checked the live services. That is real leverage, and it is worth being precise about it.
But the result still rested on decisions no model made: which workflows belonged together, that bank payments would never be automated, that sensitive records would be encrypted, that every transaction would be reviewed, that duplicate imports would be caught, that the last administrator could not be removed, that notifications would be tested before release, and that the report would be honest about what bank data cannot establish.
AI accelerated the engineering. It did not remove the need for it.
The broader lesson
AI-assisted development changes the maths on vendor sprawl. It does not mean every subscription should be replaced. Established products are still the right call when the requirements are standard, the regulation is complex, or the integrations would be hard to reproduce safely. That is most of the time, and it is worth saying plainly.
What has changed is that there is now a credible middle ground. When a product is expensive, frustrating, or used for a fraction of what it does, a focused internal tool can be the better fit. The goal is not to rebuild the SaaS product. It is to build the smallest secure system that matches the actual workflow.
For The Arts Hub, that meant staff records, timesheets, tasks, notifications and banking administration living in one platform we control, instead of five we rent. Fewer vendors, fewer duplicated records, and software shaped around the organisation using it.
If your organisation is wrestling with the same trade-off, I am available for freelance business analysis and development. Get in touch.