Microsoft's Own Goals in Teams Development

I need to be honest with you about Microsoft Teams development.

Microsoft has one of the most powerful enterprise application platforms on the market today. Microsoft Teams reaches 320 million daily users. It’s integrated into the workflow of virtually every enterprise using Microsoft 365. The technical capabilities for building custom apps are genuinely impressive.

But yet, Microsoft has been sabotaging developer adoption for years with decisions that make no sense. September’s rollout of a minor release to the Microsoft 365 Agents Toolkit (ATK) that included a huge reset to project templates is the latest example in a long history of shooting themselves in the foot.

I’ve been a Microsoft MVP for over two decades. For the last few years, I’ve taught multi-week live Teams development cohort-courses twice a year. I coach enterprises building Teams applications. I maintain documentation for Microsoft’s SharePoint developer platform. I’m deeply invested in this ecosystem, and I care about its success.

That’s why I’m frustrated enough to write this.

Microsoft keeps scoring own goals, the soccer term for accidentally kicking the ball into your own net. They’re hurting their own chances of winning by undermining developer confidence in the platform through unnecessary SDK churn, documentation disasters, and abandoning projects and templates developers relied on.

Let me explain what I’m seeing, why it matters, and why Teams development is still worth pursuing despite all of it.

TL;DR

Microsoft Teams has massive potential—320 million daily users, 93% Fortune 100 adoption—but Microsoft keeps undermining developer adoption through constant SDK changes, confusing documentation, and contradictory guidance.

Despite investing heavily in Teams development myself, I’ve watched Microsoft make the same mistakes repeatedly: deprecating tools without clear migration paths, scattering documentation across multiple domains, and rushing features before they’re ready.

The platform is actually powerful, but Microsoft’s own missteps are preventing it from becoming the app platform it should be.

Here’s what needs to change, and how I’m helping developers navigate this chaos.

Andrew Connell

Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.

The Potential We’re Wasting

Before I catalog Microsoft’s mistakes, let me be clear about what’s possible with Teams.

Every enterprise needs custom applications. Small internal tools for tracking resources, dashboards for viewing organizational data, chatbots that connect to backend systems, meeting extensions that enhance collaboration. These aren’t hypothetical use cases… these are applications every organization eventually needs.

Historically, building these meant:

• Creating a custom web app
• Finding hosting infrastructure (on-prem or cloud)
• Making the app discoverable to employees
• Managing authentication and authorization
• Ensuring security and compliance

Teams eliminates most of that friction. When you build a Teams app, you get:

• Instant distribution to everyone in your organization
• Authentication through existing Microsoft Entra infrastructure
• Integration with Microsoft Graph for accessing Microsoft 365 (M365) data
• Security and compliance inherited from your organization’s policies
• Deployment into an environment your IT department already approved

For enterprises already using Microsoft 365, Teams apps are the obvious choice for internal applications. The platform advantages are overwhelming.

That’s why Microsoft’s self-sabotage is so frustrating. They have a winning product and they keep undermining it.

The Pattern of Self-Sabotage

Abandoning Community Tools They Should Have Supported

In the beginning, Microsoft provided no tooling for Teams development. The community stepped up. Wictor Wilén created Yo Teams, a scaffolding tool that made it easy to get started building Teams apps. It became essential. Over 100,000 downloads. Developers relied on it.

Microsoft saw the popularity and decided to build their own tooling: the Teams Toolkit (TTK). Versions 1 and 2 were essentially unusable. Version 3 was barely functional… so bad that when I was building training materials for Microsoft, they told me to just keep using Yo Teams because the TTK v3 wasn’t at a point they would even recommend it.

Version 4 was finally good. Version 5 was really good… good enough that I started recommending it over Yo Teams. By version 6 (rebranded as the Microsoft 365 Agents Toolkit (ATK)), it had become a solid developer experience.

But the damage was done. The years of poor tooling killed developer confidence. And Yo Teams? Wictor eventually retired it when there was a solid developer toolkit from Microsoft.

The SDK Carousel

I understand that SDKs need to evolve. Technologies improve. Developer experience gets better. Sometimes you need breaking changes to enable significant improvements.

But doing full code resets multiple times in a few years? That’s just exhausting for developers.

Here’s the timeline:

