Hire SharePoint Developers: Rates, Vetting and Engagement Models

What a SharePoint developer actually does, and where hiring goes wrong

A client came to us with an intranet that everyone hated. Their previous developer had built the whole thing in classic SharePoint pages with a pile of jQuery injected through a Script Editor web part, plus about forty SharePoint Designer workflows holding the approval processes together. It worked, sort of, until Microsoft retired SharePoint 2010 workflows and the Script Editor stopped being available on modern pages. HR (Human Resources) approvals silently stopped firing. Nobody noticed for eleven days.

A SharePoint developer is not someone who makes pretty pages. They work on the boundary between a heavily opinionated Microsoft platform and whatever your business actually does. On a typical engagement they are building SPFx web parts and extensions in TypeScript and React, wiring them to lists and libraries through PnPjs or Microsoft Graph, deciding whether a process belongs in Power Automate or in an Azure Function, untangling permission inheritance across a site collection, writing PnP PowerShell to provision sites consistently, and migrating content from a 2013 or 2016 on-prem farm into SharePoint Online without destroying metadata, version history or the managed metadata term store.

Hiring goes wrong in one specific way, over and over. Buyers cannot tell the difference between a SharePoint administrator, a Power Platform maker and a SharePoint developer, and the three roles look identical on a resume. The administrator knows site collections, storage quotas and the admin center. The maker builds Power Apps forms and Power Automate flows and has never run npm install. The developer writes code, understands the SPFx build chain, knows what Azure AD app registration consent flows look like, and can tell you why your flow keeps hitting a 429. All three say "SharePoint developer" on LinkedIn. You will pay developer rates for a maker and then wonder why every solution is a Power Automate flow owned by one person's personal account, which breaks the day they leave.

The second failure mode is the customization graveyard. Someone builds something clever with full-trust code or unsupported DOM manipulation, Microsoft ships a change to modern page rendering, and the clever thing dies. Good SharePoint developers are almost boring about this. They ask what happens when Microsoft changes it, and they build inside the supported extensibility surface even when the hack would be faster.

Engagement models and who each one fits

An in-house hire makes sense when SharePoint is load-bearing. If you have a large tenant, real records management obligations, a term store that matters, and a rolling backlog of internal apps, you want someone who knows your permission model and your quirks. The catch is that SharePoint work is lumpy. The intranet rebuild is six months of intense work followed by two years of small tickets, and a good developer will get bored and leave, taking the tribal knowledge with them. You are also hiring from a shallow pool, because the strongest Microsoft-stack developers have largely moved toward Azure and .NET work.

A freelancer fits a scoped, bounded piece: one SPFx web part, one tricky migration wave, an audit of why your flows keep failing. Rates are the lowest and the speed is real. The risk is that SharePoint freelancers skew heavily toward the low-code end, and the good ones are usually already inside an agency or a Microsoft partner. You also inherit a bus factor of one, on a platform where undocumented tenant-specific decisions are the norm.

An agency fits when the work is a project with a definable end: migrate from on-prem to SharePoint Online, replace the classic intranet with a modern communication site, rebuild the workflow layer off deprecated Designer workflows. You are buying a team with a migration tool license (ShareGate, Metalogix or similar), a tested provisioning approach, and someone who has already hit the throttling and the mysterious permission failures on someone else's project. You pay more per hour and you should expect the agency to push back on scope, which is a feature.

Staff augmentation is the model most SharePoint buyers should use. You get one or two developers embedded in your team, running your tickets, working in your tenant, but the vendor carries recruiting, backup coverage and the bench. It fits the lumpy nature of the work: two developers during the migration, one afterwards, zero for a quarter when nothing is happening. It is also the only model where you can quietly swap someone out in a week when it turns out they are a maker and not a developer.

What it costs

These are ranges from Digital Heroes delivery and from what we see clients quoted when they shop around. They are not survey data, and they move with region and seniority.

Offshore and nearshore SharePoint developers land roughly in the $30 to $70 per hour band. India and Eastern Europe have deep Microsoft-stack talent pools because of the consulting and enterprise IT history there, and SPFx and PnP PowerShell skills are genuinely common. The lower end of that band is usually a Power Platform maker who lists SharePoint. The upper end is someone who has run migrations at scale and can debug a Graph permission problem without escalating.

Onshore contractors in the US, UK, Canada or Australia typically run $75 to $150 per hour, and senior Microsoft-partner consultants with a records management or compliance specialization go above that. You pay this for time zone overlap, for stakeholder-facing work, and for people who can sit in a governance meeting with your compliance team.

For an in-house hire in a major US market, expect base salary somewhere around $110,000 to $165,000 for a solid mid to senior SharePoint or Microsoft 365 developer. The base is the smallest part of the picture. In our own hiring, employer taxes, health coverage, retirement match, equipment, software and the share of office and management overhead add roughly a quarter to a third on top of base, and more in high cost states. Recruiting adds a fee or an internal recruiter's time, and in our experience SharePoint roles sit open longer than mainstream web roles because the pool is thin. Then add ramp. A SharePoint developer joining an existing tenant needs four to eight weeks before they understand your site architecture, your permission inheritance decisions, your term store and which of your forty flows are load-bearing. That ramp is real money and nobody budgets it.

One more cost line people miss. Migration tooling is licensed per project or per seat and it is not optional at any real scale. If a vendor tells you they will migrate 800 gigabytes of content with PowerShell scripts and no migration tool, price in the rework.

How to vet a SharePoint developer

