Compare Building inside Microsoft 365 vs. owning the platform
If your business already runs on Microsoft 365, building the missing app inside it is a sensible instinct and frequently the right one. The thing worth being precise about is what ownership means when the app only runs in the place it was built.
Side-by-side comparison
| A platform you own | Built inside Microsoft 365 | |
|---|---|---|
| What you hold | The source, the schema and the data - portable to any host | Your tenant, your data and the app definition, inside Microsoft’s runtime |
| What keeps it running | Infrastructure you can re-point or move | Licensing - per user, and the premium tiers some connectors require |
| Cost shape | A build from $8,500, then $80/month self-run or $450/month managed | Per user per month, rising with seats and with the connectors you add |
| Identity, audit and policy | Built to your identity provider, Entra included | Native, and genuinely strong - sign-on, audit and data policy come with the tenant |
| People outside the company | A portal on your own domain, priced per build rather than per head | Guest access, or a separately licensed external portal |
| Best when | The work reaches past the tenant, or the app has to outlive a licensing decision | The operation already lives in Microsoft 365 and IT administers it well |
Where the difference actually shows up
You do own the tenant. The question is what runs inside it
Be fair about this first: an app built in your own Microsoft tenant is yours in the ways that matter most. The data sits under your policies, your administrators control access, and no consultant is holding anything hostage. What does not travel is the runtime. The app is expressed as a vendor’s canvas and flows, so moving it elsewhere is a rebuild rather than a migration, and it keeps running only as long as the licensing under it is renewed.
Licensing is the part to read before the build, not after
Standard licensing and standard connectors cover a large amount of honest work, and for many companies the app costs nothing beyond seats they already pay for. The surprises arrive later: a premium connector for the line-of-business system, Dataverse once the data has real relational shape, an external-facing portal for customers, a per-user tier for people who open the app twice a month. None of it is hidden. It is simply priced after the app has been designed rather than before.
Where the owned line actually sits
What we build - the Operations Platform - is one system with its own database and its own code, on infrastructure the client controls, handed over documented at the end. It earns its place when the work crosses systems the tenant does not reach, when customers or subcontractors need to be inside it without being licensed, or when the thing has to be independent of any single vendor’s pricing. It is the wrong answer when the operation already lives in the tenant and your IT team is good at it.
When the other option is right
Build it inside Microsoft 365 when your business already lives there. If everyone has a license, IT administers the tenant, identity and device policy already run through Entra, and what you need is a form, an approval chain and a report over data that is already in SharePoint or Dataverse - that is the job Power Platform was built for, and going outside the tenant would cost you money and give up governance you already have. The compliance story is easier too: one audit boundary, one data residency answer, one set of policies rather than two. It is also the better call if someone internal builds in Power Apps well, because the app they ship next month beats the one we scope over six weeks. And if the need is small - one team, one form, a few hundred records - the honest advice is to build it in the tenant and not call us at all.
FAQ
Common questions
Do we really own an app we built in our own Microsoft tenant?
You own your tenant, your data and the app definition, which is more than many vendors give you. What you do not own is the runtime it needs - the app lives as a canvas and flows inside Microsoft’s platform, so it runs where it was built, for as long as the licensing under it is paid. That is a fair trade for a lot of businesses. It is just a narrower claim than owning the system outright.
Will you work inside our Microsoft tenant?
Yes, where that is the right answer. Plenty of engagements leave the Microsoft side alone and build only the part that has to reach outside it, and some sit entirely inside the tenant because that is where the work already is. What we will not do is recommend a separate platform when the tenant covers the need.
What happens to the data already in SharePoint and Excel?
It comes across, and it is usually the first thing we read. Existing lists and workbooks are the clearest description of how the work actually runs, including the parts nobody documented. Whether a workflow keeps reading from them or the new system takes over as the record is decided per workflow, not as a rule.
Is a build cheaper than adding Microsoft licenses?
Sometimes, and it turns on how many people need to be in the app and what it has to connect to. Seats you already pay for are not a new cost, so a small internal app inside the tenant is almost always cheaper. The arithmetic changes when the app needs premium connectors, external users, or licenses for people who touch it twice a month.
Or explore Process Automation.