Should we buy another platform or build it in Microsoft 365?

The question usually gets answered by default

A process starts hurting. Someone finds a platform built for exactly that process, the demo is good, and the decision is made before anyone asks whether the organisation already owns something that could do it.

It usually does. A mid-market organisation on Microsoft 365 is already paying for lists, forms, workflow, document management, permissions and reporting. What it doesn’t have is those pieces built into the system its operation needs. That’s a build question, not a purchasing one, and it deserves the same scrutiny a new platform gets.

We answer it with five tests before we quote anything. Same five every time. They’re allowed to say buy.

The five tests

Is the process yours, or the industry’s?

Some processes are the same in every organisation that runs them. Payroll is the obvious one: the rules come from outside, they change on someone else’s schedule, and nobody wins by doing it differently. That’s what a platform is for.

Others are shaped by how you operate. How a new starter reaches every system they need on day one. How a hazard gets from a site to someone who owns it. A platform built for the average version makes you change the process to fit it. If the process is part of how you work, build it.

Where does the data already live?

If the people, the documents and the access already sit in Microsoft 365, a new platform means a second copy of all three and a sync to keep them in step. Every sync is a place for the two copies to disagree, and someone has to own the reconciliation when they do.

Built inside the tenant, there’s one copy. The staff record in Entra ID is the staff record. The document in SharePoint is the document.

Who has to use it, and are they already licensed?

A platform is priced per seat, and the seats are rarely just the people who run the process. Everyone who submits a request, approves one or needs to see the status needs a login. That’s where the cost of a platform tends to grow after the contract is signed.

Everyone in the tenant already has a login and a licence. A build uses those.

What will someone outside ask you to prove?

An auditor, a regulator or a funder doesn’t want to know that the process exists. They want the record: who did what, when, and against which version. If that record lives in a platform outside the tenant, producing it means an export and a reconciliation against everything else.

If it lives in SharePoint, it sits next to the documents it refers to, under the same permissions and the same retention.

What happens when you stop paying?

A platform you stop paying for takes the data with it, or hands it back in a format nothing else reads. A build in your tenant stays yours. There’s no licensing fee to TechRam, and the documentation and handover are part of how we scope and price the work, so your team can run it without us.

When buying is the right answer

The tests don’t always come out on the side of building, and a firm that tells you they do is selling something.

Buy when the process is the same everywhere and the vendor carries the compliance burden, as payroll software does. Buy when the volume or the complexity outgrows what Microsoft 365 is designed for: SharePoint lists have documented limits, including a 5,000-item list view threshold, and a design that ignores them breaks. And buy when nobody in the organisation will own a built system after handover, because an unowned build decays faster than a platform.

Often the honest answer is both: buy the core that is genuinely standard, and build the requests, approvals and registers around it inside Microsoft 365, so the platform doesn’t have to reach every person in the organisation.

A real one

Achieve Australia’s onboarding and offboarding ran as a chain of manual tasks across three teams, and IT, financial and cybersecurity audits had all flagged the same risk in it.

Two of the tests read straight off the record. The data already lived in three systems: JobAdder for recruitment, ELMO for HR and payroll, and Entra ID for identity and access. A fourth system would have been one more copy to keep in step. And the evidence test had already been failed, three audits over.

The build connected the three systems that already held the data into one pipeline, and every step is now logged and timestamped for the next audit. Six months in, 120 hours a month and $126K a year of operational cost had come back. You can read the full story.

Local Government Procurement came at it from the other side: it had already bought. Two off-the-shelf OKR tools were bought and abandoned, both lost to adoption friction, and then Microsoft retired Viva Goals. The tracker built on SharePoint lists in LGP’s own tenant went from prototype approval to an organisation-wide soft launch in under a month. That story is the buy test failed twice before the build.

Running the test on your own process

Pick the process you’re about to buy software for, and answer the five questions honestly. If three or more come out on the side of building, it’s worth an hour to find out what the build would involve before you sign anything. What the manual version costs you today is the number to put against the quote.

If you want a second opinion, that’s what a Custom Operational Apps conversation starts with. We’ll run the five tests with you. No demo. No licence quote. Just a straight answer about which way it falls.