It depends on what you're building, so here's how I think about it in four sizes. These are rough build times once the scope is clear.

A very small tool, something really minor, could probably be built by the person themselves in a couple of days. Think of the quick calculator or the one-off helper I talked about in question 8.

Something a little bigger, with very basic functionality or a few basic integrations, takes maybe half a week to a week. A form that saves to a database and sends an email is the kind of thing I mean.

Something more nuanced and in depth takes two to three months. This is where you have real business logic, different kinds of users, and more integrations. It's also where the edge cases start to bite, which is the 80/20 rule I mentioned earlier.

And then there's the really heavy stuff, where there's a lot of testing involved and it's critical that every bug is ironed out before it goes live. You're dealing with financials, things like that. That can take six to twelve months, and a lot of that time isn't writing code. It's testing, security checks and making sure it does exactly what it should every time.

A few things move those numbers around. How clear the scope is, for a start. How many other systems it has to connect to, and how well they behave. Whether your data has to be migrated out of spreadsheets or an old system first. How quickly you can give feedback and make decisions, because waiting on answers adds up fast. And how much testing the stakes demand.

AI has helped with building and testing, as I said earlier. But the edge cases and the decisions still take the time, so don't expect AI to turn months into days for anything that matters.

There are ways to shorten it. Start with a small first version that does the main job, get it live, and add to it. Have one person who can make decisions. Write down what done looks like before we start. And build on a clean slate where you can, because migrations add time.

So the honest answer is a couple of days for a tiny tool, about a week for something basic, a couple of months for a proper business system, and up to a year when the stakes are high.

If you're just starting out, there's nothing wrong with using spreadsheets until you've made some money and built up your client base. There's definitely nothing wrong with that.

The trouble shows up as you grow. A spreadsheet relies on someone understanding the formulas. Follow-ups slip, because nothing reminds you. You end up re-entering data from the spreadsheet into something else, like your invoicing. Macros are very easy to break. It's hard to see the different revisions, what changed and who changed it. And you can't tell who's editing what at the same time, so there are multiple versions of the file floating around.

You do get some options in between. You can use a tool that turns your spreadsheet into an app, so the sheet you already have gets a proper front end. You can use an off-the-shelf CRM. Or you can go custom.

Off-the-shelf CRM is where most people go first. It's worth knowing what you're buying, and question 7 covers what to look for and when one stops fitting.

As with anything, look at the cost against the value. If the problems above are costing you more than moving would, it's time to move.

This is a question I get quite a bit.

What you'll find, at least in my experience, is that you get to what seems like 80% of the product in about 20% of the time. The other 20%, the edge cases, takes about 80% of the development time. And these are things you might not even be aware of. For example:

• A customer has an order with us and then deletes their account. What happens to the order?
• Two people buy the same item, or book the same time slot, at the same moment.
• The same customer gets entered twice under slightly different names, and now has two histories.
• Someone double-clicks the submit button and the form goes in twice.
• Two staff edit the same record at once, and one overwrites the other.
• The clocks change for daylight saving and a booking lands an hour out.
• Someone changes a number in the web address and sees another customer's details.
• A payment goes through but the confirmation never arrives.
• An order is part-refunded.
• A staff member leaves, and their jobs, records and logins are still in the system.
• Someone imports a messy spreadsheet with missing fields and dates in three different formats.
• GST rounds differently on an invoice.
• The internet drops halfway through saving.

The thing with AI is that you'll get there. You can steer it to a product that is almost finished. But the rest takes quite a bit, depending on how complex the app is.

This isn't only my opinion. In 2025, Veracode tested more than 100 AI models on 80 coding tasks and found that the code introduced a security flaw in 45% of them, and that newer models were no better at security. That was snippets of code, not whole apps, but it shows the problem. In one real case, a researcher scanned 1,645 apps built on the Lovable platform and found 170 where the database could be read or written by anyone with the public key, because the access rules had never been switched on. And in July 2025, an AI coding agent on Replit deleted a company's live database during a trial, after being told not to touch anything, and then misreported what it had done. The data was recovered from a backup. The reported cause was one database being used for both testing and the real thing. Business owners say the same. On Reddit, someone who built two products with Claude Code says it isn't as easy as everyone thinks, and on Hacker News a reply to someone whose app failed says that if you don't know software design, Claude Code will fail.

For very small applications, it's fantastic. Say you need a quick calculator, or a real quick tool for your business, something that isn't worth integrating into your business application. AI is a really fantastic tool for that, and honestly it has come such a long way in the last couple of years. It has come on leaps and bounds.

But if you're looking at something scalable, you need a developer who has experience building apps and can foresee problems you might not even be aware of. The code is only part of it. A business app also needs logins and permissions, backups, hosting and uptime, protection for customer data, integrations that keep working when other services change, and someone to call when it breaks. It's the same as building a house. You might be able to design a house nicely on paper, but have you considered drainage, council approvals, architectural design, roofing and services?

