"What's the status?" "Can you resend the invoice?" "Which version is current?" Every one of those is a person who'd rather have looked it up themselves, interrupting someone who'd rather not have been interrupted. We build the portal that answers them, for your clients, your vendors, your partners, or your members.
SSO and granular access · Your branding, your cloud, your code
| What arrived in your inbox last week | Where it would have gone instead |
|---|---|
| “What's the status of our project?” | Their dashboard |
| “Can you resend last month's invoice?” | Their billing page |
| “Which version of the file is current?” | Their documents page |
| “Has our order shipped?” | Their order page |
| “Can you add my colleague to updates?” | Their team settings |
| “When's our next renewal?” | Their account page |
| “Did you get the form we sent?” | Their submissions page |
| “Can we get a copy of the report?” | Their downloads page |
None of these needed a person. All of them got one.
Trusted by teams in the US, UK, and India
Siddhraj
Unoloft
Kofeko
3nStar
Veda
Cerata
Shubham
Consultup IndiaSiddhrajUnoloftKofeko3nStarVedaCerataShubhamConsultup IndiaAn account manager loses an hour a day to questions that have answers. Not hard questions, status, invoices, files, dates. Things that exist, written down, somewhere the person asking can't reach.
The obvious cost is the hour. The real cost sits underneath it. Every answer is a small act of retrieval and retyping, and each one is a chance to send the wrong version, quote a stale date, or forward something that shouldn't have left the building. The client who asks twice a week gets good service. The one who doesn't ask assumes the worst and doesn't mention it until renewal.
And it caps you. Twenty clients at two interruptions a week is manageable. Two hundred isn't, not without hiring proportionally, which is the definition of a business that can't scale. The email inbox is a support channel you never chose, with no queue, no history the client can see, and no way to tell whether the same question is being asked forty times.
A portal isn't a nicer way to communicate. It's the difference between service that scales with headcount and service that doesn't.
Same engineering. What changes completely is who's on the other side and what they're allowed to see.
Where each project, order, or case stands, updated from your CRM or project tool automatically rather than by someone remembering to post an update.
Versioned, current, with a clear “this is the latest” rather than an email thread with four attachments.
Issue history, what's outstanding, and the ability to pay, pulled from your accounting system. Pairs with document and invoice processing on the intake side.
A structured way to ask for something or sign off on it, with a history both sides can see.
Best for: agencies, professional-services firms, and anyone whose account managers have become a helpdesk by accident.
Most portals need automation underneath, a status that updates itself, a document that files itself, a reminder that sends itself. That's workflow automation, it's cheaper as its own scope, and we'll price it separately so you can see what you're paying for.
Four status emails before 10am. Someone opens the project tool and retypes what's in it.
A client asks for an invoice copy. Someone finds it in the accounting system and forwards it.
A vendor calls about payment timing. Accounts payable checks and calls back.
A document goes out. It's the wrong version. Nobody realises for a week.
Someone builds the monthly client report by hand from three systems.
A client says they didn't feel looked after. Nobody can point to what was delivered.
Those four clients checked their own dashboards over the weekend.
The invoice was already on their billing page, with the payment link.
The vendor checked payment status themselves at 6am their time.
There's one current version and it's the one on the page.
The report is live and always has been. The call is about the commentary.
Every deliverable, date, and approval is visible with a timestamp.
The measurable outcome isn't hours saved, it's inbound requests that never arrive. We baseline that in week one, which is what makes the improvement provable rather than asserted.
A portal nobody logs into is worse than no portal, because now you have both the emails and the maintenance.
Not one login per company. Real organisations, real teams, real roles, a client's finance person sees invoices, their project lead sees deliverables, and neither sees another client's anything. Row-level isolation enforced at the data layer, not by remembering to filter a query.
SSO where your users have it, magic links where they don't, and SAML for the ones whose IT department requires it. Every password reset is a person who nearly emailed you instead.
A portal that needs your team to post updates has moved the work rather than removed it. Status, documents, and invoices flow in from your CRM, project tool, and accounting system on their own.
Your users didn't ask for this and won't attend a session about it. If the first screen doesn't make the next action obvious, they'll email, and after two of those, they won't come back.
Nobody remembers to check a portal. Something changed, here's a link, one click to the exact page. The notification is as much the product as the portal is.
It sits in front of your clients, so it should look like you, your domain, your identity, your language. A portal that looks like generic vendor software undercuts the impression it was bought to improve.
If your users want to ask questions of what's in the portal rather than navigate to it, that's a RAG chatbot over the same data, and it's often a smaller build than the extra screens people request.
Who logs in, what each role sees, and, the part that matters most, what they must never see. We map organisations, teams, and roles, and we baseline the inbound requests your team currently fields so the outcome is measurable. You get the access model in writing whether or not you hire us.
Written scope, fixed price, and a delivery date before any code is written, phased so you can see what launches first. If scope moves, we re-quote in writing first.
Built against your real data, then piloted with a handful of actual clients or vendors, not internal staff pretending. Written update every Friday plus a short Loom walkthrough. Pilot feedback is where portals are saved, because the confusions that kill adoption are never the ones your own team predicts.
Launched to one group at a time with the old channel still open, so nobody is stranded. Then: monitoring, tracking which pages actually get used, and cutting the ones that don't. Portals accumulate unused screens faster than any other kind of software, and pruning is part of the monthly plan.
Portal products are good and getting better. Buying beats building more often than an agency page will say.
Your needs are close to standard, documents, messages, invoices, basic status, and you're happy for it to look mostly like the vendor's product. Client counts are modest enough that per-seat or per-client pricing works. SuiteDash, Copilot, Zendesk, HubSpot's portal, or SharePoint will be live in weeks for a fraction of a custom build. We'll tell you this on the call and we won't quote you for something you don't need.
Your access model doesn't fit the product's, nested organisations, unusual roles, or data that must be isolated in ways the tool can't express. Or the portal needs to pull live from systems no product connects to. Or per-client pricing has stopped making sense at your volume. Or it's client-facing enough that vendor branding is a problem. Or you need a workflow, approvals, submissions, registrations, the product can't run. Or you're in a regulated space and need audit trails and data residency you control.
| Off-the-shelf portal | Custom build | |
|---|---|---|
| Time to live | Weeks | Longer, scoped after the access-mapping phase |
| Upfront cost | Low | Higher, fixed and quoted in writing |
| Ongoing cost | Per-seat or per-client, grows with you | Hosting plus a monthly plan |
| Standard documents and messaging | Excellent | Overkill |
| Complex or nested access models | Product's model | Modelled to reality |
| Live data from your own systems | What the product connects to | Anything with an API |
| Branding | Vendor's, with your logo | Entirely yours |
| Custom workflows | Limited | Whatever your process is |
| Audit trail and data residency | Vendor-dependent | Yours to control |
| Ownership | You rent it | Code and data are yours |
Honest answer: the clearest signal to build is not dissatisfaction with a product's features. It's when the access model doesn't fit, when you find yourself creating duplicate accounts, or manually restricting things the tool can't restrict. Features can be lived without. A wrong permission model is a client incident waiting to happen.
A portal is only as useful as what's behind it. It shouldn't need anyone to post updates into it.
Not listed? If it has an API, we can almost certainly read from it. Where a system genuinely can't be reached live, we'll say so before you commit and propose a scheduled sync rather than promising real-time data that isn't available.
People outside your organisation self-serve, clients, vendors, partners, or members.
Your own team does the work. If everyone logging in is on your payroll, start there.
Customers pay subscriptions and the software is your product, not a service wrapper around it.
Read-only visibility. If nobody needs to do anything, a dashboard is smaller and faster.
Something happens without anyone opening anything. If the goal is a status email that sends itself, you may not need a portal at all.
The engineering underneath all of these.
Honest answer: a good share of portal enquiries are solved by automated status notifications and a shared folder. That's weeks, not months, and it's a real answer, a portal only earns its cost when people need to look things up on their own schedule, not when they need to be told things on yours.
Fixed price, quoted in writing before we start. No hourly billing, no surprise change orders.
One audience, clients, vendors, or partners, with access modelling, the core screens, identity, notifications, and integration to your primary system. Includes the first month of monitoring.
Scoped and quoted after access mapping
Good for: the audience generating the most inbound requests. This is most enquiries.
Several audiences sharing one identity and permission model, so the second and third cost a fraction of the first.
Priced once we know how many audiences
Good for: businesses fielding requests from clients and vendors both.
Monitoring, usage review and screen pruning, new sections as needs change, and a set amount of feature work each month.
A monthly plan sized to your portal
Good for: portals that have become the main client channel, most clients end up here.
Every build includes monitoring for the first month. After that it's a monthly fee, see what that covers, and you can stop any time, you keep the source code, the data, and the documentation either way.
Access modelling, mostly. Your internal systems assume everyone using them works for you. A portal assumes the opposite, that a user should see exactly their own data and nothing else, enforced at the data layer rather than by a setting someone might get wrong. That difference is the whole project, and it's why “just give them a login” tends to end badly.
Only if it's populated automatically, obvious without training, and paired with notifications that link straight to the relevant page. Portals that require your team to post updates fail, because the work moved rather than disappeared. We pilot with real users before rollout, the confusions that kill adoption are never the ones your own team predicts.
Yes, and it's usually a requirement. Real organisations, teams, and roles, their finance contact sees invoices, their project lead sees deliverables, and access is enforced at the data layer rather than by hiding buttons.
Yes, Google Workspace, Microsoft Entra ID, Okta, SAML and OIDC for enterprise users, and magic links for people whose organisations don't have SSO. Every password reset is someone who nearly emailed your team instead, so login friction gets more attention here than it usually gets.
That's the point. Status from your CRM or project tool, invoices from your accounting system, documents from wherever they live. Where a system can't be reached live we'll say so upfront and propose a scheduled sync rather than promising real-time data that isn't available.
Yes, uploads, structured forms, approvals, and requests, with a history both sides can see. That two-way history is often what actually reduces email, more than the read-only screens do.
Entirely. Your domain, your identity, your language. A portal sitting in front of your clients that looks like generic vendor software undercuts the impression it was bought to create.
You'll have a working pilot with real users well before full rollout, and a single-audience portal is quoted in writing once we've mapped the access model. Multi-audience builds run longer and go live one group at a time. The main variable is how many systems it reads from, not how many screens it has.
Row-level isolation enforced at the data layer, audit logging on access and changes, SSO and SAML, encryption in transit and at rest, and regional hosting where EU or UK data residency is required. For a portal specifically, the isolation model is the thing to get right, a leak here is a client incident, not an internal inconvenience.
Often you should, and we'll say so. They're good products and much cheaper for standard document-and-message portals. Build custom when your access model doesn't fit theirs, when you need live data from systems they don't connect to, when per-client pricing stops making sense, or when vendor branding in front of your clients is a problem.
You do. Source code, database, integration configuration, and documentation transfer to you on final payment, whether or not you keep us on a monthly plan. It runs in your accounts.
We're in Ahmedabad, India, with 2–3 hours of daily overlap with US Eastern and UK working hours and a same-business-day response commitment on anything urgent. A written update every Friday plus a short Loom walkthrough.
Book a 30-minute call. We'll work out how many of your inbound requests a portal would actually absorb, tell you honestly whether an off-the-shelf product would do it, and give you a fixed price if building is the right answer.
