News

WahInnovations has merged into MoreYeahs IT Technologies, enhancing our Salesforce solutions with AI and Data Engineering.

WahInnovations joined MoreYeahs.

Get in touch

SharePoint Development Services

Custom applications engineered on SPFx, React and TypeScript, integrated through Microsoft Graph and extended with Azure where SharePoint alone is not the right tool. Built by engineers who work in this stack every day, for clients across the US, Europe, Australia and the Middle East.

Talk to an engineer, not a salesperson See what we have built

When configuration stops being enough

Most organisations arrive here having already tried the no-code route. SharePoint is genuinely capable out of the box, and a great deal can be done with lists, libraries, standard web parts and a Power Automate flow. Then it stops.

The wall usually looks like one of these:

Each of those is an engineering problem with a known solution. None of them is solved by buying more licences or reconfiguring what is already there.

  • A stock web part does roughly what you need, but not the part that actually matters, and there is no way to change it.

  • A marketplace add-in fits eighty percent of the requirement and cannot be extended to cover the rest.

  • SharePoint needs to read from or write to a system that sits outside Microsoft 365: an ERP, an HR platform, a line-of-business database.

  • A Power Automate flow has grown into something unmaintainable, or hit a genuine limit of the low-code model.

  • Customisations built years ago are breaking, because they rely on a development model Microsoft has since retired.

What we build on SharePoint

SharePoint Framework is Microsoft's supported model for extending SharePoint Online, and it is where most of our development sits. We build web parts, application customisers, field customisers and command sets in React and TypeScript, using Fluent UI so they look native rather than bolted on. Because SPFx components run in the page rather than inside an iframe, they inherit the user's authentication context, respect existing permissions automatically and render correctly in the SharePoint mobile app. We build against the current SPFx version and test across tenant release rings, so a component does not behave differently for users on targeted release.

Full line-of-business applications that use SharePoint as the data and permissions layer rather than as a document store with a form on top. Contract management, asset registers, inspection and compliance systems, resource planning, quality management. We model the data properly (managed metadata, content types, site columns and lookups designed around the business rather than improvised as the build goes on), then engineer the interface on top in SPFx. Where the data model outgrows SharePoint lists, we move it to Dataverse or Azure SQL and keep SharePoint as the interface and document layer.

The value in most custom SharePoint work comes from data that does not live in SharePoint. Microsoft Graph gives a single authenticated interface into Teams, Outlook, Entra ID, OneDrive, Planner and the rest of Microsoft 365. We use it to build components that show a user their calendar alongside their tasks, create a Teams channel automatically when a project is approved, resolve reporting lines from Entra ID rather than a maintained list, or post an adaptive card into Teams when an approval is waiting. Permissions are scoped to the minimum the application needs and reviewed with your security team before anything is granted.

Connecting SharePoint to the systems your business already runs on: Dynamics 365, Power BI, Salesforce, SAP, HR and payroll platforms, document management systems and custom internal APIs. We build integrations through Azure Functions and Logic Apps rather than embedding credentials and logic in the front end, with secrets held in Key Vault and failures handled explicitly rather than silently. The result is an integration that survives a password rotation and an API version change, which is the part most integration work gets wrong.

If your SharePoint customisations were built on farm solutions, sandbox solutions, classic pages, JSLink or InfoPath, Microsoft has either retired or stopped investing in the model underneath them. We assess what exists, identify what is actually at risk versus what merely looks dated, and rebuild the parts that need rebuilding: farm solutions into SPFx, InfoPath forms into Power Apps, classic workflows into Power Automate. Most modernization runs in phases so business processes keep working while the rebuild happens around them.

Generating contracts, reports, certificates, proposals and compliance documents from SharePoint data: populated from templates, formatted correctly, versioned, filed in the right library with the right metadata, and routed for approval. Built with Azure Functions where the formatting is complex and Power Automate where it is not. For document-heavy organisations this is frequently the highest-return automation available, because it removes a task people do daily and get wrong occasionally.

Developer writing SharePoint Framework code across two monitors

SPFx web parts and extensions