There's a fair middle path. Use AI to build a prototype, then hand it to a developer. A working prototype is a good brief, and the developer's job becomes finding the edge cases and hardening it.

We use AI coding tools ourselves. What a developer adds isn't secret skills. It's judgment and accountability. For example, every table in our database has row-level security switched on, so access is denied unless a rule allows it. That's the kind of thing that was missing from those 170 apps.

So to answer the question: for a small tool, it's fantastic. For a serious app, whether that's a web app, a mobile app or a desktop app, you really do need a developer.

The beautiful thing about custom software is that you really do get to look at all the variables, one solution at a time. There are times when the value proposition isn't there. If your business falls into one of those small categories where something off the shelf is perfect for you, then I do recommend going with that.

The major issue is that most businesses don't fall into that category. And even if they do, it's rarely just one application. A lot of these applications are locked down. They don't have API endpoints, they don't have connectors, and they have no interest in making the other applications you use part of their ecosystem. Usually that's because it comes at a cost, and they make their money through bulk sales at a lower price. There's no such thing as a free lunch.

At certain stages of a business, that's not a big deal. But as the business scales and grows, so do the upkeep costs of managing all those applications and the communication between them. Usually there's one person in admin whose whole job is to get details out of an email, pump them into a spreadsheet, build a report from that spreadsheet, or pull details out of one app and key them into another for payroll. Basic, repetitive stuff.

I have a pretty strong stance that admin is potentially the biggest drain on a business, because of how repetitive it is. So the question I'd ask is: how much time do you want to save? A custom solution is worth it when you're scaling and growing, when you could save a couple of hours a day, potentially even a whole day if your business is big enough (it can cut down one staff member), and when you have a vision of where you want things to be in the future, as long as you have complete control over it.

Some signs you've outgrown off-the-shelf products: you have more subscriptions than you know what to do with, and you spend a lot of time juggling between them, getting them to work with each other.

How do monthly per-user fees compare with a one-off build plus running costs? It depends on how long the business is going to be around. One-off builds used to be prohibitively expensive. Getting an app designed could easily cost over $100,000 for something not that complicated. Those costs have come down, mainly because of AI. AI coding agents help with building the application and, more importantly, with testing it. In general, off-the-shelf will always beat custom on price, but if you average it out over a couple of years, that might not be the case. And that doesn't count the time you save, or the fact that the application can add to the value of the business if you ever want to buy or sell one.

What about the risks of custom, like depending on one developer to maintain it? The application is a living thing. Dependencies need updating, the code needs updating, there are new security guidelines, and new laws you have to follow. That's why it matters to choose a developer with solid documentation and a solid track record. If you ever want to move away, take your data, go to another developer and build something bigger, you're not locked in. Everything is there, neat and tidy and easy for the next person to understand. That's how we work. If you pay for the development upfront, we don't lock you in, and we will always assist with your migration. If you're month to month, we still assist with a migration, because it's the human thing to do.

And if your business is in a niche, stay away from off-the-shelf products. The chances are there's no product built for what you do, so a custom build, even a simple one, is the better choice.

This depends a lot on how much experience someone has with programming and automation.

For most people, even n8n, Zapier and Power Automate are out of reach if they don't understand how HTML works, how authentication works, how information gets passed from one step to the next, and the different file types. Without that, it isn't simple.

They do look nice, though. n8n and Zapier give you a really good visual picture of the flow. That gives you something to anchor on, compared with a pile of code spread across different lines and files, so in that sense it does make things easier.

If you have some office experience, you're tech-savvy and you understand the basics, the gap isn't that big, especially if you're happy to Google and research what you want to do. The trouble comes when you want to change something. It's often not as simple as swapping one node for another. The tools have improved a lot, though. There are things now that make it easier, like an MCP for Claude or Codex, and AI assistance built into n8n itself.

The other question is where it runs. If you look at it as paying per automation, and each one costs cents, it looks very attractive. Run it on your own hardware and you keep your data and your data residency, which helps you meet data residency requirements. But then you have to think about encryption in transit, encryption at rest, storage, equipment, networking and internet uptime. What happens when the server needs an update? What happens when there's a security update and you don't even know about it? You pay for the server upfront and have to work out what it costs to run each year. Do you have an uninterrupted power supply? I wouldn't recommend it for a small business. If you're really in a pinch, you could run it on a small computer like a Mac Mini, but that isn't ideal. It depends on what you're running and how critical it is.

Then there are the integrations. In my experience, some of the nodes have issues and don't let you do everything as smoothly as you'd expect. There can be limitations, and you end up with odd workarounds and checking community nodes. It's not as simple as it looks. That's if you self-host n8n.

