Custom portal development is worth paying for when your access rules, data residency or audit requirements cannot be expressed in someone else’s admin panel. Below that line, a portal product or a no-code builder will do the job for a published monthly fee and you should use one. This guide gives the three routes, the prices each vendor publishes today, the five requirements that force a custom build, and where the schedule actually goes once you commit.
The three routes, and what each one costs today
Portal projects divide into three routes. Prices below were read from each vendor’s own pricing page on 12 September 2026, and every one of them is a recurring fee rather than a one-off.
- A portal product. A hosted client portal you configure: users, folders, tasks, chat, branding. Clinked is the clearest example, and it publishes its price.
- A no-code builder on top of your data. You point a builder at a database or spreadsheet and it renders a permissioned front end. Softr and similar tools sit here.
- A custom build. Your own application, your own schema, your own auth. No per-seat licence, and no ceiling on what the rules can express.
| Route | Vendor and plan | Published price | What you get |
|---|---|---|---|
| Portal product | Clinked, Start Up | $8.80 per user per month | 200 GB storage, standard features |
| Portal product | Clinked, Standard | $239 per month | 100 members, 1 TB, own domain, audit trail |
| Portal product | Clinked, Premium | $479 per month | 250 members, 3 TB, role-based permissions, enforced 2FA |
| Portal product | Clinked, Enterprise | Contact sales | 1000+ members, SSO, choice of data centre region |
| No-code builder | Softr, Basic | $19 per month | Custom domain, conditional form logic |
| No-code builder | Softr, Pro | $99 per month | Branding removed, granular permissions, app-user sign-in |
| No-code builder | Softr, Business | $329 per month | 2FA, domain-restricted signup, global data restrictions |
| Custom build | Engineering time | Project priced | No licence, no seat cap, rules limited only by what you can specify |
Read the table as a floor, not a budget. A portal product at $479 a month is $5,748 a year before anyone has migrated a record into it, and that number never stops. A custom build is front-loaded instead: the cost lands once, then falls to hosting and maintenance. Which shape is cheaper depends entirely on how long the portal will live, and portals tend to live a long time.
The five requirements that force a custom build
Most portal requirements are ordinary and every product handles them: log in, see your documents, upload a file, leave a comment, get an email. The following five are where configurable products run out of road. If none of these apply to you, buy something.
Notice that four of the five are about rules rather than features. Feature lists are where portal products compete and where they are genuinely strong. Rules are where they stop, and where custom portal development earns its cost.
Where the schedule actually goes
Clients almost always budget the wrong half of a portal project. The screens are estimated carefully and the plumbing is waved through, then the plumbing takes twice as long as the screens.
In a typical portal build, the visible interface is the smaller effort. Identity, permissions, notifications, file handling and the admin side are the larger one, and none of them demo well. A dashboard looks like progress. A correctly scoped permission check looks like nothing at all, right up until the day it stops one customer seeing another customer’s invoice.
- Identity and session handling. Sign-up, invitation, password reset, session expiry, and increasingly passkeys instead of passwords. We wrote up the implementation in WebAuthn passkeys in Node.
- Authorization, enforced server side. Every endpoint, not every screen. Hiding a button is not a permission. Our production Node security guide covers the middleware pattern for this.
- The data layer and API. Schema, migrations, and an API the front end can actually use. Building a REST API with Node, Express and PostgreSQL walks through the version we start most portals from.
- File storage and access control. Uploads are easy. Making sure a signed URL cannot be forwarded to someone outside the account is not.
- Notifications. Email, and the preference centre that stops the portal becoming a spam source.
- The admin side. Every portal needs an internal view for your team to see what a user sees, fix a wrong entry and re-send an invitation. This is routinely left out of scope and always gets built in the end.
- Deployment and operations. Environments, backups, monitoring, TLS. Our deployment guide for Node on EC2 and the Docker Compose setup cover the shape we use.
Speed is possible when the scope is genuinely fixed. We have documented shipping a recall portal in under 24 hours, but the reason that works is that the requirement is known in advance and the platform already exists. A first portal with undecided requirements is a different project, and anyone quoting 24 hours for that is quoting a demo.
Client portal, customer portal, vendor portal: the differences that matter
These three get used interchangeably in briefs and they carry very different engineering. The distinction that matters is not who logs in, it is how many of them there are and who controls their identity.
| Portal type | Typical audience size | Identity controlled by | What gets hard |
|---|---|---|---|
| Client portal | Tens to hundreds | You, by invitation | Per-client data isolation and white labelling |
| Customer portal | Thousands to millions | Self-service sign-up | Sign-up abuse, support load, surge traffic |
| Vendor or supplier portal | Hundreds | Invitation, often with an org hierarchy | Multi-user organisations and delegated admin |
| Employee or intranet portal | Staff headcount | Your identity provider | SSO, joiners and leavers, directory sync |
Get this classification right before anyone estimates. A vendor portal where each supplier organisation has several users, and one of them administers the others, is a materially larger build than a client portal with one login per client, even though both screens look the same in a wireframe.
A decision test you can run in an afternoon
Rather than a build-versus-buy matrix, try this. Write down the three hardest access rules your portal must enforce, in one sentence each, in the language your business uses. Then open the trial of a portal product and try to configure exactly those three rules.
This test is better than a feature comparison because it fails fast on the thing that actually sinks portal projects. Teams rarely regret a portal for missing a feature. They regret it when the permission model was approximately right and someone saw a record they should not have.
Questions to ask a portal development company
If you take the custom route, these five questions separate teams who have shipped portals from teams who have shipped websites. We cover the wider procurement question in how to choose a custom software development company, and the architecture background in our web application development guide.
- Where is authorization enforced? The only acceptable answer is server side, on every endpoint. If the answer involves the front end, stop.
- How do I see what a specific user sees? A real portal has an impersonation or preview mode for support. Its absence means every support ticket becomes a developer task.
- What happens when a user is removed? Sessions, invitations, shared links and email notifications all have to be revoked. Most first-draft portals revoke the login and leave the file links live.
- What does the audit trail record, and who can read it? If the answer is "the database has timestamps", there is no audit trail.
- What is the surge plan? Even a client portal has a worst day. Ask what happens when ten times the expected traffic arrives in an hour.
What we build, and when we say buy instead
We build portals where the rules are the hard part: consumer-facing recall portals with eligibility lookup and remedy tracking, donation and supporter portals, and vendor portals with organisation hierarchies. Examples are on our work page, and RecallPilot is the productised version of the recall case.
We also tell people to buy. If your portal is document sharing and messaging with a few dozen clients, Clinked or a similar product at a few hundred dollars a month will serve you better than anything we could build, and we will say so on the first call. The reason to write that plainly in a guide about custom portal development is that the opposite advice is what most agency pages give, and it is wrong often enough to be worth correcting.
If you want a second opinion on which route your requirements point to, send us the three access rules from the test above. That is usually enough to answer it without a call.