Build on Microsoft 365 or Buy? Choosing the Tools That Run IT

If your company runs on Microsoft 365, someone has probably already built something with it. A SharePoint list that tracks laptops. A Teams channel where staff post IT requests. A Power Automate flow that emails the IT person when a new hire starts. It cost nothing extra, it went up in an afternoon, and it mostly works.

Then the question comes up: should you keep building on it, or pay for a tool made for the job? For the tools that run IT itself, such as the help desk, asset inventory, onboarding and offboarding, and vendor and contract tracking, the answer matters more than it first appears.

Why this is worth revisiting now

On September 9, 2026, Microsoft announced its first list price increase in more than five years for Power Apps Premium, the license needed for the more capable custom apps. The standard plan rises from $20 to $22 per user per month, effective January 1, 2027. Existing subscriptions keep their current price until the end of their term, and the Power Apps and Power Automate rights included in Microsoft 365 plans are not affected.

The increase is modest, but it is a reminder: the “free” option is only free while you stay inside what Microsoft 365 includes. Beyond that, a homegrown tool becomes a per-user subscription like any other.

What “free” actually includes

Microsoft 365 licenses come with rights to use Power Apps and Power Automate with what Microsoft calls standard connectors, a list that includes SharePoint, Microsoft Teams and Office 365 Outlook among many others. Microsoft’s licensing FAQ, last updated in August 2026, is clear about the line: a standalone Power Apps or Power Automate license is required for premium, on-premises and custom connectors. Connectors to SQL, Azure and Dynamics 365 are classified as premium.

Microsoft also offers Dataverse for Teams, a built-in database for apps inside Teams. Each team’s environment holds up to about one million records, that capacity cannot be purchased separately, and custom connectors are not supported. If an app there uses a premium connector, every user of the app must be licensed for it.

That matters for IT tools. A help desk is used by everyone, so if one feature needs a premium connector, the license question applies to every employee who submits a ticket.

Where building on Microsoft 365 makes sense

Building is a reasonable choice when most of these are true:

The process is simple and stable. An approval with two steps, a short checklist, a list of a few hundred items.
It stays inside standard connectors. SharePoint, Teams and Outlook, with no need to reach a database or another vendor’s system.
A small group uses it. The IT team or a handful of managers, not the whole company.
Losing it would be an inconvenience, not an outage. If it broke for a week, people could fall back on email.
More than one person can maintain it, and how it works is written down.

Many offboarding checklists and simple request forms fit this description.

Where a purpose-built tool usually wins

The case for buying grows when the tool needs to do what dedicated products already do well:

Service desk work. Queues, priorities, response targets, escalation, reporting on how long things take, and a portal staff will actually use.
Asset management. Automatic discovery of devices, warranty and lifecycle dates, and links to who has what. A list someone updates by hand drifts out of date.
Audit and security evidence. If an insurer or auditor asks who was granted or removed access, and when, you need a reliable history. Purpose-built tools are generally designed to keep one; a homegrown list keeps only what someone remembered to record.
Integrations. If the tool needs to talk to your HR system, device management or MSP’s platform, you are likely in premium connector territory, and building those links yourself means maintaining them yourself.

Who supports it: you, or the vendor

This is the question that usually decides it. When you build a tool, you become its software vendor. Your people fix it when it breaks, change it when the process changes, check it after every Microsoft update, and answer questions from the staff who use it. When you buy, the vendor’s people do that work. Fixes, security updates and new features arrive without your team writing them, and there is a support desk to call.

For most mid-sized companies, IT matters a great deal but is not what the business sells. A manufacturer competes on what it makes, how well and how fast, not on how it routes help desk tickets. Every hour your small IT team spends maintaining a homegrown ticketing app is an hour not spent on the plant floor systems, security or projects that move the business. Building makes sense where the tool gives you an edge; for routine IT administration, it rarely does.

Buying does not remove all the work. Someone still has to set the tool up, configure it and own it. But configuring a product is a much smaller job than maintaining one.

The cost nobody puts in the spreadsheet

The license is rarely the largest cost of a homegrown tool. The larger costs are:

Key-person risk. Most of these tools are built by one capable employee. When that person leaves, the company often finds no one understands the flows, and some run under the departed person’s account.
Governance. Apps and flows built by staff can quietly move company data to places IT did not plan for. Someone has to keep an inventory of what has been built, who owns it and what it connects to.
Getting your data out. Moving years of tickets or asset records into a new system later is a project in itself.

A purpose-built tool has its own costs, including subscription fees, price increases and the effort to set it up well. The honest comparison is total cost over three years, including people’s time, not license price against zero.

Questions to ask before you build, or keep building

Is this tool part of what makes us competitive, or is it routine administration?
Who besides the builder can fix this if it breaks next Monday?
Does it run under a personal account, or a shared service account the company controls?
Does it use, or will it soon need, any premium or custom connector? If so, which users would need a license?
How many records will it hold in three years, and does that fit the platform’s limits?
Could you produce an audit trail from it for an insurer or auditor?
What would a purpose-built tool cost per year, and what would it replace in staff time?

If the answers point to “build,” build it deliberately: document it, assign an owner, and review it each year. If they point to “buy,” choose against your requirements rather than the strongest sales pitch.

If you would like an independent view on which of your internal tools to keep, replace or retire, get in touch.