Can you build your own business software with AI now?

Where building it yourself works, where it falls over for a team with real data and real uptime needs, and how to tell which side of the line you are on.

Published 11 September 2026

Short answer: yes for a prototype, no for a system your team will run the business on.

That is not a sales line. We build with AI all day and it writes most of our code. The tools are real. But there is a hard line between “an app that works when I click through it” and “software a team of people trusts with customer data at 9am on a Monday”, and if you have never built the second kind you cannot see the line from where you are standing.

This page is about where that line sits and how to tell which side of it you are on.

Where building it yourself is the right call

We will be straight about this: a lot of what people want to build does not need us.

  • A prototype. You have an idea for how a workflow should look and you want to see it. Build it in Lovable, Replit, Claude or ChatGPT. The prototype will be a better brief than any document you could write.
  • A tool for one person. A calculator, a personal tracker, a script that reformats a spreadsheet. If it breaks, one person shrugs and fixes it.
  • Nothing sensitive in it. No customer records, no pricing, no staff data, no logins.
  • Nobody is waiting on it. If it goes down for a day, nothing stops.

If all four are true, do it yourself. You will learn a lot and it will cost you a weekend.

What "business grade" actually means

The moment more than one person depends on the app, the job changes. Not a bit. Completely.

Software a business runs on has to handle:

  • Several people with different access. The owner sees everything, a manager sees their team, a contractor sees one job. Every screen and every piece of data has to respect that, every time.
  • Data you cannot lose. Orders, invoices, client files. If it disappears, you need it back, exactly as it was, within the hour.
  • Being up when people need it. Not “mostly”. A field crew at 6am, a customer paying at 11pm, month-end reporting on a Sunday.
  • The rest of your systems. Xero, your CRM, your job management tool, a supplier’s portal. Each connection is a thing that will change without warning.
  • Growing. Fifty records today is nothing. Fifty thousand in two years is normal. A screen that loads instantly in the demo can take minutes once the data is real, and by then the whole team is waiting on it every day.
  • Someone on the hook. When it breaks, a person with the skills to fix it has to be available.

None of that is visible in the demo. All of it is where the work is.

The part you cannot see in the demo

An AI coding tool builds what you describe. That is the trap. You cannot describe what you do not know exists.

When we build a system, most of the decisions are never seen by the client, because they are the plumbing:

  • How the data is structured so it stays correct when two people edit the same record at once.
  • Who is allowed to read which rows of the database, enforced at the database, not just hidden in the interface.
  • Where secrets like API keys live, and making sure they are not shipped to the browser.
  • Where the data is hosted, which matters if you have Australian clients and any privacy obligations.
  • Backups that run, and a restore that has actually been tested rather than assumed.
  • Indexes on the tables that get searched, so the app stays fast at real volume.
  • What happens when a connected service is slow or down, and how the app retries without duplicating an order.
  • Logging and alerts, so you find out something broke before your customer does.
  • How updates get released without wiping data or taking the app offline.

A tool with no experience behind it makes every one of those decisions by default, silently, and usually the cheap way. The app looks finished. It looks finished right up until it is not.

What it looks like when it goes wrong

Two examples from the last eighteen months, both public.

Lovable, 2025. A security researcher scanned 1,645 apps built on Lovable and found 170 of them with databases readable by anyone, no login required. Emails, API keys, payment details. The cause was the same in every case: the database’s row-level security was never switched on, and the apps worked perfectly without it, so nobody noticed. It was logged as CVE-2025-48757.

Replit, July 2025. Jason Lemkin, a well-known SaaS investor, spent twelve days publicly building a product with Replit’s AI agent. On day nine the agent deleted his live production database during a code freeze, after misreading an empty result as a bug to fix. It then told him the data could not be restored. That was wrong too; a rollback worked. The Register covered it in detail.

Now put that in your business. Every customer record and invoice gone on a Tuesday afternoon, with no working backup. Your pricing and staff details readable by anyone who guesses the address. And when it happens, you open the tool, describe the problem, and it confidently tells you something that is wrong, because it does not understand the system any better than you do. The tool that built it is the same tool you have to ask to fix it, and it will sound just as sure when it is wrong. There is nobody to call, because you built it.

The point is not that these tools are bad. Both companies fixed things. The point is that the person building had no way of knowing either problem was possible before it happened, because knowing was the job they had not done before.

The quieter version happens far more often and never makes the news: the app that ran fine for six months, until the customer table hit real size and every page started taking twenty seconds. Or the one where a contractor could see every other contractor’s rates because the filter was in the interface and not the database. Nobody was breached. It just quietly cost trust.

What you are actually paying for when you hire someone

Not typing. AI does most of the typing now, for us as well.

You are paying for someone who knows what to ask for, what to check, and what “done” means for software people rely on. The demo is roughly the first fifth of the work. The other four fifths is making it not fail, and that part is invisible when it is done well, which is exactly why it is so easy to skip.

If you want a sense of what that costs in real numbers, our pricing guide has the brackets.

The best of both

The hybrid works well and we recommend it.

Build the prototype yourself. Click through it, show your team, work out what you actually want. Then bring it to us. A working prototype is the clearest brief we ever receive, and it usually makes the scoped build cheaper because the guessing is gone.

We keep what is right about it and rebuild the parts that have to be solid. You get the thing you designed, on foundations you do not have to think about.

Six questions before you put your team on an app you built

If you have already built something and people are starting to depend on it, answer these honestly:

  1. If someone logs in as a normal user, can they read data that is not theirs by changing a URL or an ID?
  2. Where is the data hosted, and is that a problem for your clients or your industry?
  3. If the database was deleted right now, how would you get it back, and have you ever tried?
  4. What happens when two people save the same record within the same second?
  5. What happens when Xero, or whatever it connects to, is down for an hour?
  6. Who fixes it at 9am on Monday when it is not you?

If any answer is “I don’t know”, that is not a criticism. It is the line. You have found it before it found you.

Start here

Tell us what you're working with.

A few quick questions so we come to the first conversation prepared.

What would you like to improve? pick any

Your details stay with us. No newsletter, no follow-up sequence.