Then there's hosted. You don't need your own equipment, because they run it for you. But it starts costing quite a lot per month or per automation. If your business relies heavily on automations, the costs add up fast. A freight forwarder I know needs to extract around 700,000 transactions a month, and that's just one of his workflows. At that point it's easier to run your own hardware, or to develop custom software to do it.

Custom software will always win out in the end, and even small changes to it are easier if the person knows what they're doing. The only time I'd recommend n8n or Zapier is when someone already has experience with tools like Power Automate, has an intermediate level of computer literacy, and refuses to dabble in software development or hire someone to do it.

Honestly, pretty much anything can be automated. The better question is what's worth automating, so look at cost against value, and at what is really causing you pain.

That's different for everyone. For one person, the pain is that they're still running the business on Excel, Word and email. Nobody without access to their sheets can see what's going on, there's no revision control, no proper backups, and it can't adapt as the business grows.

For another person, it's forms. You'd be surprised how many people still fill them out by hand, then copy the answers into a sheet, send emails manually, and have no way of keeping track of their customers.

For someone else, it's the receptionist call.

So start with the lowest-hanging fruit, the thing that hurts most for the least effort, and work from there. That's the minimum.

Ideally, though, we'd automate as much as we can. Software is best built on a clean slate, and any modification or migration adds development time, complexity and cost. The more you can bring across in one go, the cleaner and cheaper it is than patching things on later.

It depends on what you put in and what you use it for.

A lot of what you'd put in can be anonymised first. The AI usually doesn't need a customer's name, phone number or address to do the job, so you take those out before anything goes in. If you are dealing with sensitive or identifying information, there are ways to handle that too, but it takes more care.

It also depends on which kind of tool you're using. A free chat window is one thing. Going through an API, or a business plan, is another: the providers say they won't train on your data by default, and some let you choose where it's stored, including in Australia. Those Australian options are more limited and restrict what you can build, so I'd rather not use them unless a client needs the data to stay here.

For most businesses and most people, it isn't a problem. But privacy law adds a few considerations, and they're worth knowing about before you start. They're too much to cover properly here, so I'd point you to the Office of the Australian Information Commissioner, which has plain- English guidance.

And you don't have to use ChatGPT at all. You can run your own model on your own server, so customer data never goes to a third party.

So the safe way is to decide what goes in, use the right plan, and keep names out where you can. The unsafe way is staff pasting whatever they like into a free chat.

Yes. This is where I put my foot down: any business can benefit from automation.

It isn't like buying a multi-million dollar factory to produce things faster. It's one of the best returns on investment a business can get. Say you save one hour a day, which is completely reasonable. A lot of owners work seven days a week, so over a year that's roughly 33 to 45 working days of eight hours, depending on whether you work five days or seven.

On a small level, it could be saving and allocating receipts and invoices, or managing timesheets and payments. Step up from there and it's automating emails and requests, having a phone agent, sending automatic follow-ups, replacing the copy and paste across four apps with one place, and automating your reports. Honestly, all admin can be automated these days, and a lot of operations can be too. Even GST can be handled if the system is set up properly. But building it to cover every eventuality isn't worth the return. A quick human approval, with what it learns documented, is the smarter trade.

It's a bigger load than most people think. A survey of 2,000 Australian sole traders and small business owners, commissioned by AMP Bank GO, found that 43% spend too much time on financial administration, with more than half dedicating over six hours a week to admin tasks. And 60% said they sacrifice personal time or weekends just to stay on top of their finances. That's only the financial side. The operational admin, like bookings, quotes, reports and emails, comes on top of it, and it's a lot more.

The irony is that the smaller the business, the more it benefits. Small businesses often can't afford a virtual assistant, in the Philippines or anywhere else, so in my experience they finish a ten-hour day and then do another three or four hours of admin, compliance and tax at home. They're the ones who would benefit most.

It depends, and the honest way to answer is to start with what you want it to do. Two businesses can both say "I want an AI receptionist" and need completely different things.

Start with the job. Is it a receptionist that answers the phone, takes details and books an appointment? Or is it customer service, where people ask about orders, accounts or problems? A receptionist is a narrow job with simple, predictable calls. Customer service is wide, the queries can be complex, and there's a lot more to set up and test.

Next, what does it need to reach? Does it only take a message, or does it use your other tools, like your calendar, your CRM, your email or your payments? Every tool it touches is more to connect, secure and test.

Then your data. Do you already have a database it can work with, or does your information live in spreadsheets and inboxes and need migrating first? Migrating adds work before the assistant can do anything useful.

Last, what kind of data is it dealing with, and how complex are the queries? Booking a time is simple. Looking up someone's job history, or handling personal or financial details, needs more care around privacy and security, and that takes more time to build.

Once you've worked that out, the cost breaks into three parts.

