Add AI to the Software You Already Run, Without Rebuilding It

The best first features remove a task users already do by hand inside your app. Common starting points are semantic search that finds records from a plain language description, summaries of long histories such as tickets, cases or notes, extraction of fields from uploaded documents into forms, and a help assistant that answers questions about the screen the user is on. We usually recommend starting with one feature where the output is easy to check, measuring it properly, and adding the next one once the first has paid for itself.

No. In most cases the AI capability is added as a small service or module that your existing application calls through an internal interface. The rest of the app, including its database, authentication and hosting, stays as it is. A rebuild only makes sense if the application is already due for replacement for other reasons, in which case our legacy modernisation service is the better starting point.

Every build is priced on its own scope. It starts with a Discovery Audit (a fixed fee, credited in full against the build). After the audit you get a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete. The option you choose is paid in three stages against work you have accepted. We never publish day rates. Running cost is separate from the build: it depends on volume, model tier and caching, and we estimate it per request during the first week. Our guide on the cost to add AI to an existing app breaks down the drivers in more detail.

Cost control is built in from the start rather than added later. We measure cost per request during prototyping, route simple requests to smaller and cheaper models, cache repeated prompts and responses, trim the context sent to the model, and set budgets and rate limits per user and per tenant. Spend alerts go to your team, and the feature flag gives you an immediate off switch if something unexpected happens.

Providers release new versions and retire old ones regularly, so we design for it. Your app talks to our AI service, not directly to a provider, and the evaluation suite lets you test a new model against your own examples before switching. A model change becomes a measured configuration change behind a flag rather than a surprise in production.

Often, yes. The major cloud AI platforms offer some models in Australian regions, but which models are available where changes frequently, so we check the vendor's current regional availability for your chosen model at the start of the project. Where a required model is not available onshore, we explain the tradeoff and the options, including open weight models hosted in your own Australian cloud account.

It can. From 10 December 2026, APP entities must describe in their privacy policy the kinds of decisions a computer program makes, or substantially and directly contributes to, that could significantly affect a person's rights or interests. If an AI feature scores, ranks or flags people, we log what it did and help you document it so your privacy team can assess it. This is general information, not legal advice.

Yes. We integrate models from OpenAI and Anthropic directly or through Amazon Bedrock, Azure OpenAI and Google's Gemini Enterprise Agent Platform, and open weight models where data must stay in your own cloud account. The model sits behind a small AI service your app calls, so switching provider or model later is a configuration change tested against your evaluation set, not a rewrite.

Usually, yes. The AI capability lives in a small service, typically TypeScript on Node.js or Python, that your application calls through an internal API. That means an app built in .NET, Java, PHP or another language can gain AI features without its core code changing much, and your team keeps working in the language it knows.

A single well scoped feature typically takes around nine to ten weeks from codebase review to general release, including the evaluation set, integration behind a feature flag, staged rollout and handover. Simple features with easy to check output can be quicker; in app assistants that take actions take longer because they need more safety testing. Every build starts with a Discovery Audit, a fixed fee credited in full against the build. After two strategy sessions you receive a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete.

It depends on request volume, model tier and how much text each request sends, so we measure it rather than guess. Providers charge per token and change prices often, so we estimate your cost per request in the first week of the project using realistic prompts from your app. Routing simple requests to smaller models and caching repeated ones are the main levers. Our guide to LLM running costs has worked examples.

Yes, through their APIs rather than inside the products themselves. We build a small AI service that reads and writes through the platform's API, for example drafting job notes from a ServiceM8 or simPRO job, or suggesting categories for transactions before they reach Xero. Each vendor controls what its API exposes and any connection fees, so we check those limits before scoping. If the product's own AI feature already does the job, use that first.

Not if the integration is set up correctly. We call models through enterprise APIs or cloud platforms such as Amazon Bedrock and Azure OpenAI, select the settings that exclude your content from training where the provider offers them, and document the terms that apply. Where data must not leave your environment at all, an open weight model can run in your own cloud account instead, at the cost of more hosting work.