Start by separating the roles. Ask them to describe the last thing they shipped, then ask what was in the source repo. If the answer does not include a package.json, a gulpfile and a .sppkg going into the app catalog, you are talking to a maker or an administrator, which may be fine, but price accordingly.

Then ask these, in roughly this order.

How do you deploy an SPFx solution? A real answer walks through the build, bundling and packaging, uploading the .sppkg to the tenant app catalog versus a site collection app catalog, and when they would use each. If they mention Node version pinning without being prompted, that is a strong signal, because SPFx is famously particular about Node versions and anyone who has actually shipped has been burned by it.

How do you call Microsoft Graph from an SPFx web part? You want to hear about MSGraphClient, the API permissions declared in package-solution.json, and the fact that those permissions go to the tenant-wide API access page and need an administrator to approve them. If they say they will just put a client secret in the code, end the interview.

What happens at the 5,000 item list view threshold? Everyone who has done real SharePoint work has hit this. Good answers cover indexed columns, filtering, folder or metadata partitioning, and knowing when a list is simply the wrong store and the data belongs in Dataverse or SQL. A weak answer is "increase the limit," which you cannot do in SharePoint Online.

How do you handle throttling? Real answers mention 429 responses, Retry-After headers, exponential backoff, and batching through PnPjs or the Graph batch endpoint. Anyone who has run a migration or a bulk update has fought this.

Describe a permission model you inherited and had to fix. You are listening for broken inheritance, item-level permissions on thousands of items, unique permissions causing scaling problems, and whether they moved things toward Azure AD security groups and SharePoint groups instead of individual user grants. Also listen for whether they mention sharing links and how those interact with your governance rules.

What would you do about a business process running on SharePoint Designer workflows? Anyone still recommending Designer workflows in 2026 has not been paying attention. You want a real conversation about Power Automate versus Azure Functions versus Logic Apps, with the licensing and premium connector implications named out loud.

For a take-home, keep it small and specific. Ask for an SPFx web part that lists items from a SharePoint list with paging, filters by a lookup field, handles the empty and error states, and uses PnPjs. Give them four hours of scope, not a weekend. What you are reading is: do they use the SPFx context properly rather than reaching for raw fetch with hardcoded URLs, do they respect the SharePoint theme variables so the web part does not look alien on your intranet, do they handle the list not existing, and is the property pane configurable rather than the site URL being hardcoded. Then ask them to explain a decision they made and what they would change with more time. The explanation tells you more than the code.

For a portfolio review, ask for a migration they ran. Get specifics: source version, volume, what broke, what metadata was lost, how they handled the term store, whether they did a delta pass, and how they cut over. Anyone who says a migration went perfectly did not run one.

Red flags

They suggest injecting JavaScript through a Script Editor or Content Editor web part, or using custom actions to load scripts. This was the old way. It is not supported on modern pages and it breaks when Microsoft ships. Ask instead: "What is your approach when the supported extensibility surface does not cover what we need?"

They pitch a farm solution, full-trust code, or a sandboxed solution for a SharePoint Online project. Their experience stopped around 2016 and they are applying on-prem thinking to a cloud tenant. Ask instead: "Which parts of your SharePoint experience are on-prem and which are online, and when did you last ship to SharePoint Online?"

Every problem gets a Power Automate flow, and the flow is owned by their personal account. This is the single most common piece of technical debt we inherit. Flows die when the owner leaves, premium connectors quietly generate license costs, and there is no source control, no environments and no rollback. Ask instead: "How do you make automation survive a person leaving the company?"

They cannot explain how a SharePoint app gets permission to read data. If they are fuzzy on Azure AD app registrations, application versus delegated permissions, admin consent, or the difference between Sites.Selected and the blunt Sites.ReadWrite.All, they will hand your tenant an over-permissioned app and call it done. Ask instead: "Walk me through granting an app read access to exactly one site and nothing else."

They talk about SharePoint as if it exists alone. Modern SharePoint is fused to Teams, OneDrive and the Microsoft 365 group model. Every Team has a SharePoint site behind it. If they do not know that, they will build something that fights the platform. Ask instead: "What happens in SharePoint when someone creates a Team, and how does that affect governance?"

When to hire this role, and how we staff it

Be honest about whether you need a SharePoint developer at all. If the real problem is that your document storage is a mess, you need an information architect and an administrator, not a developer. If the problem is that finance wants a better approval form, a Power Platform maker will get you there faster and cheaper. If the problem is that you want a customer-facing app, do not build it in SharePoint. SharePoint is an internal platform and every team that has tried to make it external has regretted it. And if you are on a legacy on-prem farm and mostly need to get off it, what you need is a migration team with tooling, not a permanent developer.

You need a real SharePoint developer when you have code-level customization inside a live tenant: SPFx components, Graph integrations, provisioning at scale, or a migration where the metadata and permission model matters to someone in compliance.

Digital Heroes staffs this as a small pod rather than a lone developer, because SharePoint work almost never stays in one lane. A typical engagement is one senior SPFx developer working in TypeScript and React who owns the code, a Microsoft 365 architect part-time for the tenant, permission and governance decisions, and a Power Platform person for the workflow layer where low-code is the right answer. On migrations we add a dedicated migration lead who owns the tooling, the inventory and the delta passes, because that is a specialist job and pretending otherwise is how you lose version history. Everything ships from your repo into your app catalog with your team on the pull requests, and provisioning lives in PnP PowerShell or PnP templates that you keep, so nothing depends on a person we happen to have assigned. When the migration ends and the volume drops, the pod shrinks instead of the salary staying the same.