Planning an AI Engagement: What Production Delivery Requires

Starting an AI initiative is a commitment of budget, engineering time, and organisational attention. The organisations that get the most out of that investment tend to do the same thing early: they define what "production-grade" means for their context before any code is written. This guide sets out the standards worth establishing at the scoping stage, drawn from how we approach ai engineering work at Horizon Labs.

What Does Production-Grade AI Delivery Actually Look Like?

A production AI system is one that keeps running after the initial launch — handling real traffic, real data quality issues, and the inevitable drift between training conditions and live conditions. That's a different bar to a proof-of-concept, which only has to work once, in a controlled demo. Before scoping any engagement, it's worth agreeing internally on what "done" means: Is it a model that returns a correct answer in a demo? Or a system your team can monitor, retrain, and hand off in twelve months? Being explicit about this upfront avoids a common source of disappointment later.

Why Production Track Record Matters More Than a Demo

A working demo tells you a model can produce an output under ideal conditions. It doesn't tell you much about latency under real load, cost at scale, or what happens when an underlying model provider changes its API — all of which surface only once a system is live. When we talk to prospective clients, we point them to systems we've had running in production for extended periods, not just pilots, because that's the evidence that actually predicts what an engagement will feel like six months in. If you're planning your own AI roadmap, it's worth applying the same standard to any reference case studies you look at, including ours.

Moving From Proof-of-Concept to a System That Stays in Production

Most AI initiatives that stall do so at the same point: the proof-of-concept works, but nobody has planned for the harder problem of running it continuously. Data pipelines break. Models degrade as real-world inputs shift away from training data. Edge cases surface that no demo environment reveals. Our own AI readiness assessment work exists largely because this gap — between a working prototype and a maintainable system — is where most of the real engineering effort sits. Budgeting time and attention for that stage, rather than treating launch as the finish line, is one of the more reliable predictors of whether an AI project delivers lasting value.

Avoiding Lock-In: Building on Portable, Standard Tooling

Lock-in happens when a system can only be operated, extended, or migrated by the people who originally built it — through proprietary tooling, undocumented pipelines, or a closed platform with no data export path. This is worth planning for regardless of who builds the system, including us. Ask what happens if you want to bring the work in-house or move providers in two years. A well-built system documents its architecture, favours standard tooling over proprietary lock-in, and leaves you with code and infrastructure your own team can run. This is part of why we frame our engagements around application modernisation principles even for greenfield AI work — the goal is always something you own and can maintain.

MLOps: Planning for What Happens After Launch

MLOps is the discipline of deploying, monitoring, and maintaining machine learning models once they're live — including drift detection, retraining triggers, and rollback procedures. A model that performs well at launch can quietly degrade months later as real-world data shifts. Any AI engagement scope should include an answer to "what happens after launch," not just "how do we get to launch." Our MLOps consulting work goes into more detail on what a credible post-launch plan should cover.

Getting IP Ownership Right From the Start

Intellectual property terms should be unambiguous before work begins, not negotiated afterwards. Confirm in writing that code, trained models, and data pipelines built for your business belong to your company, unless you've deliberately agreed to a different licensing arrangement. IP Australia provides general guidance on IP rights, and it's worth having legal counsel review any contract clause specifically for model weights and training data ownership — general services agreements often don't address these directly.

SaaS Product or Embedded Engineering: Two Different Ways to Solve a Problem

Some AI problems are best solved with a packaged product; others need bespoke engineering tailored to your architecture and data. Neither approach is inherently better — the right choice depends on the problem.

	Packaged SaaS AI product	Embedded AI engineering
Strategic advisory	Usually not included	Part of the engagement
Architecture	Fixed by the product	Tailored to your stack
Code ownership	You operate their tool	You own the code
Team capability transfer	Minimal	Your team learns the system
Customisation	Limited to product roadmap	High

Our ai product strategy work usually starts by helping a team work out which model fits their problem — sometimes the answer is a product, sometimes it's a custom build, and sometimes it's a mix of both.

A Practical Checklist for Scoping Your Next AI Engagement

Before committing budget to an AI initiative, it's worth working through a short list internally:

• Define what "production-grade" means for this specific system — not just what a successful demo looks like.
• Ask for a written MLOps and monitoring plan alongside the delivery timeline.
• Confirm IP ownership terms in the contract, reviewed by your own legal counsel.
• Check whether the build uses portable, standard tooling.
• Decide, deliberately, whether a packaged product or bespoke engineering fits the problem better.

These aren't hurdles to clear before you can start — they're the groundwork that makes an AI initiative something your team can run long after the initial build. For more on how we think about this, browse more insights from our team.

If you're scoping an AI initiative and want a second opinion on the plan, get in touch. We're happy to talk through what production-grade would look like for your specific system, whether or not that ends up being a project with us.