Microsoft 365 automation: when to buy a product and when to build custom

Every mid-market team eventually hits a workflow that is too manual to ignore and too specific for any product to fix. Invoices retyped from PDFs into an ERP. A compliance register kept by hand. Email that someone triages every morning before real work starts. The question is always the same: do we buy a tool, or do we build something ourselves?

Both answers can be right. The expensive mistake is choosing on instinct. Here is a framework for choosing on evidence, and an honest view of what each path actually costs.

Buy when the problem is common

If your problem is one that thousands of other companies also have, someone has almost certainly built a good product for it, and buying is the right call. Security questionnaires, tenant security scanning, email threat protection, e-signatures, expense management: these are solved categories. A product gives you maintenance, updates, support and a roadmap you do not pay to build.

Buy when:

• The workflow is standard and you can adapt to the tool's way of working.
• An existing product covers most of what you need out of the box.
• You want predictable per-seat pricing and someone else owning the upkeep.

The trap here is the opposite of overbuilding: forcing a unique, valuable process into a generic tool that almost fits, and quietly losing the edge that made the process yours.

Build when the workflow is your own

Custom is worth it when the process is specific to your business, touches systems no product integrates with, or runs into rules that off-the-shelf software was never designed for. Four signals that you should build:

1. The workflow is a differentiator. It is part of how you actually win, not generic back office.
2. It crosses your own systems. A line-of-business application, an ERP, an industry database that no SaaS connector speaks to.
3. Regulation shapes it. EUDAMED registrations, ISO 27001 evidence, NIS2 controls, medical or financial audit trails, where the requirement is precise and the generic tool is vague.
4. The data cannot leave. When residency or sensitivity means content has to stay in your tenant or on local models, a public SaaS is simply off the table.

The honest test for building: would a generic product force you to change a process that is working

and valuable? If yes, build. If you are just avoiding a subscription, buy.

The hidden cost of "we'll build it ourselves"

Do-it-yourself automation rarely fails at the first version. It fails at maintenance. The script that one engineer wrote works beautifully until that person leaves, the API changes, an edge case appears, and nobody owns it. What looked free turns into a fragile dependency with no documentation and no runbook.

A real build is not just code that runs once. It is scoped requirements, error handling for the messy inputs, validation you can trust, and a handover so the thing survives the person who made it.

How a fixed-scope build should work

The risk in custom work is the open-ended project that drifts. A disciplined build removes that risk with a predictable path: a short discovery to define the problem, a small paid pilot to prove the approach on real data, a fixed-scope build with regular demos, and a handover where you receive the source code, the runbook and the repository. No lock-in, no surprise invoice.

This is what Olyteck Studio does for EU mid-market teams: senior engineers, fixed scope and fixed price, EU-hosted and GDPR-aligned by design, with local models when regulation requires and code you own at the end. It exists for exactly the cases where Cyber or Ask do not fit, and where a generic product would mean bending a process that should not bend.

A quick way to decide

• Common problem, standard workflow, predictable budget: buy.
• Differentiating process, custom integrations, strict regulation or data residency: build.
• Not sure: run a small pilot before committing to either. A pilot on your real data answers the question faster than any amount of debate.

Buy versus build is not a loyalty test for software. It is a fit question. Match the solution to the problem, count the maintenance cost honestly, and the right path is usually obvious once you stop deciding by reflex.