If you've been anywhere near the bookkeeping and small business space over the last couple of years, you'll have noticed it. New apps everywhere. Slick, purpose-built tools promising to solve one specific problem better than the big platforms ever could. Reconciliation helpers, reporting add-ons, workflow automators, industry-specific niche solutions. Some of them are genuinely excellent.

But there's a pattern worth naming, because I don't think enough business owners are asking about it before they commit.

Who's actually behind the app?

A lot of these tools aren't built by established software companies with a product team, a support desk and a roadmap. They're built by one person, or a very small team, often a developer who saw a gap and built something clever to fill it. That's not a criticism. Some of the best tools in this space started exactly that way, and solo builders can move fast and listen closely to what practitioners actually need.

But it does mean something important for how you should evaluate the tool. When you sign up, you're not just buying software. You're placing a bet on a person, or a very small handful of people, staying interested, staying available and staying in business.

And this is only accelerating. AI-assisted development tools, things like Claude, Lovable and similar platforms, mean a single person can now design, build and ship a working app faster than ever before, often without a team, without formal QA, and without the infrastructure a proper software company would normally have around it. That's not a knock on the tools or the people using them. It genuinely opens up who gets to build something useful. But it also means the pattern this post is about isn't slowing down. It's speeding up, and it's worth having on your radar now, not once it's already caused a problem.

What "deeply embedded" actually looks like

This only becomes a real problem when the app stops being a nice-to-have and becomes part of how your business actually runs. That might mean:

• Client data lives inside it, and nowhere else
• A daily or weekly process depends on it working
• Your team has been trained on it and built habits around it
• Other tools or workflows have been built to connect to it
• You're paying an ongoing fee for continued access and support

None of that is a red flag on its own. It's just normal adoption. The risk shows up later, when you've stopped thinking of it as "that new app we're trialling" and started thinking of it as infrastructure.

The part nobody talks about at sign-up

Here's the scenario worth sitting with. Six months in, the app is working well and you've built it into your workflow. Twelve months in, updates have slowed but nothing's broken yet. Eighteen to twenty-four months in, support tickets go unanswered, security patches stop, and eventually you find out the developer has moved on to something else, sold the business quietly, or simply run out of steam.

For a fee-for-service app, that's a particularly uncomfortable position. You've been paying for ongoing support and maintenance, and at some point that support quietly stops arriving even though the fee might not. Meanwhile your business continuity, and potentially client data security, is sitting on a foundation nobody is actively maintaining.

This isn't a hypothetical about one bad actor. It's a structural risk that comes with how a lot of this innovation happens. Solo developers and small teams are often where the best ideas come from, but they're also the most exposed to burnout, changed priorities, ill health or simply moving on to the next thing.

This isn't a new problem, it's just a new format

If you've been in this industry long enough, you'll recognise this pattern. It's the same one we lived through with Microsoft Access databases.

Through the nineties and two thousands, plenty of businesses ran on a custom Access database built by one person, often an in-house bookkeeper, office manager, or an external consultant who understood the business well enough to build exactly what was needed. It worked. It was often better suited to the business than any off-the-shelf option.

Then that person left. Retired, moved on, or simply became unavailable. And the business was left with a system nobody else understood, that couldn't be updated, and that eventually had to be painstakingly reverse-engineered or replaced at real cost and real risk, usually at the worst possible time.

The apps proliferating through the industry now are the same risk wearing a different outfit. Cloud-based, subscription-priced, better looking, but still ultimately dependent on the ongoing availability of the person, or small team, who built and understands them. The format has changed. The underlying exposure hasn't.

Questions worth asking before you commit

I'm not suggesting you avoid new or niche tools. Some of them are worth the risk, and plenty of established platforms started exactly this way. What I'd suggest is asking a few questions before you let a tool become load-bearing in your business:

• Who built this, and is it one person or a team?
• What happens to your data if the app disappears tomorrow? Can you export it easily, in a usable format?
• Is there a clear support structure, or is it one person answering emails when they can?
• How long has it actually been running, and has development continued steadily?
• If security patches stopped tomorrow, would you know?
• Do you have a fallback process if the app becomes unavailable overnight?

If you can't answer most of these, that's not necessarily a reason to walk away. It's a reason to keep the tool at arm's length until you can, rather than wiring it into everything you do.

Why this matters more if you're a registered practitioner

If you're a registered BAS or tax agent, this isn't just good business sense, it sits inside your professional obligations. The Code of Professional Conduct already requires you to maintain sufficient IT controls to protect the security and confidentiality of client records, and the TPB has previously encouraged practitioners to seek expert advice to confirm their software choices actually meet that standard.

It's just been reinforced again. On 22 July 2026, the TPB published new guidance on AI and the Code of Professional Conduct, which applies to registered tax and BAS agents. Among other things, it says practitioners should be reviewing any AI application they use, whether commercial, internally built, or modified, to make sure it meets data security standards and complies with the Privacy Act.

That guidance is about AI specifically, but the underlying principle isn't new and isn't limited to AI tools. If a third-party app holding or touching client data goes unmaintained, the security gap that creates sits squarely inside your Code obligations, not just your operational risk. Vetting who built a tool, and whether it's still being actively maintained, isn't optional due diligence anymore. It's part of meeting your professional obligations.

This isn't about saying no

I want to be clear about what I'm not saying. I'm not telling you to stick only with the big established platforms, and I'm not saying solo-built tools are inherently unsafe. Some of the most useful things in this industry came from exactly that kind of builder, and plenty of them are still going strong years later.

What I am saying is that adoption should be a considered decision, not an accident of convenience. Know what you're relying on, know who's behind it, and have a plan for what happens if it goes quiet. That's not caution for its own sake. It's just good business practice, and it's the same due diligence you'd apply to any other supplier your business depends on.