• Teams JavaScript client SDK v1 to v2: Fundamental API changes, but for good reasons. The v2 API (released June 2022) is cleaner and better. This was a justified reset.
• TeamsFx: Server-side library for Teams apps. Evolved through several versions as it was released with the TTK. Finally got really good around v4/v5. And then, Microsoft abruptly deprecated entirely in September 2025.
• Teams AI Library v1: Released May 2023 as the modern way to build AI-powered Teams apps. Complete code reset and deprecated it in September 2025.
• Teams AI SDK v2: Released September 2025 as a complete rewrite. Different APIs, different patterns, no migration tools.
• Microsoft 365 Agents SDK: Released May 2025 as yet another option for building agents.

Add in Bot Framework, which Microsoft quietly stopped investing in without formally deprecating it, and you have a pattern of continuous disruption.

Every time Microsoft does a reset, developers face the same calculation: invest time learning the new approach that might be deprecated in 18 months, or stay on the old approach and risk obsolescence.

That’s not sustainable. Developers get exhausted. They lose confidence. Some ISV’s just go build on Slack instead because at least Slack’s API doesn’t fundamentally change every year.

Project Template Chaos

Every time Microsoft releases new project templates with their toolkit updates, they’re dramatically different from previous versions.

Developers who learned to start projects one way suddenly face completely unfamiliar structures when starting new projects. The old templates don’t just get deprecated, they get deleted from the toolkit entirely. There’s no way to see what changed or understand the evolution.

When the Teams AI v2 reached the GA milestone in September 2025, all the old templates vanished. Concepts that developers understood, like command bots, notification bots, specific tab patterns using React with Fluent UI, either disappeared or were reimagined in ways that weren’t documented.

Features developers relied on in notification bots? Gone. The intuitive patterns for building tab apps? Replaced with something completely different with no migration guide.

I watched experienced developers struggle to figure out how to do things they’d done successfully in previous versions because the templates had changed so drastically.

The Documentation Disaster

Let me be blunt: Microsoft’s Teams development documentation is a disaster.

I maintain developer documentation for Microsoft’s SharePoint platform, so I know it’s not hard to keep docs updated and consolidated on learn.microsoft.com. You can push updates quickly. You can retire old content without deleting it. You can maintain multiple versions clearly.

Microsoft isn’t doing any of that for Teams.

The docs still reference deprecated tools: ngrock instead of Dev Tunnels and project structures that no longer exist.

The docs are scattered across multiple domains: Microsoft Learn has outdated content. GitHub Pages has the current Teams AI SDK v2 docs, but they’re not discoverable through search. Samples are scattered all over the place and samples that use the latest SDKs leave a LOT to be desired.

The docs contradict themselves: Different pages recommend different approaches. Some pages reference Teams AI v1 (deprecated), others reference v2, others reference the M365 Agents SDK, all without explaining when to use which. The only way I was able to figure it out was by finding the source and posting questions in their GitHub repos.

When Teams AI v2 launched in September 2025, the published documentation left a lot to be desired… and still does. Samples still use v1 APIs. Templates still referenced TeamsFx. Developers trying to learn the new SDK were reading documentation for deprecated technologies.

I’ve submitted documentation fixes. I’ve flagged issues to Microsoft employees. The response is always the same: acknowledgment that it’s a problem, promises to improve, and then nothing changes.

Why This Matters More Than You Think

You might think: “So what? Developers can figure it out. The underlying platform is good.”

But that misses how developer ecosystems work.

Every developer who tries Teams development, gets frustrated, and gives up is one less person building Teams apps. They’re also one less person recommending Teams to colleagues, creating tutorials, building tools, or contributing to the community.

Network effects matter. Slack has 2,600 apps in their directory despite having 42 million users. Teams has 1,400 apps despite 320 million users (reported late 2023 in their FY24Q1 results). That’s not because Teams has worse capabilities - it’s because the developer experience makes it harder to succeed.

The app directory gap represents lost value for Microsoft’s customers, reduced platform utility, and unrealized revenue opportunities. Microsoft’s user base advantage doesn’t automatically translate into platform strength when developers avoid building on it.

The Investment That Gives Me Hope

Despite everything I’ve documented, I still believe in Teams development.

Here’s why:

The recent investments are real. Teams AI v2, the M365 Agents SDK, and the Agents Toolkit represent genuine commitment. These aren’t half-hearted efforts. Microsoft is investing engineering resources in making Teams development work.

Teams AI v2 is actually really good. Once you get past the confusing name (it’s not just for AI, and it’s not Teams-specific), it’s essentially TeamsFx v5. The architecture is solid. The APIs are clean. It supports TypeScript, Python, and C#. This is what a mature Teams SDK should look like.

