“Our customers and vendors keep calling and emailing to ask where things stand.” A portal fixes that only if it answers those questions with the same information your office sees. So build vs buy for a customer portal is mostly a decision about data, roles and workflow, not feature lists.
The short answer: buy portal software for standard self-service, build what’s specific to you
Buy the commodity, build the differentiator. Logging a ticket, searching help articles, downloading an invoice and resetting a password work roughly the same everywhere, and products already do them well. How an order moves through your shop, which vendor documents your team must approve, and what a customer’s site manager may see compared with their accounts payable clerk are specific to you. That’s where custom work earns its cost.
To see which side you’re on, pull a week of the calls and emails your team answers and sort them by the question behind each one.
Questions in the top rows point to products. Questions in the bottom rows mean the portal’s value depends on your own systems. The same test works for build vs buy on a vendor portal: swap “Where’s my order?” for “Did you get my invoice?”
What off-the-shelf customer portal software does well
“Customer portal software” covers the portal module in a help desk or CRM, standalone client-portal products, no-code portal builders and the portal bundled with some ERP, accounting and field-service systems. At their best, they give you:
- A fast start. Accounts, branding and standard pages are configured, not developed.
- Sign-in handled for you. Logins, password resets and invitations are maintained by the vendor, often with multi-factor sign-in.
- Hosting, security patches and updates on the vendor’s side, paid for through the subscription.
- Mature ticketing, help articles and file sharing, because the vendor builds them once for every customer.
- A roadmap you don’t fund alone. New features arrive without a project.
We see this from the vendor side too: we design, engineer and still run our own product, Just A Menu, used by restaurants across the U.S. Publishing one menu to QR codes, TV menu boards and a website is the same job for many restaurants, so a product solves it well. If your portal’s job is that common, buy.
Test portal software on your hardest real case
Demos follow the vendor’s happy path. Before you sign, ask to see these done live with your own sample data:
- One customer company with three users who should see different things: a buyer, an accounts payable clerk and a site manager.
- Order or job status coming from your system, not typed into the portal by your staff.
- Your most awkward real request: the partial shipment, the rush order, the document that needs a second approval.
- The same tasks on a phone, done by someone who isn’t at a desk.
- A full export of users, documents and history.
A workaround on a rare case is normal. A workaround on the question people call about every day means the product isn’t solving your problem. If the gap is a simple internal form, a low-code tool may be enough; see low-code vs custom software.
Signs you’ve outgrown your customer portal software
One sign on its own is often a configuration or training problem. Several, on questions customers and vendors ask every day, is a pattern.
1. Roles: everyone at a customer company sees the same thing
A whole customer company shares one login, or big accounts get separate portals, or staff export a report per customer and email it because the portal can’t filter it safely. Each is a permissions problem. Broken access control, where users can act outside their intended permissions, is #1 in the OWASP Top 10:2025 list of web application security risks. When outsiders use the portal, roles are part of the design, not a setting you add later.
2. Your own data: the portal shows a copy, and the copy is wrong
The portal keeps its own version of your orders or vendor records, refreshed by a nightly upload or by someone retyping. Then it says “shipped” while your ERP says “backordered,” and customers call to ask which is right. A portal that can’t read from, and sometimes write back to, the system of record creates calls instead of preventing them. See how to eliminate double data entry.
3. Workflows: the real process happens in email after the form
“We need software that follows our specific process.” The portal accepts the request, then the real work happens in email: a credit check before an order is released, a quote that needs a manager’s sign-off, a vendor document someone has to review. The customer can’t see those steps, so they still call.
4. Phones: your outside users aren’t at desks
“Our contractors need to do this from their phones.” Drivers, technicians and small suppliers check status and upload documents between jobs. If the portal is a shrunken desktop page, updates come back by text and someone in the office types them in. Our guide to contractor portal features covers what a phone-first portal needs, and the free mobile-friendly test checks pages, including ones behind a login.
5. Pricing: per-user fees don’t match how outsiders use it
A plan that charges per user, per contact or by tier works for a few dozen staff. It works less well for hundreds of customer contacts or vendors who log in a few times a month to check one thing.
6. The calls didn’t stop
The clearest sign. Count status calls and emails before and after launch. If the count hasn’t moved, the portal isn’t answering the question people actually have.
Count your signs
One sign: fix the configuration, the training or one integration. Two or more on a daily question: price the middle path below. Most of them, on a portal that has to follow your own process: get a custom build quote before the platform renews.
The middle path: a portal platform plus custom integration
Outgrowing portal software doesn’t always mean replacing it. If the platform still handles sign-in, tickets and documents well, keep it and build only what it can’t do.
Platform plus integration
The platform stays the front door. A small integration service reads order, invoice or job status from your ERP, SQL Server database or job system through their APIs and keeps the portal current, logging every sync and alerting a person when one fails. See API and database integration.
Platform plus one custom workflow
Build the one process the platform can’t follow, such as a proof approval or a change-order sign-off, as a focused web app linked from the portal that writes results back to your systems. Plan sign-in early so outside users don’t juggle two accounts.
Example (hypothetical): a commercial printer keeps its help desk portal
Customers use the printer’s help desk portal for questions and file uploads, and it works. But proof approvals happen by email, and “Is my job on press yet?” is a phone call, because job status lives in the production system. The middle path keeps the help desk portal and adds a proof-approval page and a job-status view, linked from it, that read from and write to the production system. Not client data.
What makes the middle path hold up
- Decide which system owns each piece of data before anything is connected.
- Confirm the platform has a documented API, and that API access is in the plan you’ll actually pay for.
- Log every sync, retry failures and alert a named person when one doesn’t go through.
- Agree who updates the integration when the vendor changes its API.
Not sure which side of the line your portal is on?
Tell us what customers and vendors keep asking and which systems hold the answers. Your first call is with an engineer, who will tell you plainly if a platform is the better fit.
What drives customer portal cost on each side (in your own numbers)
There are no prices here on purpose: subscription prices and build quotes depend on things only you know. These are the customer portal cost factors to price with your own quotes:
Per-user pricing grows with every customer you add. For each year, multiply the users you expect by the price per user per month and by 12, then add platform fees, add-ons and workaround time. Do it for five years with your real growth, not today’s user count.
Example (hypothetical): seats that grow with your customer list
A distributor’s portal starts with 150 customer contacts and adds 150 a year, so year 5 has 750. If the plan bills per contact, year 5 costs five times year 1 before any price increase. That line is what you compare with a build quote plus yearly hosting and maintenance. Not client data.
Our build vs buy software calculator compares both paths month by month over one to ten years, including the subscription you keep paying while a custom portal is built. It shows each path’s total, the break-even month if there is one, and the user count at which building pays off. Nothing you type is sent anywhere unless you choose to send it to us. For the build side, how much custom software costs explains what drives a build quote.
Who maintains the portal for the next five years
Customers and vendors depend on a portal every day, so decide now who looks after it, whichever path you choose.
If you buy, the vendor hosts, patches and updates the product. You still own the configuration, user administration, any integrations and the content, and you absorb the vendor’s decisions: price changes, features moved to a higher tier, an API that changes.
If you build, someone has to host, back up, monitor and update it, and change it as your process changes. That’s a permanent line item; the web application maintenance checklist lists what it covers.
Questions to settle with any provider
- Who gets the alert when a sync fails overnight, and who fixes it?
- Who can add a new role or user type, and what does that involve?
- Where are backups kept, and when was a restore last tested?
- Who holds admin access to the hosting, domain, code repository and data?
How we look after portals
On any project, you talk directly to the engineers doing the work, and the crew that builds a system also maintains it; see software maintenance and support.
With a portal that already exists, looking after it can mean steady improvement rather than a big launch. Amusement Advantage, an attractions guest-experience company with a network of 60,000+ contractors, is one example: we’re modernizing its existing contractor portal page by page so contractors can register, find and apply for assignments, check status, update their information and upload photos from their phones. Each page is tested on a staging copy before production, and we provide ongoing maintenance. Mobile-responsive pages now cover about 90% of the contractor workflow, with 20–30% fewer support requests for login assistance, opportunity search/updates and assignment/project status.
Decision table: customer portal software, middle path or custom build
If your rows point in different directions, price the middle path first, because it keeps what already works. Either way, write down the questions customers and vendors ask, the systems that hold the answers and who will own the portal; the free software RFP template turns that into a brief for any vendor or development team. If you’re leaning toward a build, customer and vendor portal development explains how we approach it, and our guides cover related decisions.
