Lyron
Microsoft 365

SharePoint Web Parts with SPFx

One building block that does exactly what your department is missing – built with the SharePoint Framework, deployed to your app catalog and configurable by your own editors.

Context

First check whether the built-ins already do it

SharePoint Online ships with a lot: lists, libraries, news, quick links, highlights. Before we write a line of code we go through whether your case is already covered. Surprisingly often it is – and then we tell you, instead of selling a project.

When the built-ins are not enough, it usually ends up in an Excel file on a shared drive or in a separate tool with its own login. Both cost more than a web part: one in data quality, the other in licences and attention.

A custom web part instead lives where your people already are. It inherits your permissions, your design and your sign-in. And the decisive part: whatever changes later, your editors change themselves – not us at an hourly rate.

Use cases

What a web part is worth building for

We start with the case that costs the most manual work today. Further web parts share the same components later and become cheaper as a result.

Most common starting point

Departmental overviews

The most common case: one view that joins several lists, filters and sorts them the way the department actually works.

Several listsCustom filtersGroupingExport

Data entry forms

Forms with logic: fields appear depending on the selection, required fields follow the case.

Dependent fieldsValidationPrefilling

Data from other systems

ERP figures, order status, stock levels – visible in the intranet without anyone signing in twice.

REST APIMicrosoft GraphDatabase

Personalised views

Everyone sees their area, their tasks, their location – based on the sign-in, not a dropdown.

By departmentBy locationBy role

Status overviews

What is open, what is stuck, what is done. At a glance instead of spread across four lists.

Traffic lightsDeadlinesOwnership

Surfaces in Teams and Viva

The same web part in Microsoft Teams and through Viva Connections on a phone – one block, three places.

Teams tabViva ConnectionsMobile
Example

What your editors see afterwards

The property pane of a finished web part. Everything shown here can be changed without a developer.

Property pane
Heading
Open approvals
Data source
List “Requests 2026”
Number of items
8
Own department only
on
Show completed
off
Layout
CardsCompactTable

What that means day to day

  • check_circleEditors change the heading, source and layout themselves – no ticket, no developer.
  • check_circleThe same web part can sit on several pages with different settings.
  • check_circleNew requirements often mean one changed setting instead of a new project.
  • check_circleWhich fields become configurable we decide together – too many options confuse more than they help.

This pane is the real difference between a web part and a one-off: it decides whether you need somebody for every change.

Illustrative settings. Which fields become configurable we define before development – too many options make a web part unusable.

How it works

How a web part project runs

  • Sharpen the requirement

    A session with the people who will use it. We look at today's Excel file or the tool alongside – the requirement is usually more complete there than in any written brief.

  • Check the built-ins

    Would a list with a custom view do? A list plus Power Automate? If so we recommend that and you save the project. This check is part of the quote, not an extra.

  • Build with SPFx

    Development with TypeScript and React against your real data in a test environment. Interim versions are clickable, not screenshots.

  • Make it configurable

    Everything that experience says will change – title, source, count, layout – moves into the property pane. What gets hard-wired is a deliberate decision and we document it.

  • Deploy and hand over

    Signed package into your app catalog, permissions clarified, source code into the repository, a 60-minute session for your editors.

Impact

What changes for the department

Today

  • The department maintains an Excel file on a shared drive
  • For the same information you click through four lists
  • An extra tool with its own login and its own licence cost
  • Small changes require an external provider
  • On a phone the view is unusable

With a custom web part

  • The data sits in SharePoint, with your permissions
  • One view shows what belongs together
  • No extra login, no extra licence
  • Title, source and layout are changed by your editors
  • The same web part runs in Teams and on a phone
Limits

When we advise against a web part

