15 Years of SharePoint Development — What I Know Now

I wrote my first SharePoint web part in 2009. It was a server-side ASPX user control that queried a list via the object model, built an HTML table in a StringBuilder, and wrote it to Response.Output. It worked. It was terrible. And it taught me more about SharePoint's architecture than any documentation I had read at the time.
Fifteen years later, I am still building on SharePoint — only now with TypeScript, React, Fluent UI, and a platform that has genuinely become one of the better places to build enterprise software. A lot has changed. Some things have not.
This is what I know now that I wish I had known then.

The Platform Always Wins

For the first half of my career, I spent enormous energy working around SharePoint — writing custom code to bypass constraints, building elaborate server-side solutions to compensate for things the platform did not do natively.

Looking back, most of that work had a short shelf life. Every major SharePoint version brought native capabilities that made the custom workarounds redundant. The applications I built with the platform's grain — lists, content types, workflows, search — outlasted the clever custom solutions by years.

The lesson: before building something custom, spend the time to understand what the platform already does. SharePoint's list infrastructure is remarkably capable. Its search is genuinely excellent. Its permissions model, frustrating as it is to navigate, is comprehensive. The custom code that lasts is the code that extends these foundations, not the code that replaces them.

The Upgrade Problem Is Permanent

SharePoint has gone through at least four major architectural transitions in fifteen years: server-side web parts to sandbox solutions, sandbox solutions to the add-in model, the add-in model to SPFx, and now SPFx extending into Teams, Viva, and Copilot.

Every transition broke something. Every transition also improved something fundamentally.

Developers who built tightly on the deprecated model — SharePoint Designer workflows, server-side code in the sandbox, full-trust farm solutions — faced painful rewrites. Developers who built loosely — clean data in lists, content types as the contract, minimal custom UI — adapted with much less effort.

The best defence against platform transitions is keeping business logic in SharePoint's data layer and keeping presentation thin. A web part that reads from a well-structured list can be rebuilt in an afternoon when the next rendering framework arrives. A web part that is tightly coupled to a specific API surface takes weeks.

Lists Are the Right Primitive

I spent years treating SharePoint lists as a compromise — the thing you used when you could not have a real database. That was the wrong frame entirely.

A SharePoint list with properly defined content types, indexed columns, and a managed taxonomy is a genuinely powerful, versioned, permission-aware, search-indexed data store that non-developers can manage without IT involvement. That is not a compromise. That is a deliberate design with real advantages.

The solutions I am most proud of are not the ones with the most code — they are the ones where the architecture is mostly SharePoint lists, content types, and a thin SPFx layer to present the data. These solutions have been maintained and extended by people who were not developers, have survived multiple SharePoint migrations without code changes, and are still running a decade after I last touched them.

Simplicity Is a Feature

Early in my career I equated complexity with capability. A solution with custom web services, elaborate event receivers, and custom workflow activities felt more serious than a list and a few web parts.

I no longer believe this. The most capable SharePoint solutions I have seen are also among the simplest. They do one thing well, use the platform's own persistence, and are understood by anyone who works with SharePoint regularly — not just the developer who built them.

Complexity adds bugs, slows onboarding, increases maintenance cost, and creates single-person dependencies. Before adding any abstraction layer, any custom service, or any clever pattern, I now ask: what would happen if I just did this with a list and a web part? If the answer is "it would work fine," I do not add the abstraction.

The Community Multiplies Everything

SharePoint is the most active developer community in the Microsoft ecosystem. PnPjs, the SPFx Controls library, the SharePoint Patterns and Practices samples — these represent hundreds of thousands of engineering hours contributed by developers who built something, figured out the hard parts, and then gave it away.

I benefited from this community enormously before I contributed to it. The switch — from consumer to contributor — happened when I published a working sample that solved a problem I had not found documented anywhere. The response from developers who found it useful was immediate and genuine. That feedback loop is addictive in the best way.

If you are reading this and have not contributed to the community yet — publish something. A blog post explaining the error message you spent a day debugging. A GitHub sample of the pattern you finally got working. A comment on someone else's post that adds the context they were missing. The barrier to valuable contribution is much lower than it seems.

Certifications Do Not Expire, But Knowledge Does

I have watched developers coast on certifications that reflected a version of SharePoint that no longer exists. The exam you passed for SharePoint 2013 told you something about the platform as it was then. It tells you very little about SPFx, Graph API, or Viva Connections.

The developers I respect most are the ones who stay curious — who follow the Microsoft 365 changelog, who read the SPFx release notes, who try the new things before they are required to know them. In a platform that evolves this quickly, the willingness to keep learning is a more durable advantage than any specific technical knowledge.

What I Would Tell Myself on Day One

Build things. Break things. Build them again better. Read the platform's documentation — not to memorise it, but to understand what it wants to do. Learn to work with the grain of the platform before you learn to work against it. Join the community early. Publish what you figure out, even if it is imperfect.

And if you are about to copy a Web Part base page file into a Content Editor Web Part and inline some JavaScript — please, just learn the proper web part model first. Trust me on this one.

✅ Thank You

Fifteen years is a long time to work on a single platform. SharePoint has been frustrating, exciting, occasionally maddening, and genuinely rewarding. The community of developers around it — the people who ask questions, share solutions, write samples, and push back on the platform when it needs pushing — are the real reason I am still here.

If you have questions, disagree with anything here, or want to share your own SharePoint war stories, reach out. The community conversation is where the best learning happens.

Happy coding!