AI Software Development: 8 Questions to Ask Before Starting Your First Project

Key Takeaways

• AI software development is the work of designing, building and running software where a model makes predictions, generates content or decides something, instead of following rules a developer wrote by hand.

• Most first projects fail for boring reasons. RAND found more than 80% of AI projects fall over, with leadership misunderstanding the problem and thin data as the two biggest causes.

• Answer eight questions before you brief anyone: the problem, the data, build or buy, the measure of success, running costs, accountability, codebase readiness, and the shape of the first 90 days.

• A narrow AI proof of concept done in six to eight weeks tells you more than a six-month strategy document and costs a fraction of one.

• Australian obligations are tightening. The Voluntary AI Safety Standard and new automated decision-making transparency rules both belong in your scoping conversation, not your launch retro.

There is a meeting that seems to happen in Australian startups and SMEs about once a quarter now, and it always plays out the same way: someone shares a competitor's new feature on the screen, everyone watches it summarise and predict and answer questions in plain English, and then a voice from the end of the table asks why we don't have that yet.

It's a fair question. The more useful one, though, is what it would take to build the thing properly, and what happens to the business if we get it wrong.

RAND Corporation put that second question to 65 experienced data scientists and engineers and found that more than 80% of AI projects fail, roughly twice the failure rate of IT projects that don't involve AI. The reasons were mundane rather than technical. Leadership asked for the wrong thing, or the data was never going to support what was being asked of it.

What follows are the questions we work through with founders before anyone plans a sprint. None of them need a technical background to answer, and every one of them has saved somebody money.

What Is AI Software Development?

AI software development is the practice of building software in which a machine learning model produces part of the output, rather than a developer writing explicit rules for every outcome. The model learns patterns from data, then applies them to new inputs.

That difference matters more than it sounds. Traditional software is predictable: the same input returns the same output, every time. An AI feature gives you a probability wearing the costume of an answer. Your architecture, testing, interface design and support process all have to account for that.

The machine learning development process runs on a different rhythm too. Instead of design, build, test and ship, it goes more like: find the data, clean the data, configure the model, measure how often it's wrong, decide whether that's acceptable, and only then think about shipping.

Question 1. What Problem Are We Solving, and Is AI the Cheapest Way to Solve It?

Of RAND's interviewees, 84% pointed at leadership-driven failure as a primary cause, well ahead of anything else, and the shape of it is usually the same: a brief arrives asking the team to use AI to improve customer service when the thing really costing the business money is four people spending ninety minutes a day copying order details from one system into another.

So, write the problem down as a sentence with a number in it. Something like "our support team answers roughly 400 repetitive emails a week, and each one takes about six minutes." That version can be argued with, measured, and eventually proven right or wrong, which the original brief cannot.

While you're at it, check whether plain rules get you most of the way. One RAND interviewee described being handed datasets with a handful of dominant patterns and asked to apply machine learning, when a few if-then rules would have done the job for a fraction of the cost.

We ran into a version of this on CosMe, a health and wellness shopping app where users set up an allergen profile and see products matched to their sensitivities. Described out loud, that sounds like a recommendation engine. What it needed was structured ingredient and allergen data, a traffic-light warning system so people could read a product at a glance, and a fast search layer, and the mobile build was finished inside a month. A model would have added cost and uncertainty to a problem that good data and clear rules had already solved.

So if a decent filter and a working search function handle 70% of the volume, build those first and spend the AI budget on the difficult 30%.

Question 2. Do We Have the Data This Needs, and Can Anyone Reach It?

Data is the second most common killer and the one founders underestimate most, partly because every business believes it has good data. The uncomfortable finding in RAND's work is that the belief usually comes from receiving weekly reports, which says nothing about whether the underlying records were ever structured in a way a model can use. Legacy data tends to record what happened without recording why, and the why is normally the part that matters.

Four things to confirm before anyone writes code:

• Where it lives. Count the systems honestly, including the spreadsheet somebody maintains by hand.

• Whether it can be reached. An API connection is a project. A weekly manual CSV export is a liability.

• Whether it's consistent. Three spellings of the same supplier will confuse a model faster than a person.

