A SharePoint intranet can look disappointingly similar to a shared folder with a homepage: technically available, rarely visited and difficult to navigate. Marketplace apps can change that quickly, but only if they solve a real user problem without creating a new support, security or budget problem for IT.
This SharePoint marketplace app buying guide is for the person asked to make the intranet more useful without commissioning months of bespoke development. It covers what to check before a trial, how to compare the cost of buying against building, and when an app is the right answer.
Start with the problem, not the app catalogue
Marketplace listings make it easy to start with features. A news carousel looks good. An organisation chart feels useful. A personalised dashboard sounds like a quick win. The better starting point is the point of friction your people already recognise.
Perhaps staff cannot find the latest policy, new starters do not know who does what, internal news is missed, or the intranet does not feel like part of the organisation. Each is a specific job to solve. Write it down in plain terms, then decide what success looks like. For example, a better people directory should reduce the time spent asking colleagues who owns a process. Better navigation should get staff to common resources in fewer clicks.
This matters because an app that is impressive in a demonstration can still be unnecessary. If standard SharePoint functionality already handles the job well, keep it simple. Buy where the gap is clear and the improvement will be visible to users.
Check how the app fits Microsoft 365
The most useful SharePoint marketplace apps feel like a natural part of the environment people already use. They should work within modern SharePoint, respect the site’s existing design and avoid sending users into a separate portal for everyday tasks.
Confirm where data is processed and stored
Ask a direct question: does the app keep data inside your Microsoft 365 tenant, or does it rely on external hosting? There are valid models for both, but they have different implications for security review, data protection, access management and ongoing assurance.
For many small and mid-sized organisations, native SharePoint Framework apps are the lower-friction route. They run within the Microsoft 365 environment and can use the permissions and identity controls already in place. That does not remove the need for due diligence, but it makes the technical and governance conversation more straightforward.
Check the permissions requested during installation. An app should only request the access it genuinely needs. If the explanation is vague, or the permission level appears disproportionate to the feature, ask for clarification before moving forward.
Test branding and page behaviour
An app should inherit the look and feel of the intranet rather than forcing a competing visual style. Test it on a representative communication site, including on mobile. Look at spacing, colours, page load behaviour and accessibility, not just the feature itself.
Also check how editors will use it. A web part can be technically capable but still become a burden if every update requires specialist knowledge. Communications teams and site owners need to be able to change content, select items and manage settings without raising a ticket for routine work.
Use a trial to test real conditions
A free trial is more valuable than a polished sales call because it reveals what happens in your tenant, with your pages and your users. Install the app in a safe test site and give it a defined assessment period, usually one or two weeks.
Avoid testing every available feature at once. Pick one use case and involve the people who will own it after launch. For a news carousel, that may be internal communications. For a people directory, involve HR or the team responsible for employee information. For navigation, include staff who regularly answer “where can I find?” questions.
During the trial, assess four practical points:
- how long installation and initial configuration actually take;
- whether the app behaves as expected with your tenant branding and permissions;
- whether content owners can manage it confidently; and
- whether staff can understand and use it without instructions.
The final point is often overlooked. An intranet feature does not need to be novel. It needs to be useful enough that people return to it. A simple welcome banner that directs employees to the right resources may do more for adoption than a complex feature that requires explanation.
Compare buying with custom development honestly
Custom development has a place. It is appropriate when a requirement is genuinely unique, involves a specialised business process or must connect several systems in a way an off-the-shelf app cannot. But it is often chosen for standard intranet needs that have already been solved well by productised web parts.
Put the comparison on paper. A custom SPFx web part for a familiar requirement can easily cost £8,000 or more once design, build, testing, deployment and project management are included. It may also create a future support obligation whenever SharePoint changes or the original developer moves on.
A production-ready app may cost £249 per year for an individual web part, with installation and configuration included, and be live within days rather than months. That is not automatically the better choice. The app still needs to meet the requirement. But if it does, the commercial case is usually clear.
Bundles can make more sense where several parts of the intranet need attention at once. Rather than buying isolated features over time, assess the combined need for navigation, news, employee information, engagement and personalised content. A bundle should be judged on the features you will deploy, not on the number of features you might use one day.
ThePoint’s SharePoint Experience Pack, for example, offers individual web parts from £249 per year, a five-app Starter Bundle from £999 per year, and all 18 apps from £2,499 per year for up to 500 users. The relevant point is not that every organisation needs all 18. It is that published pricing allows a buyer to make a proper buy-versus-build decision before a drawn-out procurement exercise.
Look beyond the first installation
An app is not a one-off purchase if it becomes part of the intranet. Ask what support looks like after deployment. Is there a clear route for raising issues? Are updates included in the licence? Will the supplier help if a Microsoft change affects a page or if you need to alter the configuration later?
Also consider ownership. Someone in the organisation should be accountable for the content and purpose of each web part. Technology can make a directory easier to present, but the source data still needs to be accurate. A news component can improve visibility, but someone must publish useful news consistently.
This is where an app and a wider SharePoint support arrangement can work well together. Apps provide the visible improvement quickly. Ongoing senior input can deal with the less glamorous work: governance, information architecture, permissions, page standards and the backlog of small improvements that otherwise never gets prioritised.
A practical SharePoint marketplace app buying checklist
Before buying, make sure you can answer these questions clearly:
- What specific user or business problem will this app solve?
- Can standard SharePoint meet the need without adding another component?
- Does the app run natively within Microsoft 365, and what permissions does it require?
- Will it fit your branding, work on mobile and remain accessible?
- Can the people who own the content manage it themselves?
- Has it been tested in your tenant with a real use case?
- What is the full annual cost, including licences, configuration and support?
- What would an equivalent custom build cost and how long would it take?
If the answers are solid, marketplace apps can be one of the quickest ways to make an underused SharePoint intranet feel purposeful. Start with the feature that removes the most everyday friction, prove its value with real users, then build from there.