Development # SharePoint development services built inside your own tenant Custom applications, integrations and SPFx web parts for SharePoint Online and Microsoft 365. We design before we build, stay Microsoft-native wherever possible, and deliver everything inside your environment – no external hosting, no third-party dependencies. [ Talk through a build ](https://contentformula.com/discuss-a-project/) [ See what we build ](#what-we-build) Typical contained builds run three to eight weeks. In short What we build SPFx web parts and extensions, custom business applications, integrations with line-of-business systems, and increasingly agents built on Copilot Studio. How we start Never with technology. Requirements and process first, workflow mapped, wireframed and signed off before any development begins. Where it runs Inside your Microsoft 365 tenant. No external hosting, no third-party dependencies, no data leaving your environment. How long Three to eight weeks for a contained build, quoted as a fixed price against an agreed scope. Scope ## What SharePoint development services actually cover Three kinds of work, and most projects involve more than one. ### Advanced branding & navigation Custom themes, mega-menus and layout extensions that take an intranet beyond what site settings allow. This is where SPFx earns its place - the modern page editor is genuinely good now, but it stops short of a navigation model designed around how your organisation actually works. ### Data integration SharePoint integrations connecting lists and document libraries to the systems your business already runs - CRM, ERP, HR, finance, ITSM. Custom connectors where a standard one does not exist, and Microsoft Graph where the data is already inside Microsoft 365. ### Specialised business tools Interactive dashboards, resource and room booking, structured approval processes, read-tracking for compliance. The applications that do not exist off the shelf because they are specific to how you work. ### Agents & extensibility Increasingly this work means agent development - Copilot Studio, custom connectors feeding Copilot, and retrieval over your own content so answers come from your material rather than the open web. [More on AI & search](https://contentformula.com/solutions/microsoft-copilot-consulting/). Method ## Four things we do differently 1 ### UX & discovery first We never start with technology. We understand the requirements and the process, map the workflow, wireframe it and get sign-off before any development starts - so what gets built is what users actually need rather than what was assumed at kick-off. ** On larger programmes this is a [digital workplace discovery](https://contentformula.com/solutions/digital-workplace-discovery/) in its own right. On a contained build it is a shorter piece of the same work. 2 ### Microsoft-native first We use Power Apps, Power Automate and SharePoint before reaching for custom code. Solutions stay maintainable, supportable and inside your existing licensing, and you do not end up paying to build something you already own. This is the part of our approach that costs us work. If configuring what you have will do the job, that is what the recommendation says. 3 ### Everything lives in your tenant No external hosting, no third-party dependencies, no data leaving your environment. Your IT and security teams stay in control, and there is no supplier-owned infrastructure to unpick if you change providers. Worth asking any development partner directly, because the answer varies more than you would expect. 4 ### Quality built in, not bolted on Dedicated QA throughout the build rather than a test phase at the end, a structured UAT with a written test plan, and bug fixes during UAT built into the project. - Typical contained builds run three to eight weeks - Fixed price against an agreed scope, quoted after we understand the process - SharePoint Online. We do not develop against on-premises SharePoint Server Where the line falls ## When does custom code beat low-code? The question worth asking a development partner, and the one most avoid answering. Power Apps and Power Automate cover a great deal, and where they fit we use them – it keeps the solution inside licensing you already hold and inside a support model your own team can pick up. Three things push a requirement past low-code, and it is usually obvious which one you are hitting. Trigger 1 SPFx ### The user experience has to be designed Power Apps gets you a working interface quickly, within its own interaction patterns, and embedded in a SharePoint page it always reads as a separate application sitting inside one. That is fine for a form somebody completes occasionally. It is not fine when the experience genuinely matters - a tool used fifty times a day, or something that has to feel like part of the intranet rather than a visitor to it. Where the UX needs designing rather than assembling, SPFx gives us control over layout, interaction and page integration that a canvas app cannot. Trigger 2 SPFx + Azure ### The data is genuinely relational SharePoint lists are flat, with lookups. That works well up to a point. Past a certain number of related entities you are working around the platform rather than with it, and the workarounds are what later becomes unmaintainable. Where the requirement is a real relational database - multiple related tables, referential integrity, joins, volume - that belongs in a SQL database in Azure, with SPFx over the top for the interface. Dataverse sits between the two and is a reasonable fit for straightforward builds. Our experience is that a requirement which has genuinely outgrown SharePoint lists usually warrants the full step rather than an intermediate one, so in practice we go from lists to SQL. Trigger 3 Multi-country, multi-language ### There is real processing to do Power Automate is built for orchestration - move this, notify them, wait for approval. It is not built for computation, and at volume the run limits and timeouts stop being a technicality and start being the reason a process fails at month end. Where there is high compute or intensive processing involved, that work moves to Azure components and the flow calls out to them rather than attempting it inside the platform. In practice it is rarely one or the other. Most builds that cross any of these lines end up as a mix of SPFx and Azure** – SPFx for the interface and the page integration, Azure for the data or the processing behind it, and Power Platform still doing the parts it does well. #### Power Platform work in its own right Where the answer is Power Apps or Power Automate rather than custom development, that is a different conversation with a different shape. [ Power Platform consulting ](https://contentformula.com/solutions/power-platform-consulting/) Afterwards ## Built so your own team can keep it running Because we build Microsoft-native wherever possible, a good deal of what we deliver can be maintained by the people who own the process rather than by us. Process owners adjusting their own Power Automate flows. A key user managing an app that supports their team’s work. That is deliberate, and it means less ongoing support is needed than a comparable custom build would demand. Where you do want support, our [SharePoint support services](https://contentformula.com/solutions/sharepoint-support-services/) cover the solutions we have built. Handing something over only works if it is governed. Environments, permissions, naming conventions, ownership and a review cycle all need to exist before a maintainable solution becomes somebody else’s problem – and [governance is a service we sell, implement and advise on](https://contentformula.com/solutions/sharepoint-support-services/) rather than an assumption we leave you to manage. Boundaries ## What we do not do If your project sits in the right-hand column we will say so early and point you somewhere better. #### Ours - SPFx web parts, extensions and field customisers - Custom business applications on SharePoint and Microsoft 365 - Integrations with line-of-business systems, and custom connectors - Microsoft Graph development - Agents & Copilot extensibility - Azure components where additional processing or intelligence is needed - UX, wireframing & information architecture #### Not ours - On-premises SharePoint Server development - Standalone web or mobile applications outside Microsoft 365 - Dynamics 365 & CRM implementation - Data warehousing & analytics platform builds - Staff augmentation or developers by the day - Offshore delivery at volume **On the last two** Several firms on this market sell SharePoint developers by the day, and for some organisations that is genuinely the right purchase. It is not what we do. We take responsibility for the outcome rather than for the hours, which means we scope tightly and turn work down when the fit is wrong. ## Start with the process, not the build Tell us what is not working and we will tell you whether it needs custom development at all. If configuring what you already own would do it, that is a shorter and cheaper conversation – and we would rather have it now than three months in. [ Talk through a build ](https://contentformula.com/discuss-a-project/) Or [ start with a discovery ](https://contentformula.com/solutions/digital-workplace-discovery/) Common questions ## SharePoint development, answered ### What are SharePoint development services? SharePoint development services cover building tailored web parts, extensions, applications and integrations for SharePoint Online, most commonly using the SharePoint Framework – SPFx – with TypeScript, React and REST APIs. The work bridges the gap between what Microsoft 365 does out of the box and what an organisation actually needs: custom branding and navigation beyond site settings, integrations with line-of-business systems, and business applications that do not exist off the shelf. Increasingly it also covers agent development on Copilot Studio and extending Copilot over an organisation’s own content. ### What is SPFx, and why does it matter? The SharePoint Framework is Microsoft’s supported model for building client-side web parts and extensions that run inside modern SharePoint pages. It matters because it is the option that stays inside your tenant and inside Microsoft’s own support boundary – the code runs in SharePoint rather than on infrastructure somebody else owns. Older approaches, and some third-party alternatives, put parts of your intranet outside your environment. We stay as close to SPFx as the requirement allows for exactly that reason. ### How long does a custom SharePoint build take? Three to eight weeks for a contained build – a web part, an integration, or an application supporting a single process. That range assumes the requirement is understood before development starts, which is why we wireframe and get sign-off first. Larger programmes are scoped in phases rather than quoted as one number, and if a supplier gives you a timeline before understanding the process, the timeline is a guess. ### Do we need custom development, or will Power Apps do it? Often Power Apps or Power Automate will do it, and where that is true we will say so – it keeps the solution inside licensing you already hold and lets your own team maintain it. Three things push a requirement past low-code. If the user experience has to be designed rather than assembled, that points to SPFx. If the data is genuinely relational – multiple related tables, referential integrity, volume – that points to Azure with SPFx over the top. And if there is high compute or intensive processing involved, Power Automate is the wrong tool because it is built for orchestration rather than computation. Most builds that cross one of those lines end up as a mix of SPFx and Azure. The honest version of this answer costs us work fairly regularly, which is the point of giving it. ### Where does the code and data live? Inside your Microsoft 365 tenant. No external hosting, no third-party services in the path, and no data leaving your environment. Where additional processing or AI capability is genuinely required we use Azure components, still within your subscription. This matters more than it sounds: it means your IT and security teams keep control, and there is no supplier-owned infrastructure to unpick if you decide to work with somebody else. Your privacy matters We use cookies to enhance your experience. You can accept, reject, or customise your choices. Learn more via our links below. Functional Functional Always active Essential for site features. Preferences Preferences The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user. Statistics Statistics The technical storage or access that is used exclusively for statistical purposes. Helps us understand site use. Marketing Marketing Used to show relevant ads. - [Manage options](#) - [Manage services](#) - [Manage {vendor_count} vendors](#) - [Read more about these purposes](https://cookiedatabase.org/tcf/purposes/) Accept all Reject all View preferences Save preferences [View preferences](#) - [{title}](#) - [{title}](#) - [{title}](#) Your privacy matters To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behaviour or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions. Functional Functional Always active Essential for site features. Preferences Preferences The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user. Statistics Statistics The technical storage or access that is used exclusively for statistical purposes. Helps us understand site use. Marketing Marketing Used to show relevant ads. - [Manage options](#) - [Manage services](#) - [Manage {vendor_count} vendors](#) - [Read more about these purposes](https://cookiedatabase.org/tcf/purposes/) Accept Reject all View preferences Save preferences [View preferences](#) - [{title}](#) - [{title}](#) - [{title}](#) Manage consent Manage consent