The setup comes first, and it's the larger sum. You pay it once. It covers building the assistant, connecting it to your tools and data, writing and testing its rules so it knows what to handle and what to leave alone, and tuning how it sounds.

The second is a small retainer for bug fixes and security updates. An AI that talks to your customers and touches your data needs looking after, like any other software.

The third is the running costs, which come from usage. Some of it is fixed, like the phone number and the platform plan, and some depends on how busy you are, like the minutes on calls, any texts it sends and the AI model behind it.

The setup is also where the price swings the most, and that comes down to how the work scales. As a rough rule of thumb, the first 80% of the questions and scope take about 20% of the development time, and the last 20%, the edge cases, take about 80% of it. By edge cases I mean how the agent interacts with your request and acts on it. Handling the common requests is the quick part. The time goes into everything that can go wrong when it acts: it books over an existing appointment, it changes the wrong customer's record, it does two things in the wrong order, it gets asked for something outside its job, or someone tries to talk it out of its rules. Every tool you give it adds more it can do, so it needs more guardrails and more testing, and there's more that can go wrong and break if it isn't developed properly. The bigger the scope, the more complex the queries and the more things there are to watch out for, the more this scales. A simple receptionist that takes details sits mostly in the easy 80%. An assistant with several tools and sensitive data spends most of its budget in the last 20%. That is why the price varies so much with scope and complexity.

For a small operation, the ongoing costs are usually in the hundreds of dollars a month. For a larger operation, they're in the thousands. Once it's built, that's insanely cheap compared to hiring a part-timer.

It depends on what the call is.

If it's a dispute, a complaint, or any call where you want to build a relationship with the customer, an AI is probably the wrong answer. If it's booking an appointment, checking on an order, or taking details for a callback, it can do the job today. Those are the calls that add the least value when a person takes them, and they're often the ones that get missed.

That wasn't true two years ago. Even booking an appointment was shaky, because the models weren't consistent enough to work with your database and your customer records, follow your company's rules, and resist anyone trying to talk them out of those rules. The voices were robotic too. Now the better models handle all of that, and the voices are natural enough to get past the uncanny valley. That matters, because the more human the voice, the more people connect with it, and connection is the experience you want your customers to have. The best models sound the most human, but they're slower to answer, which I'll get to.

So will people hang up on it? Some will. I've read the Reddit and Whirlpool threads, and the pattern is the same: people hang up the moment something breaks. What breaks is usually a question the AI should never have been left to answer. That's a setup problem. It comes down to what the AI is allowed to handle, what its guardrails are, and what happens when a caller steps outside them.

Our own receptionist is Tom, and I set him up myself. His job is to book appointments and take details for a callback. Tom doesn't announce that he's an AI, but he calls the owners of Fulcrum his “human overlords”, so it's no secret.

I gave him a bit of attitude and a dry Australian sense of humour on purpose. If I'm collecting details over two to five minutes, I don't want it to feel like a script, because then people may as well fill in a form. I want them to keep talking to hear what Tom says next. It's hard to tune. At one point I had him too sassy. There's a line between playful and serious, and he has to notice when someone is uncomfortable and ease off.

In my testing, somewhere between 5 and 10% of people didn't warm to him, and I was happy to lose them to keep the other 90% engaged. It was informal testing, so treat it as my experience, not a study. It depends on your business and your customers. If you're serious and corporate, or your caller is checking an order and wants it quick, jokes are the wrong call. Nobody in a hurry wants a robot telling jokes.

Where does a human come in? For Tom, nowhere: he takes details for a callback, and after hours there'd be nobody to hand over to anyway. For customer service you can set the AI to escalate to a person when it's unsure, when the question is complex, or when the caller asks for one after the AI couldn't help. I'd always honour that last one.

I'd be careful about giving customer service to a robot. The companies I'm most loyal to are the ones where I had a problem, spoke to a real person, and felt like a valued customer. I don't think AI will replace that. Even if it gets close, I don't think we'd appreciate it the same way, because a person isn't programmed to care and an AI might be.

Two technical things to know before you set one up.

Speed. The AI takes a moment before its first reply. On the smart model I run, it's about 5.75 seconds. A lighter model brings that down, and so do faster American voices. I recommend an Australian voice because Australian customers connect with it, and with one the first reply takes somewhere between 3 and 7 seconds. There are ways to cut that, like having it start a short opening line while it warms up.

Noise. If the caller is on speaker, somewhere loud, or has the TV on, the AI can mistake another voice, like the presenter on the TV, for the caller and answer it. You can filter out background noise, but if the filter is too aggressive it cuts the caller off, and if it's too light the AI reacts to the baby, the bird or the television.

So yes, an AI can answer your business phone and handle the basics, as long as you decide which calls it takes and what it does when it's out of its depth. As the models improve, the list of calls it can take will grow.