Get in Touch
Hire Talent
Tell us the role
Hire SharePoint Developers

SharePoint Developers Who Build for the Version You Actually Run

A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.

72-hour shortlist · 30-day replacement guarantee · Month-to-month

On-Premises and SharePoint Online Are Two Different Jobs

SharePoint has been three or four different products under one name, and a CV reading “SharePoint developer” can mean any of them.

On-premises farm development — full-trust C# solutions deployed to servers you own — is a real specialism and a shrinking one. SharePoint Online development is TypeScript, the SharePoint Framework, and Microsoft Graph, with no server to deploy to and a release cadence you do not control. The classic and modern experiences differ enough that customisations built for one frequently do not carry across to the other.

Name your version before writing the job description. A developer whose last five years were farm solutions on 2016 will need time to become productive in SPFx, and one whose entire career has been Online may never have seen a content database. Both are reasonable hires. Only one of them is the right hire for your estate.

Screening

What We Screen For

Your version, specifically

2016, 2019, Subscription Edition, or Online. The gap between farm solutions and SPFx is wider than the shared product name suggests.

SPFx and Microsoft Graph

Modern client-side development in TypeScript against Graph. The part of this skill set that dates well.

Permissions discipline

Broken inheritance is how estates become ungovernable. Knowing when to break it and when to redesign the structure instead.

Information architecture

Metadata and content types over nested folders. Decided early, and painful to change once people have filed things.

Migration judgement

Knowing what not to bring across. Most migrations move too much and inherit the problem they were meant to solve.

Platform boundaries

Recognising when a requirement has outgrown SharePoint and belongs in Power Apps or a purpose-built application.

What This Costs You When It Goes Wrong

SharePoint rarely fails loudly. It sprawls.

The pattern starts with a reasonable decision: let teams create their own sites. Two years later there are four hundred of them, nobody knows which are current, and the same document exists in six places with three different sets of edits. Search stops being useful because it returns everything, which people experience as SharePoint being bad at search rather than as a governance problem with a fixable cause.

Permissions decay alongside it. Someone breaks inheritance on a library to share one folder with a contractor, and it is never restored. Repeat that across hundreds of sites and you no longer have a permissions model, you have permissions archaeology. The day someone asks who can see the HR folder, nobody can answer without running a script — and in a regulated environment, that question arrives with an auditor attached to it.

The costly version is the migration that copies the mess forward. The move to SharePoint Online gets treated as a technical exercise, everything is lifted across, and the sprawl arrives intact — along with customisations that no longer work in the modern experience. The organisation pays for a migration and receives the same estate on a newer platform, plus a fresh backlog of broken web parts. Deciding what not to migrate is the hard part, and it is a business conversation rather than a technical one.

Seniority, Defined

Developer (3–5 years). Builds SPFx web parts and configures sites within an established structure. Comfortable with lists, libraries, and Power Automate. Needs direction on architecture and governance.

Senior (5–8 years). Owns the information architecture and the permissions model, leads migrations, and decides when a requirement should leave SharePoint altogether. Works with the business on adoption rather than only on delivery.

Architect (8+ years). Tenant-level design, governance policy, compliance and retention, and integration across Microsoft 365. Relevant for large estates or regulated environments where access review is a standing obligation.

Common Requests

Migration to SharePoint Online. From on-premises or from an older tenant. Still the most common request by some distance.

Intranet builds. Modern communication sites, news, and navigation that people actually use rather than bookmark once.

SPFx development. Custom web parts and extensions for the places where the out-of-the-box components genuinely fall short.

Governance and permissions remediation. Untangling inherited sprawl. The same problem usually exists one layer up in Power Platform, and the two are best tackled together. Unglamorous, and the work that most improves daily life for everyone using it.

Document management and compliance. Retention, records, and access review. See security and compliance.

Teams and SharePoint alignment. Every team site created from Teams is a SharePoint site whether anyone planned for it or not, and reconciling the two is a request that arrives about a year after adoption. Where it widens into several systems, a solution architect is usually the right person to lead it.

What a Good First Month Looks Like

Week one. They look at how people actually use the estate before proposing changes to it. Expect site and library counts, a read on where content is duplicated, a sample of broken permission inheritance, and a note of which customisations will not survive a move to the modern experience.

Weeks two to four. One structural fix and one visible improvement. The structural fix is usually permissions or information architecture; the visible one is usually navigation or search, because those are what people complain about. Expect a clear recommendation about what to leave behind in any planned migration, with a defensible rule behind it rather than a per-site judgement call that will never finish.

The warning sign is a developer who wants to build web parts immediately. Custom code is the smallest part of most SharePoint problems and much the most satisfying to write. If the first proposal is a custom component rather than a question about how content is organised, you will end up with something well built that nobody needed.

Mistakes We See

Hiring farm-solution experience for an Online estate. Or the reverse. Ask which version someone has worked in for the last two years, not which versions appear somewhere on the CV.

Using SharePoint as an application platform. It was a reasonable choice a decade ago. Requirements involving complex logic, genuinely relational data, or a real user interface now belong in Power Apps, Dataverse, or a purpose-built application.

Folders instead of metadata. Folders are familiar, and they quietly defeat search, views, and retention policy. The cost is invisible for a year and close to permanent afterwards.

Migrating everything. The volume you carry across is a choice, not a given. Content nobody has opened in five years does not become more valuable on a new platform, and it makes everything else harder to find.

How It Works

  1. Discovery, 30 minutes. Which version, tenant size, what has been customised, and whether a migration is in scope.
  2. Shortlist within 72 hours. Three to five profiles, matched to your version rather than to the product name.
  3. You interview. Your process, your technical test. We suggest asking how they would decide what not to migrate.
  4. Onboarded in two weeks. Contracts, NDA, IP assignment, tenant access.
  5. 30-day guarantee. One email, replacement candidates within 48 business hours, no cost. Full terms →

Rates depend on version, seniority, and engagement length. Tell us the role and we will give you a firm number.

Tell us the role and we will send a shortlist within 72 hours.

Tell Us the Role
FAQs

Questions

Does on-premises versus Online really change who we hire?

Yes, more than most people expect. Farm solutions are server-side C# deployed to infrastructure you control; Online is client-side TypeScript against Graph with no server access at all. Strong developers cross over given time, but you should budget for that time rather than assume it away.

Should we still be building custom web parts?

Sometimes, and less often than people think. The modern out-of-the-box components cover a great deal, and every custom part is something you own and maintain through each platform change. Build custom when the gap is real and the requirement is stable enough to be worth the maintenance you are signing up for.

How long does a migration take?

The content move is the predictable part. The time goes into deciding what moves, rebuilding customisations that will not carry across, and getting people to change where they save things. Estates of similar size vary by months depending on how much of that work is faced early.

Do we need a developer or an administrator?

If the work is sites, permissions, governance, and Power Automate, that is administration and a developer is an expensive way to buy it. SPFx, Graph integration, or custom extensions mean you need a developer. Migration projects usually need both.

Is SharePoint still the right place for our intranet?

For most organisations already on Microsoft 365, yes — the integration with Teams, search, and identity is difficult to match. The question is usually not whether to use it, but whether anyone will own the information architecture once it is live.

Get Your Shortlist

Tell us the role. Three to five profiles within 72 hours.