Most founders come to us wanting to add AI to their product. They’ve seen a competitor ship a copilot feature, or a customer asked why there’s no “smart” anything in the dashboard, and now there’s pressure to move. The instinct is to start scoping the AI layer. That’s the wrong starting point. What you actually need to do first is audit what you already have – because roughly half the SaaS products we look at aren’t ready for AI to sit on top of them, and building anyway just creates a faster path to an expensive mess.
This isn’t a scare post. It’s a working guide to the audit we run internally before we recommend any AI build to a founder who already has a live product. Some of it takes a week. Some of it takes an afternoon. But skipping it costs you months.
What “AI Readiness” Actually Means (It’s Not What You Think)
There’s a temptation to frame AI readiness as a question of infrastructure – do you have GPUs, do you have a vector database, are you on the right cloud. That’s not it. Those are procurement questions and they’re easy to answer once you know what you’re building.
Real AI readiness is about three things:
- Data quality and structure. Does your product capture the right events, in a consistent shape, with enough signal to actually train or retrieve against?
- Architectural separation. Is your business logic decoupled enough that you can insert an AI layer without re-engineering half the application?
- Feedback loops. Do you have any mechanism to measure whether an AI output was useful, ignored, or harmful – or would you be flying blind post-launch?
If any of those three are broken, adding AI doesn’t make your product smarter. It makes it unpredictably wrong at scale, and now your support queue is full of confused customers asking why the “smart” feature gave them garbage.
The Data Audit: Where Most Products Fail First
Pull up your database schema and your event tracking side by side. Ask yourself a blunt question: if you had to explain to a model what a user did over the last 30 days, could you reconstruct that story from what you’re actually storing?
More often than not, the answer is no. We see products where key actions – a user editing a record, abandoning a flow, changing a setting – were never instrumented because nobody thought they’d matter. They didn’t matter for the original product. They matter enormously for AI.
The specific things to check during a data audit:
- Event completeness. Are user actions logged with timestamps, user IDs, and contextual metadata? Or are you only storing the final state of a record with no history of how it got there?
- Schema consistency. If you’ve been running for more than two years, you almost certainly have fields that mean different things in different rows, nullable columns used inconsistently, or free-text fields where structured data should live. Each one is a retrieval problem waiting to happen.
- Volume and recency. For anything involving personalisation or recommendation, you need meaningful per-user activity – typically at least 30-90 days of consistent data before pattern-matching becomes useful. Many early-stage SaaS products simply don’t have the depth yet.
- PII exposure. This matters more in Australia than founders sometimes realise. If your AI layer is going to process or surface personal information, you need to know exactly where it lives, whether it’s appropriately encrypted at rest, and whether your AI vendor’s data processing agreements are compatible with your Privacy Act obligations.
Don’t paper over gaps with “we’ll fix it during the build.” Fix it before the build. A data remediation sprint – cleaning schemas, backfilling events, establishing a proper event stream – typically runs $8,000-$18,000 depending on the state of things. That’s painful. It’s still less painful than building an AI feature that doesn’t work because the inputs were wrong.
The Architecture Audit: Can You Actually Insert an AI Layer Here?
This is where you need someone technical to be honest with you. A lot of SaaS products – particularly ones that grew quickly in their first 18 months – have business logic scattered through the codebase in ways that make surgical additions genuinely difficult.
The warning signs are specific:
- Business logic living in frontend components rather than in an API layer
- No clear service boundaries – everything talks to everything via direct database calls
- Monolithic background job queues where it’s hard to add a new async step without touching shared infrastructure
- No API versioning, which means adding AI-driven endpoints risks breaking existing integrations
What you’re looking for is a clean answer to: where would an AI inference call actually sit in this system? It needs to be asynchronous (you don’t want a user waiting 4 seconds for a page load because you’re hitting an LLM), it needs to be isolated enough that a model failure doesn’t cascade into core functionality, and it needs observable enough that you can log inputs and outputs for debugging and compliance.
If your architecture doesn’t have a natural place for that, you have a refactoring job ahead of the AI build. The refactor is usually smaller than founders fear – often two to four weeks of focused work, $12,000-$25,000 – but it has to happen first, not concurrently. Building the AI layer on top of an unprepared architecture is how you end up rewriting both six months later.
The Feedback Loop Problem Nobody Talks About
Here’s the part of AI readiness that almost never comes up in scoping conversations, and it’s the part that determines whether your AI feature improves over time or quietly gets ignored by users.
Every AI output in production needs a signal. Did the user act on it? Did they dismiss it? Did they edit it? Did they never open it? Without that signal, you have no way to know if the model is performing, no way to fine-tune, and no way to justify continued investment.
The feedback mechanism doesn’t have to be complex. A fintech we shipped last year used nothing more than a thumbs up/down on AI-generated summaries, tied to the user ID and the input context. That’s it. Six months in, it was the most valuable dataset they had – clear signal on which types of queries the model handled well and which needed a prompt rework or a retrieval change.
Before you build, design the feedback loop. It should be a first-class feature, not an afterthought. Ask: what does a “good” AI output look like in this product, and what user behaviour would indicate it was useful? Build to measure that from day one.
What the Audit Actually Produces
A proper AI readiness audit isn’t a report that says “you’re ready” or “you’re not.” It produces a prioritised list of pre-work – the specific things that need to be true before the AI build starts – with effort estimates attached to each.
Typically that list has three tiers:
- Blockers. Things that will prevent the AI feature from working at all if not addressed – usually data structure issues or architectural coupling problems.
- Quality risks. Things that won’t stop the launch but will make the outputs unreliable or the product hard to improve – often incomplete instrumentation or missing feedback hooks.
- Nice to haves. Things that would improve the AI experience but can be deferred to a second sprint without compromising the initial launch.
That tiered list is what lets you make an actual decision: do we fix the blockers and ship, do we do a fuller remediation pass first, or is the pre-work so substantial that we should reconsider the scope of the AI feature entirely?
We’ve had audits come back clean – product ready, data solid, architecture sensible, go straight to build. We’ve had audits reveal that what the founder wanted would have required essentially rebuilding the data layer before any AI was possible, and the honest conversation was that a different, narrower AI feature would deliver 80% of the value for 20% of the work. Both outcomes are useful. Neither wastes a sprint on something that wasn’t going to work.
How Long Does This Take and What Does It Cost
A focused AI readiness audit for an existing SaaS product – done properly, by someone who can read the codebase, interrogate the data model, and map the architecture – takes between three and five days of senior technical time. In Australian terms, budget $4,000-$9,000 for a thorough audit from a team that actually knows what they’re looking for.
That number makes some founders wince. The comparison to make isn’t “audit vs nothing.” It’s “audit vs the cost of discovering mid-build that your data model can’t support what you’re trying to do.” We’ve seen that conversation happen at the $60,000 mark. The audit was suddenly very cheap in retrospect.
If you’ve got a live product and you’re seriously considering an AI feature, don’t start with a pitch deck or a feature list. Start with the audit. And if you want a second set of eyes on what you’re working with, talk to Amora about your build – we’ll tell you straight what’s ready and what isn’t.
The AI layer is the interesting part. But interesting doesn’t ship on a broken foundation.
Got something you want built?
Amora Digital is an Australian software and AI agency. We scope it, build it, and ship it – live in 28 days. No offshore teams. No surprises.