SharePoint Framework is Microsoft's supported model for extending SharePoint Online, and it is where most of our development sits. We build web parts, application customisers, field customisers and command sets in React and TypeScript, using Fluent UI so they look native rather than bolted on. Because SPFx components run in the page rather than inside an iframe, they inherit the user's authentication context, respect existing permissions automatically and render correctly in the SharePoint mobile app. We build against the current SPFx version and test across tenant release rings, so a component does not behave differently for users on targeted release.

Built with
SPFxReactTypeScriptFluent UI
Custom business application showing reports and dashboards on a laptop

Custom business applications on SharePoint

Full line-of-business applications that use SharePoint as the data and permissions layer rather than as a document store with a form on top. Contract management, asset registers, inspection and compliance systems, resource planning, quality management. We model the data properly (managed metadata, content types, site columns and lookups designed around the business rather than improvised as the build goes on), then engineer the interface on top in SPFx. Where the data model outgrows SharePoint lists, we move it to Dataverse or Azure SQL and keep SharePoint as the interface and document layer.

Built with
Content typesManaged metadataDataverseAzure SQL
Team reviewing a dashboard that brings Microsoft 365 data into one view

Microsoft Graph development

The value in most custom SharePoint work comes from data that does not live in SharePoint. Microsoft Graph gives a single authenticated interface into Teams, Outlook, Entra ID, OneDrive, Planner and the rest of Microsoft 365. We use it to build components that show a user their calendar alongside their tasks, create a Teams channel automatically when a project is approved, resolve reporting lines from Entra ID rather than a maintained list, or post an adaptive card into Teams when an approval is waiting. Permissions are scoped to the minimum the application needs and reviewed with your security team before anything is granted.

Built with
Microsoft GraphTeamsEntra IDAdaptive Cards
Business team agreeing an integration between SharePoint and their systems

Third-party and line-of-business integration

Connecting SharePoint to the systems your business already runs on: Dynamics 365, Power BI, Salesforce, SAP, HR and payroll platforms, document management systems and custom internal APIs. We build integrations through Azure Functions and Logic Apps rather than embedding credentials and logic in the front end, with secrets held in Key Vault and failures handled explicitly rather than silently. The result is an integration that survives a password rotation and an API version change, which is the part most integration work gets wrong.

Built with
Azure FunctionsLogic AppsKey Vault
Planning session mapping out the modernization of legacy customisations

Classic to modern modernization

If your SharePoint customisations were built on farm solutions, sandbox solutions, classic pages, JSLink or InfoPath, Microsoft has either retired or stopped investing in the model underneath them. We assess what exists, identify what is actually at risk versus what merely looks dated, and rebuild the parts that need rebuilding: farm solutions into SPFx, InfoPath forms into Power Apps, classic workflows into Power Automate. Most modernization runs in phases so business processes keep working while the rebuild happens around them.

Related
Documents generated automatically from a laptop

Document generation and automation

Generating contracts, reports, certificates, proposals and compliance documents from SharePoint data: populated from templates, formatted correctly, versioned, filed in the right library with the right metadata, and routed for approval. Built with Azure Functions where the formatting is complex and Power Automate where it is not. For document-heavy organisations this is frequently the highest-return automation available, because it removes a task people do daily and get wrong occasionally.

Built with
Azure FunctionsPower AutomateTemplates

Modernising legacy SharePoint customisations

This deserves more than a paragraph, because it is an urgent problem with a small supplier pool and most organisations underestimate it until something breaks.

What has actually been retired

  • InfoPathEnd of life
  • SharePoint 2010 and 2013 workflowsRetired in Microsoft 365
  • Sandbox solutions with codeGone
  • Farm solutionsNot in SharePoint Online
  • Classic pagesNo further investment

Classic pages still render, but receive no investment and increasingly diverge from the modern experience your users see everywhere else.

How we assess before recommending anything

We inventory every customisation, establish what it does, who uses it and what it depends on, then classify each one. A significant share of legacy customisation turns out to be replaceable with modern standard functionality that did not exist when it was built. Telling you that is cheaper for you and better for us than rebuilding something nobody needs.

Retire itReplace with out-of-the-boxRebuild itLeave it alone

The rebuild paths