The market fundamentals are overwhelming. 320 million daily users. 93% of Fortune 100 companies. Built-in authentication, security, and compliance. Microsoft Graph integration. For enterprise applications, Teams’ advantages are undeniable.

The platform isn’t going away. Microsoft has bet the company on Microsoft 365 and Teams. They’re not abandoning this platform. They’re just making it unnecessarily hard to build on.

What Needs to Change

Microsoft needs to act more like their “One Microsoft” catchy phrase introduced in 2013 and less like shipping the org chart with lacking oversight.

Consolidate and clarify the SDKs. Three competing SDKs with overlapping capabilities or SDKs that don’t that don’t work together confuses everyone. Ask each team responsible for their SDK and they’ll each give you an answer. But in the docs? Nope. A page that guides

Provide a clear decision matrix. Explain when to use what. Better yet, consolidate to two clear paths with a clear story… and ship when it’s ready… not when it’s rushed for some conference.

Fix the documentation. Move everything to learn.microsoft.com. Retire old content without deleting it. Clearly mark what’s current versus deprecated. Update docs when SDKs ship, not months later. This isn’t technically hard - it’s an organizational priority problem.

Provide migration tools and guides. When you deprecate an SDK or make breaking changes, give developers concrete migration paths. Automated migration tools for simple cases. Step-by-step guides for complex ones. Acknowledge the cost you’re imposing on developers and help minimize it.

Stop deleting project templates. Archive old templates instead of removing them. Let developers see the evolution. Provide upgrade guides that show what changed and why.

Commit to stability windows. Promise that SDKs will be supported for minimum timeframes. Announce deprecations with 24-month lead times, not 12-18 months. Give enterprises time to plan and budget for migrations.

Will any of this happen? With Microsoft’s track record of ambivalence to the developer ecosystem and lack of empathy… I doubt it.

Why I’m Still Teaching Teams Development

Given everything I’ve documented, why do I still run workshops on Teams development? Why do I invest hundreds of hours creating training materials and coaching developers?

Simple: the underlying platform is worth it.

When you successfully navigate Microsoft’s chaos, you can build applications that reach more enterprise users than almost any other platform. You get security and integration capabilities that would take months to build elsewhere. You deploy into an environment already approved and trusted by IT.

The problem isn’t that Teams development is bad — it’s that Microsoft makes it unnecessarily difficult.

My workshops exist to bridge that gap. I teach developers:

• Which SDKs to use and when (something Microsoft should provide but doesn’t)
• How to navigate the fragmented documentation and find accurate information
• Architectural patterns that survive SDK changes and deprecations
• Practical strategies for building Teams apps that last

I also teach the strategic perspective: how to read Microsoft’s signals, when to adopt new technologies versus waiting, how to plan for inevitable migrations.

Developers shouldn’t have to figure all of this out through trial and error. They shouldn’t waste hundreds of hours researching SDK options or debugging deprecated code samples. They should be able to focus on solving business problems, not navigating platform chaos.

That’s what Voitanos provides: the expertise that makes Teams development manageable despite Microsoft’s self-sabotage.

The Honest Reality

Let me end with complete honesty:

If you’re building enterprise applications and your users are already on Microsoft 365, Teams gives you capabilities no other platform can match. The market access alone justifies navigating Microsoft’s complexity.

You just need to be smart about what you build and what dependencies you take.

That’s the reality I’m teaching in my workshops—not because Teams development is easy, but because it’s valuable enough to be worth the effort.

Microsoft has built an good platform and then undermined its adoption through preventable mistakes. Sure, there are parts that aren’t great. The experience of Teams meetings is no where near as good as Google Meet or Zoom. That chat & threading experience sucks compared to Slack. But as a host for your apps? It’s pretty good.

As a developer or development team, you can succeed despite those mistakes. You just need to build with eyes wide open and need a trusted source you can rely on.

author

Andrew Connell

Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.

Andrew Connell is a full stack developer who focuses on Microsoft Azure & Microsoft 365. He’s a 21-year recipient of Microsoft’s MVP award and has helped thousands of developers through the various courses he’s authored & taught. Whether it’s an introduction to the entire ecosystem, or a deep dive into a specific software, his resources, tools, and support help web developers become experts in the Microsoft 365 ecosystem, so they can become irreplaceable in their organization.

Feedback & Questions