• Whether it's yours to use. Customer data carries obligations that don't disappear because the processing moved to a model.

Thin data doesn't always kill a project, but it changes the approach, usually towards retrieval instead of training: the app searches your own documents, pulls the relevant passages, and hands them to a general model alongside the question.

Question 3. Should We Build, Buy, or Blend?

Very few SMEs need to train a model from scratch in 2026. Most custom AI applications today are custom plumbing, interface and data work wrapped around a general-purpose model somebody else trained.

Timeframes assume a reasonably modern codebase and data you can reach.

Most SMEs land on rows two and three, often combining them. If someone proposes row four for a first project, ask to see the dataset before the quote. Our breakdown of the real numbers behind a build-versus-buy decision pairs well with this one, and if you’d rather talk the options through with engineers who build these for a living, that’s what our AI software development team does.  

Question 4. How Will We Know If It Worked?

This is the question people answer with adjectives when they should be answering it with numbers. "Better," "faster," and "smarter" cannot be tested in week nine, so put the definition in writing before anything is built. The assistant drafts a reply a human approves without edits 70% of the time. Invoice coding reaches 95% accuracy against a checked sample of 500. Average handling time drops by four minutes.

Then agree on the acceptable failure rate, which almost nobody does, and which turns out to govern most of the design decisions that follow. A tool drafting internal notes can be wrong now and then without anybody getting hurt. A tool quoting prices to customers cannot. Where you set that line determines how much human review sits in the workflow, and review costs real money, so it belongs in the budget conversation rather than being discovered later.

Adoption is the measure that gets forgotten. A feature that performs beautifully and sits unused has failed, whatever the accuracy numbers say, so track usage from the first week alongside everything else.

‍

‍

Question 5. What Does This Cost Once It's Live?

Here is where AI parts company with the software you're used to buying. Traditional features cost what they cost to build and then run for very little; AI features keep charging you per use, because model providers bill by the token, which is roughly a fragment of text going in or coming out. A feature that costs a few dollars a day while three people test it can quietly reach thousands a month once every customer hits it ten times a day.

Ask your development partner for a cost model built on realistic volumes rather than test volumes, then ask for four controls: hard spending caps agreed with the provider, caching for repeated questions, cheaper models on the simple jobs like tagging and sorting, and an alert when daily spend crosses a line you set yourself.

Maintenance is the second cost and the quieter one. Models get deprecated, prompts drift, source documents go stale, and accuracy decays without anyone noticing until a customer complains, so budget for someone to look at the numbers every month. Our guide to calculating ROI before you build runs through the full ownership picture.

Question 6. Who Is Accountable When the AI Gets It Wrong?

Worth saying plainly: every AI feature will produce a wrong answer at some point, so the question is not whether that happens but who is holding the bag when it does.

Australia's regulatory settings have moved a fair way in two years, and SMEs are in scope more often than they expect. The federal government's Voluntary AI Safety Standard sets out ten guardrails covering accountability, testing, transparency and record-keeping, written for organisations using AI, not only those building models. It aligns with AS ISO/IEC 42001 and the NIST AI Risk Management Framework, so adopting it now means less unpicking later.

Privacy obligations apply the moment a feature touches personal information. The OAIC's guidance on commercially available AI products asks for due diligence on any AI product you adopt, a privacy-by-design approach including a Privacy Impact Assessment, and as best practice, keeping personal and sensitive information out of publicly available generative AI tools.

The practical version for a first project is short: name someone who owns the feature, log every model call and its output, keep a human in the approval loop for anything customer-facing, and write down what the feature may and may not do. That last document takes an afternoon and is the first thing anyone will ask for when something goes sideways.

Question 7. Can Our Existing Software Support an AI Feature?

This is the question that decides whether you are looking at an eight-week build or an eight-month one, and no honest answer to it comes out of a sales call.

Older systems tend to hit the same few walls. A tangled codebase offers nowhere clean to plug anything in. Synchronous request handling means a model call taking seven seconds freezes the screen while the user stares at it. Dated frameworks don't support the current provider SDKs. And where there are no automated tests, there is no safety net at all once AI work starts touching checkout or sign-up, which is exactly where it tends to end up.

