Choosing an intranet portal development company comes down to four things: proven platform expertise, evidence of a real discovery process rather than a template pitch, clarity on what is genuinely customised versus configured, and a support model that continues after go-live. Getting these four right matters more than comparing feature lists, since most vendors can demonstrate similar features in a sales demo.
Start with the platform, not the vendor
Before evaluating companies, decide whether SharePoint, Drupal or another platform fits your organisation's existing technology stack, since this choice affects which vendors are even worth shortlisting. A vendor with deep SharePoint expertise may not be the right fit if your organisation runs on a different ecosystem, and a generalist agency that "does intranets" alongside a dozen other services rarely has the platform-specific depth that shows up in the details of a finished build. If your organisation is already a heavy Microsoft 365 user, that alone narrows the shortlist considerably and should shape the questions you ask each vendor.
Ask for evidence of the discovery process
A company that starts talking about design and features before understanding your organisation's structure, departments and existing pain points is building a generic template, not a solution for your business. Ask prospective vendors what their discovery phase actually looks like: do they interview stakeholders across departments, review your existing intranet usage data if you have one, and document specific workflows before proposing an architecture? Vendors who skip this step tend to deliver portals that look polished in a demo but do not match how your organisation actually works, and the mismatch usually only becomes obvious after launch, when it is expensive to fix.
Customisation versus configuration: understand what they are actually building
Many vendors describe their work as "custom" when what they are really doing is configuring an out-of-the-box template with your branding applied. There is nothing wrong with configuration if it is what you need and is priced accordingly, but you should know the difference before signing a contract. Ask specifically what will be custom-built for your organisation versus what comes from a standard template, and get this distinction in writing so expectations are clear on both sides. This also affects future flexibility: a heavily templated build can be harder to extend later than one built with your specific workflows in mind from the start.
Budget transparency and total cost of ownership
The headline development cost is only part of the picture. A trustworthy vendor will walk you through licensing costs, ongoing hosting or platform fees, and the realistic cost of adding features after launch, rather than letting these surface as surprises later. Ask how change requests are priced once the initial scope is delivered, since this is where many intranet budgets quietly expand well beyond the original quote.
Support, training and governance after go-live
The organisations that struggle most with their intranet are usually the ones that treated launch as the finish line. A good intranet portal development company will talk about training plans, content governance, and ongoing support before you even ask, because they know adoption depends on what happens in the months after launch, not just the quality of the initial build. Ask what post-launch support looks like, who owns fixing issues that surface once real users start working in the system, and how content governance is handled as the organisation grows.
Timeline expectations and project realism
Be wary of any vendor who quotes a firm timeline before completing discovery, since a realistic schedule depends on findings that only emerge once requirements are properly scoped. A company that gives a rough range upfront and commits to a firm date after discovery is usually being more honest than one that promises an exact go-live date in the first sales call. Ask how the vendor handles scope changes that surface mid-project, since this is one of the most common causes of delay and budget overrun in intranet builds.
How to structure the final decision
Once you have shortlisted two or three companies, request a working demo built around one of your organisation's actual use cases rather than a generic showcase, and involve the employees who will use the system daily in that evaluation, not just IT and leadership. Their reaction to how intuitive the navigation feels is often a better predictor of eventual adoption than any feature comparison on paper.
Red flags to watch for during vendor evaluation
Be cautious of vendors who cannot show you a live reference site similar to your use case, who are vague about timelines and cost breakdowns, or who push a single platform regardless of what you describe about your organisation's needs. A vendor confident in their work will happily connect you with an existing client for a reference call, and will be transparent about where a project might run into complexity rather than promising a frictionless build.
Sign in to leave a comment.