Farm or sandbox solutionSPFx web part or extension
InfoPath formPower Apps, or a custom SPFx form where logic is complex
SharePoint 2010 / 2013 workflowPower Automate, with Azure Functions for anything beyond the low-code limits
JSLink field renderingSPFx field customiser or column formatting JSON
Classic publishing pageModern page with custom SPFx components
Server-side timer jobAzure Function on a schedule

How we engineer, not just what we build

Every development firm says it has experienced developers. Here is what we actually do, so you can judge for yourself.

Source control and code review

All code lives in version control from day one, in Azure DevOps or GitHub (we work in both), with a branching model, pull requests and peer review before anything merges. You get access to the repository during the engagement, not at the end of it.

CI/CD and deployment

SPFx packages are built and deployed through an automated pipeline rather than by hand. That means a deployment is repeatable, reversible and logged, instead of depending on one person remembering the right sequence.

Environment strategy

Development, test and production are separated, usually a dedicated developer tenant, your test environment and your production tenant. Nothing reaches production without having run somewhere else first. Where you do not have a test tenant, we will tell you why you need one before we start.

Community patterns over reinvented code

We build on PnPjs and the Microsoft 365 PnP patterns rather than writing our own abstractions over the SharePoint APIs. Community-maintained libraries are better tested than anything a single project can produce, and they mean the next developer who opens your codebase recognises what they are looking at.

Accessibility and responsive behaviour

Treated as build requirements, not a retrofit. Components are keyboard-navigable, screen-reader compatible and tested in the SharePoint mobile app rather than only resized in a browser. For public-sector and regulated clients this is frequently a procurement requirement; for everyone else it is simply better software.

Documentation and handover

Every engagement ends with technical documentation, deployment instructions and a handover session, whether or not you continue with us. You should be able to take what we build to another supplier, or maintain it internally, without renegotiating. A supplier who makes themselves impossible to leave is not a partner.

Our SharePoint development stack

We build on the current SharePoint Framework release and test across tenant update rings. For clients still running SharePoint Server on-premises, we work in the full-trust and CSOM models as well, and can advise on what moving to SharePoint Online would mean for your existing customisations specifically, which is usually the deciding factor in the business case.

Front end

  • React
  • TypeScript
  • Fluent UI
  • SCSS

SharePoint

  • SharePoint Framework (SPFx)
  • PnPjs
  • SharePoint REST API
  • CSOM (on-premises)

Microsoft 365

  • Microsoft Graph
  • Teams SDK
  • Adaptive Cards

Power Platform

  • Power Automate
  • Power Apps
  • Dataverse
  • Custom connectors

Azure

  • Functions
  • Logic Apps
  • Blob Storage
  • Key Vault
  • Entra ID app registrations

Data

  • SharePoint lists
  • Dataverse
  • Azure SQL

Engineering

Across every layer
  • Azure DevOps / GitHub
  • Automated CI/CD
  • Jest
  • ESLint

How we work with your team

01

Fixed-scope project

A defined build with an agreed specification, timeline and cost. Best when the requirement is clear: a specific application, a set of components, a defined integration.

02

Dedicated engineering team

SharePoint and Power Platform engineers working as an extension of your team on a monthly basis, in your stand-ups and your backlog. Best for continuous development or a roadmap that will evolve as it is delivered.

03

Ongoing development retainer

A block of engineering capacity each month for enhancement, fixes and small builds. Best once a platform is live and changing continuously.

Practical details that matter more than the commercial model: our engineers join your existing tools rather than asking you to join ours, and communicate in writing by default so decisions are traceable.

Engineering we have delivered

Trivandi: a modular SPFx intranet across four countries

A multi-module intranet platform engineered for Trivandi and running across offices in Brisbane, Dubai, London and Riyadh, built modularly so capability could be added without rebuilding the core. It is engineered as a modern, scalable SharePoint Online solution using SPFx, React, TypeScript, PnPjs, Microsoft Graph and integrated HR services, delivering secure, responsive and highly reusable digital experiences.

Custom web parts and application customizers are built in React and TypeScript, with component-scoped SCSS Modules for maintainable, consistent styling. PnPjs provides efficient access to SharePoint lists and document libraries, while Microsoft Graph supports Azure AD group membership resolution and role-based access.