A ready application has a clear API layer, support for background jobs or streamed responses, logging you can extend to track model calls and spend, and server-side storage for API keys. Never ship a key inside a mobile app.

Missing a few of those isn't fatal, since a small separate service can usually sit beside the existing system and do the AI work while the core app carries on untouched. Working out which path fits is the job of a technical discovery phase, and it costs far less than finding out in month four.

If the original developers are long gone and nobody left in the building fully understands the codebase, bolting AI onto it is the expensive path dressed up as the quick one. Getting a stalled or inherited build back under control almost always costs less than forcing new features onto foundations nobody trusts.

SoulConnect is a reasonable illustration of the order these things happen in. The visible parts are the AI features: compatibility scoring that learns from how people behave, chat prompts, a date planner that suggests where and when to meet. Making those work took a modular REST API layer on the backend, token-based authentication, encrypted data and admin moderation tools, plus load and security testing before anything reached the app stores. The intelligence was the easy half to describe and the smaller half of the build.

If the product is still taking shape, it's far cheaper to build AI in from the first sprint than to retrofit it in year two.  

Question 8. What Do the First 90 Days Look Like?

An AI proof of concept is a small, time-boxed build that exists to answer one question: can this work with our data, at our quality bar, at a cost we would accept? It is not a demo for the board, and it is not a pilot. Its real job is to kill bad ideas cheaply, which is a harder sell internally than it should be.

This is where plenty of organisations come unstuck. S&P Global Market Intelligence surveyed more than 1,000 enterprises and found the share abandoning most of their AI initiatives jumped to 42%, up from 17% the year before, with the average organisation scrapping 46% of proofs of concept before production. Cost, data privacy and security topped the obstacles. The lesson isn't that proofs of concept are a waste. It's that one scoped without a production path is a dead end dressed as progress.

A workable 90 days looks roughly like this:

• Weeks 1 to 2. Pin down the problem, audit the data, agree on the success number and acceptable failure rate.

• Weeks 3 to 6. Build the narrowest version that could work. One use case, internal users only.

• Weeks 7 to 9. Measure against the agreed number. Read the errors rather than glancing at the average.

• Weeks 10 to 12. Decide: expand, change approach, or stop. All three are good outcomes if the data supports them.

Treat stopping as a legitimate result rather than a failure, because twelve weeks and a modest budget spent learning that AI isn't the right tool for this particular problem is a good trade against a year and a six-figure write-off.

Your Pre-Project Checklist

Run through this before you brief a developer. If you can't tick at least seven, close those gaps first.

☐ We've written the problem as one sentence containing a real number

☐ We've checked whether simpler, non-AI logic solves most of it

☐ We know which data the feature needs, where it lives, and that it can be reached by API

☐ We've agreed on the success measure and the acceptable error rate

☐ We've chosen build, buy or blend, with reasons we can defend

☐ We have a running cost estimate at realistic volumes, plus spending caps

☐ One named person owns the feature and its outputs

☐ We've checked our privacy obligations and the Voluntary AI Safety Standard guardrails

☐ Our codebase has an API layer, logging and server-side key storage

☐ The first version is scoped to 90 days, with a genuine option to stop  

Where Australian SMEs Sit Right Now

Some context before you decide you're behind. The National AI Centre's SME AI Pulse found 44% of Australian SMEs reporting some level of AI adoption in February 2026, the strongest result in several months. Broad adoption across several parts of the business hit a seven-month high while one-off experiments faded, which tells you something useful: businesses that commit properly tend to keep going, and the ones dabbling drift away.

This means you are neither late nor early. You're mid-pack, and mid-pack is a perfectly reasonable place to be deliberate from.

In our experience, the teams getting real value out of AI software development rarely have the most impressive demos. They picked one expensive, annoying problem, checked that the data could support solving it, shipped something narrow, measured it honestly even when the numbers were unflattering, and only expanded once those numbers held up over a few months.

None of that is complicated. It just requires answering eight questions before the first sprint rather than discovering them somewhere around the fourth.

‍