Overview
Custom code should be the exception, and it should be justified
Every custom component is something your team will need to maintain, upgrade and eventually replace. We build custom when a real requirement genuinely cannot be met otherwise — and we will tell you when an out-of-the-box configuration would do the same job for nothing.
- Modern SPFxComponents built on current SharePoint Framework versions with React and Fluent UI, so they keep working through tenant updates.
- Graph and REST integrationData pulled from across Microsoft 365 — calendars, users, groups, Teams — with permissions requested and approved properly through Entra ID.
- Tested against real conditionsBuilt and validated with production-scale data volumes, not a ten-item demo list.
- Handed over as sourceYou get the repository, the build pipeline and the documentation. No dependency on us to make a change.
Architecture
Where an SPFx solution actually sits
The permission grant in Entra ID is the part security teams question, and the part worth settling before development starts rather than after.
What is included
What we build
SPFx web parts
Custom components for scenarios the out-of-the-box parts do not cover — dashboards, directories, aggregations, request interfaces.
Extensions
Application customisers for consistent headers and footers, field customisers, and command sets adding actions to library toolbars.
Graph integrations
Applications reading and writing across Microsoft 365 with the correct delegated or application permission model.
Teams applications
SPFx components surfaced as Teams tabs and personal apps, so the same solution works in both places.
Line-of-business apps
Departmental applications on the Power Platform or as custom web applications, integrated with SharePoint as the data layer.
API integration
Connecting SharePoint and Power Platform solutions to external systems through Azure API Management or custom connectors.
In practice
On the permission model, which is where this usually gets complicated
An SPFx component calling Microsoft Graph does not get access simply because you wrote the code. Permissions are requested in the solution package and must be approved by a tenant administrator against the SharePoint Online Client Extensibility service principal — a shared principal, which means approving a permission for one web part grants it to every SPFx component in the tenant.
That has real security implications, and security teams are right to question it. When a client needs isolation, the answer is a dedicated app registration with an Azure-hosted API in front of it, rather than the default pattern.
Getting this settled early matters, because a security review that starts after development is finished can delay a launch by weeks.
Questions
Common questions
Will custom components survive Microsoft’s updates?
Components on supported SPFx versions using documented APIs are stable. We flag anything relying on undocumented behaviour, because that is what breaks.
Do we own the code?
Yes. Source, build configuration and documentation are handed over at project close.
Can you work with our existing development team?
Yes — as an extra pair of hands, or in a review and mentoring role on SharePoint-specific architecture.
How do you handle deployment?
Solution packages deployed through the tenant app catalogue, tested in a staging environment first. We can set up a CI pipeline if you do not have one.