See the intranet page

Integration: BreatheHR and CMAP CRM inside SharePoint

Integration with BreatheHR enables employee and policy data to be consumed directly within the platform. CMAP CRM was integrated for the Projects department, so they can see a status update without touching the CRM.

Brand consistency is supported through Google Fonts integration, while rich-text authoring enables flexible content management. The solution also includes in-browser PDF previews, responsive desktop and mobile experiences, toast notifications, and reusable loading and pagination components for a consistent user experience.

75%faster approvals

IT project prioritisation portal with automated multi-level approvals

Project requests ran on email and paper with no budget checks. We built SPFx dashboards and Power Automate routing across department heads, finance and IT, with real-time budget validation and full approval history.

98%adoption in month one0budget overruns since launch
Read the full case study
Trivandi intranet: component structureSanitised view of how the platform is put together.
In the page (SPFx)
  • Custom web parts
  • Application customizers
  • React + TypeScript
  • SCSS Modules
Data and identity
  • PnPjs → SharePoint lists and libraries
  • Microsoft Graph → Azure AD groups
  • Role-based access
Connected systems
  • BreatheHR (employee and policy data)
  • CMAP CRM (project status)
  • Google Fonts
See all SharePoint case studies

SharePoint development: common questions

What technical teams ask us before a SharePoint build.

SharePoint Framework is Microsoft's supported model for building custom components in SharePoint Online. It matters because it is the only extensibility model Microsoft is actively investing in. Solutions built on it continue working through the platform's release cycle, while the older models have been retired one by one. It also runs client-side inside the page, so components inherit the user's permissions automatically rather than requiring a separate security model.

Correctly built code does not. Solutions on SPFx and the supported APIs continue working through Microsoft's release cycle. What breaks is code built on unsupported customisations, deprecated frameworks or classic-page techniques Microsoft has retired. We build only on the supported model, and for clients on a support agreement we test against Microsoft's release roadmap before changes reach their tenant.

Yes, and a meaningful share of our work starts that way. We begin with a code and architecture review, tell you plainly what is sound, what carries risk and what should be replaced, and then extend or rebuild accordingly. We do not require a rebuild in order to work with you, and we will say so when targeted fixes are the better answer.

Both. SharePoint Online requires client-side development through SPFx and the Graph and REST APIs, with no server-side code. On-premises still allows full-trust server-side development but carries the infrastructure, patching and upgrade burden with it. If you are weighing a move, we can tell you specifically what would happen to your existing customisations. That is usually the deciding factor in the business case, and the part generic migration advice never covers.

Through an automated CI/CD pipeline, into separated development, test and production environments. Deployments are repeatable, logged and reversible. If you do not currently have a test environment we will raise it before the build starts. Deploying untested code straight into a production tenant is the single most common cause of the problems we get called in to fix.

Yes. All custom code we develop may be owned by you, subject to the agreed contractual terms, while any third-party libraries, Microsoft technologies or pre-existing components remain subject to their respective licences and ownership. The code lives in a repository you have access to throughout, and every engagement ends with documentation and a handover session.

Whenever it will genuinely do the job. Power Automate and Power Apps are faster to build, cheaper to maintain and easier for your own team to change. Custom development earns its place when the requirement exceeds what the low-code model supports, when performance or scale matters, or when the interface needs to sit natively inside SharePoint rather than beside it. We use both, frequently in the same solution, and we will not sell you custom engineering for something a flow would handle.

Other SharePoint services

01SharePoint Intranet Development02Custom SharePoint DevelopmentCurrently viewing03Power Automate & Power Apps04SharePoint Migration05SharePoint Managed Services

Send us the problem, not the brief

Most of our engagements start with someone describing one specific thing they cannot get SharePoint to do. Tell us what it is. We will tell you whether it needs custom development, whether Power Platform would do it faster, or whether there is a standard capability you have not found yet, before anyone talks about scope or cost.

Response within one business day from a technical lead, not a bot.
NDA on request before you share anything sensitive.
Prefer to book directly? Grab a 30-min architecture slot on our calendar.