An admin opens Copilot, describes what he needs in five sentences, and has an app by the afternoon. It creates teams, enforces a naming convention, and puts an approval step in front. That is not an illusion. It works. Vibe coding, meaning building software in dialogue with an AI model, really has lowered the barrier to entry. So now many conversations include the same question: why buy a software if we can build it ourselves?
The answer is not in the prototype but in the total cost of ownership. A governance app holds high permissions in your tenant, runs in production, and has to survive every Microsoft change. Building it is the cheap part. Here are the line items missing from the first estimate, with the numbers behind them.
Should you build a Microsoft 365 governance app or buy one? The short answer
Buy. For anything that has to run in production for years, buying is cheaper and safer. In our experience at Solutions2Share, initial development is about 15 % of total cost of ownership. Around 45 % of AI-generated code contains known security flaws (Veracode). And experienced developers were 19 % slower with AI tools, not faster (METR).
What is vibe coding?
Vibe coding means developing software in dialogue with an AI model. You describe the behavior you want in plain language, the model writes the code, and you check the result in operation instead of line by line. It works well for prototypes. Software that manages permissions in a Microsoft 365 tenant has different requirements.
The 15 % trap: where the TCO of a self-built app actually sits
Initial development is the smallest line item. For our apps it accounts for roughly 15 % of the total effort. The other 85 % is work that never shows up in a project plan for an internal tool:
- Product management and prioritization
- UX and UI
- Functionality beyond the first use case
- QA and testing
- Documentation
- Hosting and operations
- Security and security reviews
- Maintenance
- Further development
- Ongoing adjustments to Microsoft changes
None of that disappears when an AI writes the code. It moves from a vendor's invoice to your team's calendar, and it comes back every year the app stays in use.
One line item surprises people: the tokens for development and bug fixing can end up costing more than a license. At that point you have paid, and you still have no support, no testing, no hosting, and no certification.
Why the last 5 % take longer than the first 95 %
The old 80/20 rule has shifted. With vibe coding you get to 95 %. The interface, the login, the simple functions, all there, and it looks good. The last 5 % are throttling limits in the Microsoft Graph API, permission inheritance, and error handling for half-created teams. Those 5 % decide whether the tool can run in production at all.
Veracode tested more than 150 language models on 80 coding tasks in spring 2026. Syntactic correctness came in above 95 %. Security stayed flat at around 55 %, unchanged across two years. Their own summary: the models have become very good at writing code that compiles, and bad at writing code that is secure.
Developers report the same thing. In the Stack Overflow Developer Survey 2025, 66 % named AI solutions that are almost right but not quite as their main problem, and 45 % said debugging AI-generated code takes longer than expected.
The time math is unreliable too. In July 2025, METR ran a randomized study with 16 experienced open source developers across 246 tasks. With AI tools they took 19 % longer. Beforehand they had expected a 24 % speedup. Afterwards they still believed they had been 20 % faster. Your estimate does not go wrong because your team estimates badly. It goes wrong because the time saved feels bigger than it was, even in hindsight.
What happens when the developer leaves the company?
An internal colleague builds the tool, understands it, and maintains it. Then he takes a job at a different company. What stays behind is an app running in production, with logic nobody understands anymore and documentation that consists of code comments. At the next Microsoft update, provisioning stops working, and nobody in the building can say why.
Your developer is good. That is beside the point. The critical issue is that the knowledge is tied to him. Ask yourself: if that app fails today, who can fix it? If the answer is a person's name, you do not have a tool. You have a dependency.
In the end it is less secure, not more
A governance app needs high permissions in the tenant: create teams, change memberships, invite guests, set permissions. A flaw in that app sits at the center of your environment, and the flaw classes AI code fails on are the invisible ones. In Veracode's tests the pass rate for cross-site scripting was 15 %, and for log injection 13 %. Neither is something you notice in a running app.
Sloppy work is rarely the cause. Serious flaws go undetected because nobody is looking for them systematically. No pentest budget, no security review, no external auditor.
Then come the questions your compliance department will ask:
- Who is responsible if data leaks through the app?
- Is hosting running securely in your own VNet, or just somewhere in Azure?
- Who documents the permissions the app holds in the tenant?
- Who proves the security posture to an auditor?
On our side, our certifications answer that. Solutions2Share is certified to ISO/IEC 27001:2022, our apps are Microsoft certified, and Microsoft reviews them thoroughly before they reach the Marketplace. A SOC 2 audit is currently underway as well.
For banks, insurers, utilities, and public sector buyers this is not just a nice-to-have. Without that evidence the solution never goes into operation. Producing it yourself for an internal tool means starting a second costly project next to the first one.
Who picks up the phone at 9pm on a Saturday?
Build it yourself and there is no SLA, no on-call rotation, and no one to call. Solutions2Share has an emergency team that steps in on weekends, if necessary. Ask yourself what that commitment would look like at your company, and who could give it.
Microsoft keeps rebuilding, without asking you
Microsoft publishes Graph API changes continuously in a public changelog. Some are harmless, some break functionality. In the years we have maintained it, Microsoft has rebuilt OneNote integration and provisioning at least five times. Every time we had to follow within a few days, and our customers never noticed. That is exactly what they pay for.
With a self-built app you notice when colleagues start reporting issues. Then you search, then you fix, then you test. And again in four weeks. A product team tracks these changes permanently because that is its job. An internal IT department deprioritizes it after the third time, because there are more urgent tickets.
Why Copilot tells you that you can build it yourself
Ask an AI model whether you can build your own governance tool and it will usually say yes. A model judges feasibility from code, not from years in operation. It sees that the Graph calls exist. It does not see the certification your auditor wants, the maintenance after the next Microsoft release, or the support load in daily operation.
The recommendation is also not neutral. AI vendors earn money on tokens, so a suggestion that generates many development hours is better business than pointing you to a finished solution. That is how the business model works. Before you carry the answer into a business case, think a little further: Not "can I build this," but "what will it cost to run, secure, and keep up-to-date for the next five years."
Governance is experience, not code
Our apps look deceptively simple. An admin creates a template in Teams Manager, clicks it together, done. What runs behind it is not simple: permission logic, lifecycles, approval processes, throttling, recovery after half-aborted operations. That seeming simplicity is the result of 15 years on this one topic, across hundreds of customer environments with different tenants, compliance requirements, and legacy baggage. Your developer does governance today and something else tomorrow. That can work. It just has a different tolerance for error.
Strategic IT resource allocation: stop building what you should be buying
The real question is not whether your team can build a governance app. It is what your team does not do while it builds, and whether the TOC are really lower than a software license. An internal Microsoft 365 governance tool is not a project with an end date. It is a standing commitment: someone has to track Graph API changes, run the security reviews, answer the tickets, and rebuild the parts Microsoft moves. That belongs in the budget as recurring capacity, not as a one-time sprint.
Run the numbers with your own figures. Take the fully loaded annual cost of the developer who would own the tool, multiply by the share of the year it realistically consumes once it is in production, and add the security review and the on-call coverage you do not have today. Compare the result to the license. In small and mid-sized organizations, the internal number is usually the larger one.
Then ask the strategic question. Microsoft 365 governance tooling is probably not what your company makes money on. Capacity spent there is capacity not spent on the systems only you can build: your product, your integrations, your data. The rule of thumb is short. If it is not a differentiator and somebody sells it, buy it. Buying a governance app is a decision about where else your engineers create value nobody else could.
The short version: make or buy?
| Criterion | Building it yourself with AI | Teams Manager / External User Manager |
| --- | --- | --- |
| Total cost of ownership | ongoing, hard to plan, tokens plus staff time | license, predictable |
| Share of initial development in TCO | approx. 15 %, the rest comes later | included in the price |
| Time to use | months, open-ended for the last 5 % | ready right away |
| Code security | approx. 45 % of AI code with known flaws (Veracode 2026) | reviewed, certified, externally audited |
| Microsoft changes | you follow every time | we follow, you never notice |
| Proof of security | you produce it yourself | ISO/IEC 27001:2022, Microsoft review, SOC 2 audit underway |
| Support | internal, no SLA | defined support, emergency team on weekends |
| Knowledge risk | tied to individual people | product team and documentation |
| Responsibility during an outage | entirely yours | ours |
The solution you built yourself ends up less secure, more expensive than planned, and at some point nobody is left to keep it going.
If you are preparing this decision right now, talk to us before you estimate the effort. We will gladly show you the details of which cases Teams Manager and External User Manager cover, and where your own script is enough.
Sources
- Veracode, Spring 2026 GenAI Code Security Update, March 24, 2026. More than 150 language models, 80 coding tasks, four languages. veracode.com
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 10, 2025. 16 developers, 246 tasks, randomized. metr.org
- Stack Overflow, Developer Survey 2025, AI section, December 2025. survey.stackoverflow.co
- Microsoft, Microsoft Graph Changelog, updated continuously. developer.microsoft.com
- Andrej Karpathy, origin of the term vibe coding, February 2, 2025. x.com/karpathy
- Solutions2Share, our own effort distribution from 15 years of product development for Microsoft 365 governance.
