Should you build a customer portal or buy an off the shelf one?

Most businesses arrive at this question the same way. Someone works out how much of the week goes on taking bookings, chasing missing details on forms, and answering "where is my order?", and decides customers should be able to do some of that themselves. Then the choice appears: buy a portal product, or have one built.

The honest answer is that a good portion of businesses should buy. Portals are not exotic, and there are decent products covering the common shapes. But the build-or-buy decision for a portal has one wrinkle that the general bespoke versus off the shelf question does not, and it is the thing that trips people up: a customer portal is not really a piece of software you use. It is a piece of software your customers use, and you only find out whether they will after you have paid.

What "off the shelf" means here

The packaged options fall into three groups, and they are not comparable.

A portal bolted onto something you already run. Your practice management system, job management software or accounts package probably has a customer login of some sort included or available as a module. This is nearly always the first thing to look at, because the data is already there and the integration problem is somebody else's.

A dedicated portal product. A standalone product built to be a client portal, usually charged per user or per month, that you configure and connect to whatever you already run.

A form or booking tool. Not a portal at all, strictly, but for a lot of businesses the actual need is "let people submit this properly and see what happened next", and a well-chosen booking or form product covers it for a fraction of anything else.

Work through those in order. A surprising number of portal projects end at the first one, when someone finally reads the documentation for a system the business already pays for.

The three questions that decide it

1. Is the process itself standard?

Booking an appointment, submitting a support request, downloading an invoice, approving a quote. If what your customers need to do is one of the common shapes, a product very likely does it, and does it with a decade of other people's edge cases already handled.

The moment the process has a genuine twist in it, the calculation changes. Not "we do it slightly differently", which every business believes about itself, but a real structural difference: a multi-stage application where later steps depend on what was answered earlier, a pricing calculation particular to your trade, a referral that has to route to different people on different rules. That is the kind of thing that gets a "no, but you could do it this way instead" from a product vendor, and that answer becomes your process for the next five years.

2. What happens to the data afterwards?

This is where portals go wrong. A portal that captures information beautifully and then emails it to your office for someone to re-key has moved the work rather than removed it. You have added a system and kept the labour.

So ask, before anything else: can this product write into the system where the information actually needs to live? If it can, through a real integration rather than a CSV export somebody runs on Fridays, a packaged portal is a strong buy. If it cannot, and you end up building the connection anyway, you have taken on the harder half of a bespoke build without getting the flexibility that comes with it. Our system integration page covers what joining those systems involves.

3. Who are your customers, and how often do they come back?

A portal that asks someone to create an account and remember a password, for a task they perform twice a year, will not get used. That is not a software problem and no product fixes it. For infrequent interactions, a secure link sent to the customer's email usually beats an account, and several packaged products simply do not work that way.

If your customers are trade accounts, repeat clients or people with an ongoing case, accounts earn their keep, because there is a history worth logging in for.

The costs nobody puts in the comparison

The sticker prices are easy to compare and mostly misleading. Four things move the real number.

Per-user pricing against a customer base. Internal software is priced per staff member, which is a number you know. A portal is used by your customers, which may be a number that grows, and per-seat or per-contact pricing that looks trivial at fifty customers behaves very differently at two thousand. Check how the pricing scales before you check the monthly figure.

Configuration time. Packaged does not mean instant. Somebody in your business will spend weeks setting it up, and that person is usually the one who can least afford the weeks.

The integration. Covered above, and routinely the largest line in a "cheap" option.

The workarounds. The compromises you accept at purchase get paid for every week afterwards, in manual steps and in explaining to customers why the thing works the way it does.

Against that, a bespoke portal is a capital cost with a support arrangement after it. Most bespoke projects for SMEs fall between £15k and £60k, and a focused portal covering one job sits at the lower end of that. The bands and what moves a project up them are on our bespoke software cost page, so you can do the comparison before you speak to anybody. Timescales are covered in how long bespoke software takes.

When bespoke is clearly the right call

Three situations, in our experience, where buying is the more expensive mistake.

The portal is the product. If customers choosing you over a competitor is partly about the experience of dealing with you, the portal is not admin overhead, it is the shop front. Configuring somebody else's product means your differentiator looks like everyone else's.

The process has already been refused. If you have taken your requirement to two or three suppliers and been told it cannot work that way, that is worth paying attention to. It is sometimes a sign the requirement is wrong. Just as often it is a sign the requirement is real and the products are not built for it.

It has to sit properly inside what you already run. When the portal must read live stock, live availability or live case status from your existing systems, and write back into them, integration stops being a bolt-on and starts being the architecture. At that point you are commissioning a build regardless, and you may as well commission the one that fits.

A reasonable way to run the decision

Start by writing down the single task you most want customers doing themselves, in one sentence. Not the full wishlist, the one that would take the most work off your team.

Then find two or three products that claim to do it and put your real, messiest example through a trial. Not the tidy example, the one with the missing details and the awkward exception, because that is the case that costs you money now.

If a product handles it, buy it. If every product handles it only by changing how you work, price up both properly and decide with the numbers in front of you. Getting to that point costs you a fortnight and no capital, and it is the cheapest fortnight in the project either way.

If you would like a second opinion on which side you are on, our customer portals page sets out how we approach these builds, and the free process audit is a 60 minute session where we map what actually happens today. You will get a straight answer, including "buy the product" where that is the right one. Get in touch if that would help.