If I could go back and rebuild some of the early SharePoint environments I worked on, I wouldn’t start with technology. I would start with restraint.

If you met me early in my career, you already know I’ve always had energy and passion for technology, especially SharePoint. The difference is that back then I aimed it at everything. If SharePoint could do it, we probably should. Workflows, custom master pages, extra navigation layers. More features meant more value. More customization meant more sophistication. Complexity felt like competence.

It wasn’t ego. It was enthusiasm, and enthusiasm without boundaries turns into technical debt with a personality.

Overbuilding felt responsible. Overcustomizing felt strategic. Overengineering felt impressive in a demo. In reality, it often meant I was solving for clever instead of durable, and clever sometimes ages badly.

When I exercised restraint, I built solutions that lasted almost a decade. When I did everything I was asked for, I built solutions that got dated quickly.

I once built a document approval portal that outlasted me in that job twice. I left, came back years later, and the workflows were still running without a single failure. I left again, and they kept going. I’m fairly certain the original owner has retired by now. Hopefully those workflows have finally made their way to Power Automate.

That contrast took years to appreciate. Early on, I optimized for approval. Now I optimize for longevity.

If I could do it again, I would build with lifecycle in mind before launch. If I can’t explain how content dies, I shouldn’t launch it.

Retention, governance, permissions, ownership. Not as cleanup projects, but as design principles. Environments that ignore lifecycle always pay for it later, usually during migrations or painful cleanups. The discipline behind aging content intentionally instead of scrambling to clean it up should exist before the first library is even created.

Nothing exposes weak structure faster than time or change. Every extra layer eventually comes back for inspection during testing and validation cycles. That reality shows up clearly when environments go through migration moments that feel more personal than technical.

I would design fewer entry points and resist portal sprawl. Fewer “one more homepage” requests. More purpose-driven spaces that solve specific problems well. Navigation should guide action, not mirror the org chart. The lesson behind task-driven navigation and clarity over web part overload becomes obvious only after living through complexity.

I would say no more often. No to unnecessary customization. No to executive vanity portals. No to complexity disguised as innovation. Being responsive does not mean saying yes to everything. It means protecting the system from short-term decisions that create long-term maintenance.

Business owner does not always mean site owner. A feature request is not automatically a business requirement.

I would default to out-of-the-box harder. SPFx when necessary, not when bored or trying to impress. The UI will move. It always has. Fighting the platform rarely ends well. Partnering with it usually does.

Most importantly, I would build for behavior, not architecture diagrams. User stories first. Structure second. Designing for ideal behavior punishes real people, while designing for real behavior creates systems that actually last. That shift only happened after I stopped fighting users and started designing with them, not for them, something that fundamentally changed how I approached collaboration.

Even features that quietly protect collaboration, like version history acting as the backbone of trust, only work when the surrounding structure supports them.

Here’s the uncomfortable part. Some of the environments I later criticized were environments I designed. That’s not failure. That’s pattern recognition earned the hard way.

I would also have trusted my gut more. There were managers who told me SharePoint was going the way of the dodo, that it wasn’t marketable, that I should pivot. I worried. I second-guessed. I stayed anyway. If I could go back, I would worry less and trust more. Platforms that quietly solve real business problems tend to outlive hype cycles.

And yet, I’m thankful for the adversity. Every broken workflow, every migration weekend, every executive demand that didn’t age well, every curveball forced me to simplify, think long term, and anticipate consequences. Experience does not come from smooth projects. It comes from messy ones.

If I had to rebuild a tenant tomorrow, it would be smaller, flatter, and simpler. Governed from day one. Lifecycle defined before launch. Training embedded into job expectations. Customization intentional, not decorative. Less impressive on demo day, more durable five years later.

Impressive fades. Durable stays.

---

This post is part of my 25 days of SharePoint series, created to celebrate SharePoint’s 25th anniversary and lead up to the SharePoint at 25 digital event on March 2.

Each post reflects on what actually made SharePoint last 25 years, the wins, the mistakes, and the lessons learned from building, breaking, and rebuilding it in real organizations.

You can find all posts in this series here.

If there’s a topic you think I should cover next, a SharePoint mistake you keep seeing, or a question no one ever answers straight, leave a comment. This series is shaped by real experiences, not marketing slides.