AI & Automation
Custom AI Development
Built, when bought will not do.
Custom AI development means building software for one organization when no off-the-shelf product does the job: a tool that answers questions from your own documents, a classifier that sorts incoming work, or a step that reads a supplier’s PDF and pulls out the fields. happier IT builds these for Canadian organizations of roughly 15 to 200 people, and says plainly when buying something existing would be cheaper.
Who it's for
Four situations where building is genuinely the right call.
The bar is high on purpose. A bought product has a support line, a roadmap and somebody else’s testing. A built one has us.
The knowledge people need is not in Microsoft 365. It is in a document archive, a line-of-business system, twenty years of project files, or a database. Microsoft 365 Copilot cannot see it, so no licence solves this. A retrieval tool over that content can.
The same judgement is made hundreds of times a week. Which team an incoming request belongs to, whether a claim is straightforward or needs review, which category a purchase falls into. Consistent, repeated classification is where a custom model earns its keep.
Documents arrive in a shape nothing reads. Supplier invoices in forty layouts, site reports, scanned forms. Extraction is a well-understood problem now and it is usually the highest-value custom build available to a company your size.
You tried a product and it fits at 70%. That last 30% is often an integration rather than a build. We check that before quoting anything, because it is usually a tenth of the cost.
When we say buy instead
If a product exists that does 90% of it, buy the product. You get a vendor’s testing, their security work, their updates and their support desk, and the 10% is usually a workflow around the edges.
We will tell you this even when a build would be the better invoice for us. A bespoke tool is a permanent commitment for both of us, and it should be entered on purpose.
What's included
The techniques, in plain English.
The words in this section are the ones you will hear in every sales meeting. Here is what each actually means and when it applies.
-
Retrieval-augmented generation (RAG)
RAG means the system searches your own documents first, then asks a language model to answer using only what it found, quoting the source. It is the right approach for "answer questions about our stuff", nothing is baked into a model, so a corrected document is corrected everywhere immediately.
-
Fine-tuning, where it is actually warranted
Fine-tuning means further training a model on your examples so it adopts a format, a tone or a specialist vocabulary. It teaches style and shape, not facts. It is rarely the answer for knowledge questions and often proposed when RAG would be cheaper, faster and easier to correct.
-
Document extraction and classification
Reading a document that arrives in an unpredictable layout, pulling out defined fields, checking them against a system of record, and flagging anything it is unsure about for a person rather than guessing.
-
Evaluation, before anyone trusts it
A test set of real examples with known right answers, scored before launch and re-scored after every change. Without this you have opinions about whether a system works. This is the step most often skipped and the one that decides whether it can be relied on.
-
A human step wherever the cost of being wrong is real
Confidence thresholds, a review queue, and a rule that anything below the line goes to a person. Designed in from the start, because retrofitting it after the first bad output is much harder and much later.
-
Model choice kept replaceable
Models change quickly and prices move. We build so the model behind a feature can be swapped without rewriting the application, and we will say when a smaller, cheaper model is sufficient for the task.
-
Deployment inside boundaries you have chosen
Where a build runs matters. Azure AI Foundry offers Regional deployments that keep inference inside the geography you choose, Data Zone deployments confined to the US or EU, and Global deployments processed anywhere. We pick with your obligations in mind, see <a href="/ai/governance/">AI governance</a>.
-
Documentation and an exit
Source code, architecture notes, the evaluation set, and a runbook. Written so another provider could take it over. A custom build that only we can maintain is a liability we sold you.
How it works
Prove it on real data before anything is built properly.
The first question is never how to build it. It is whether the accuracy is good enough to be useful, and that can be answered cheaply.
-
A short proof on your own data
Two or three weeks, real documents or records, measured against known right answers. Sometimes the answer is that it works well enough to matter. Sometimes it is that the data would have to be cleaned first. Both are worth knowing before a build budget exists.
-
Build the narrow version
One task, one team, a defined boundary and a review step. Narrow systems are more accurate, cheaper to run and far easier to evaluate. Scope creep in an AI build is not a schedule problem, it is an accuracy problem.
-
Measure, harden, hand over
Re-run the evaluation, tighten the thresholds, add monitoring and a defined failure path, write the documentation, and name an owner. Then either we run it under <a href="/managed-it-services/">managed IT</a> or you take it in-house with everything you need.
What it costs
Proof first, then a fixed-scope build.
Nobody should commit a build budget before knowing whether the accuracy is there. So we sell the finding-out separately.
The proof
The build
Running costs are real and ongoing. Model usage is billed by volume, so a system used a hundred times a day costs meaningfully more than one used ten times. We estimate it before you commit and monitor it after, because a runaway usage bill is the most common unpleasant surprise in this category.
Support and maintenance sit inside managed IT
The question to ask any AI developer
"How will we know it works?" If the answer is a demonstration, keep asking. The answer you want is a test set of real examples with known right answers, a score, and a threshold agreed before the build starts.
Demonstrations are chosen. Test sets are not.
Why us for this
Where we will talk you out of it.
Three honest limits, stated up front. A model will not fix data that disagrees with itself, if two systems hold different versions of the same customer, a confident wrong answer is the likely result and it is worse than no answer. A custom build for a process that changes every quarter will spend its life being rewritten. And anything that needs to be right every single time, with a legal or safety consequence, needs a person in it regardless of how good the accuracy looks.
The stated capability is broad, automation, custom builds, and most things a business would be looking for, and that is genuinely what we do. What we will not do is claim a build we have not done. Builds we have delivered include connections into software APIs that pull real-time information from several locations into one view, candidate processing for a human resources team, and automated skills coaching for professional development.
Where a build handles personal information, the privacy questions are not an afterthought, see AI governance and policy and compliance and risk.
Go deeper
- AI integration services Often the cheaper answer to the same problem.
- AI agents and assistants When the system needs to take steps, not just answer.
- AI governance and policy Where a build runs, and under what rules.
Questions
What people ask before they sign anything.
What is RAG (retrieval-augmented generation)?
RAG is a way of building an AI tool that answers from your own documents: the system searches your content first, then asks a language model to write an answer using only what it retrieved, with the source cited. Nothing about your documents is stored inside the model, so when you correct a document the answers change immediately. For "answer questions about our own material", RAG is almost always the right approach and fine-tuning is not.
Should we fine-tune a model on our data?
Usually not. Fine-tuning means further training a model on your examples, and it is good at teaching format, tone and specialist vocabulary, not facts. If the goal is answering questions about your documents, retrieval-augmented generation is cheaper, faster to change, and lets you correct a wrong answer by editing a file rather than retraining. Fine-tuning earns its place when the output has to follow a rigid house structure every time, or when a smaller, cheaper model needs to be taught one narrow job well.
How much does a custom AI build cost?
It is quoted in two parts. Budget separately for running costs, model usage is billed by volume and scales with how often the tool is used.
Is our data used to train the model?
It depends on the platform and the tier, and it is a question worth asking in writing. Microsoft states that for Azure OpenAI models, prompts, completions, embeddings and training data are not used by model providers to improve their models or services, and are not used to train foundation models without your instruction. Microsoft also states that Microsoft 365 Copilot prompts, responses and Microsoft Graph data are not used to train its foundation models. Consumer tiers of other services frequently say something different, which is why we build on business platforms with contractual terms rather than on a personal account.
How accurate is it going to be?
Nobody can answer that before testing on your data, and any provider who gives you a number in the first meeting is quoting someone else’s benchmark. What we can commit to is measuring it: a test set of real examples with known right answers, a score before launch, a threshold agreed in advance, and a review queue for anything the system is unsure about. Where the accuracy does not clear the threshold, the honest outcome is that we do not build it.
What happens if you stop supporting it, or we change providers?
You get the source code, the architecture notes, the evaluation set and a runbook, written so another provider can take it over. That is part of every build rather than something negotiated at the end. A custom system only we can maintain would be a liability we sold you, and it would make it much harder for us to give you honest advice about whether to build in the first place.
Can you host it in Canada?
Often, and it depends on the platform and the model. Azure AI Foundry offers Regional deployments where inference happens only within the geography you choose, Data Zone deployments confined to the US or EU, and Global deployments that may process anywhere. Data stored at rest sits in the geography of the resource you create. Which specific models are available in a Canadian region changes over time, so it is checked at design time rather than assumed. See AI governance and policy for the wider data-residency question.
Related
Where to go next.
Want to know what this would look like for you?
A 30-minute call. No slides, no audit fee, no obligation. We ask what is breaking and tell you honestly whether we are the right fit.