Custom code is a commitment, not just a solution. In these four cases we recommend something else:

  • When the built-ins are enough. A list with a custom view, a highlights web part or a Power Automate rule cost nothing extra and do not age. We check that first and say so even when it costs us the project.
  • When nobody maintains the data. A web part makes bad data more visible, not better. If the underlying list has not been touched for two years, the first project is cleaning the data – not the view on top of it.
  • Custom code needs maintenance. Microsoft ships SPFx on a roughly quarterly rhythm and the move to React 18 is under way. A web part nobody looks after becomes a problem in two years. Budget for maintenance – with us or in-house.
  • When it is really a process. Anyone who needs approvals, deadlines and escalations needs a workflow, not a view. Then Power Automate or n8n is the better start, and the web part comes later as the surface on top.
Systems

Runs inside your Microsoft 365 environment

SharePoint OnlineMicrosoft GraphMicrosoft TeamsViva ConnectionsEntra IDREST APIsPower Automate
Scope and price

Scope and price

The entry price covers one clearly scoped web part including rollout and handover. What moves the price, we say before the quote.

from €1,900 per web part
  • Requirements workshop with the eventual users
  • Check whether SharePoint built-ins are sufficient
  • One web part with a clearly scoped function
  • Connection to SharePoint lists or Microsoft Graph
  • Configurable properties for your editors
  • Deployment to the app catalog including a permission concept
  • Source code handover, documentation and a 60-minute session

What increases the price

  • Connection to a system outside Microsoft 365
  • Write access instead of display only
  • Complex permission logic across departmental boundaries
  • Multilingual with separate editorial content per language
  • Surfacing as a Copilot app in addition to the web part

If several web parts are planned from the start, the intranet suite from €5,900 is cheaper than separate projects. We quote the binding fixed price after the workshop.

All prices excl. VAT · maintenance and the React 18 migration optionally via a support package

Included

What you get

  • Signed web part package

    Deployed as .sppkg in the app catalog and signed off with real data

  • Source code with no licence lock-in

    Complete repository with build pipeline – you could keep building yourself at any time

  • Documented property pane

    Which setting does what, in language your editors understand

  • Training and 30 days of support

    60 minutes for the editors plus guidance through the adoption phase

Questions & answers

Frequently asked questions about SharePoint web parts

That is exactly what we check first, and often it is the right answer. A web part pays off when several sources come together, when the display depends on who is signed in, or when logic is needed that list views cannot do. For “the same list but prettier” we do not recommend it.
Whatever sits in the property pane, yes – and that is exactly what we discuss before development. Title, data source, count, layout, filters: everything experience says will change becomes configurable. Changes to the function itself need code, and for that you have the repository.
Existing web parts keep running; Microsoft has announced no deprecation. What to plan for is the React 18 migration, whose broad enablement is scheduled for the SPFx 1.24 GA. We build so that migration stays manageable, and take it on via a support package if you want. More in our guide to SPFx 1.24 and Copilot Apps.
Deploying to the app catalog requires tenant administrator rights, and if the web part accesses Microsoft Graph an administrator has to consent to the permissions once. We list exactly which rights are needed in advance – nobody should have to agree to a blanket request.
Yes, the same web part can be surfaced as a Teams tab and through Viva Connections on a phone. We plan for that from the start, because adapting to small screens afterwards usually costs more than thinking about it up front.
Less than the first, because the setup, build pipeline and design components already exist. If several are planned from the outset, the intranet suite from €5,900 is the cheaper route.
Related solutions

These solutions fit alongside

SharePoint Intranet Suite

Several coordinated web parts plus a design system – cheaper than three separate projects.

SharePoint Copilot Apps

The same basis, additionally on the Copilot surface in Teams and SharePoint.

SharePoint Document Workflows

When it is really about approvals and deadlines rather than a view.

SharePoint Migration

Replacing old customisations such as JSLink or InfoPath with maintainable web parts.

Which Excel file do we replace first?

Bring whatever your department maintains on the side to the free intro call. We will tell you honestly whether SharePoint can already do it – or whether a custom web part pays off.

Book a free intro call
arrow_back Back to all products