Build Versus Buy a Client Portal: The Honest Arithmetic
A competent engineer can build a working client portal in three weeks. The reason firms regret it has nothing to do with those three weeks.
The build-versus-buy conversation about client portals is unusually prone to a specific error, because the first version genuinely is easy. Authentication, a file list, an upload control and a permissions check is a fortnight of work for somebody who knows what they are doing, and it will demonstrate beautifully. The estimate is not wrong. It is just an estimate of the wrong thing.
What follows is the arithmetic of the parts that do not appear in the first estimate, and then the cases where building really is the right decision, because there are several and they are not rare.
What the first version leaves out
These are not features somebody forgot. Each one is invisible until a specific event forces it into existence, and the events are all certain to happen.
- Invitation and revocation flows, including the contact who leaves their company mid-engagement and the one who forwards their invitation to a colleague.
- An audit trail of who viewed what, which nobody asks for until a dispute, at which point it cannot be created retrospectively.
- Email deliverability. Notifications from a new domain land in spam, and fixing that is a specialist exercise in domain authentication and reputation.
- Mobile. Client contacts read on phones, and a responsive layout that was never tested on a real device is not mobile support.
- Accessibility, which is a legal requirement in many jurisdictions for a system a client is required to use.
- Data residency, retention and deletion, which arrive with the first client whose contract specifies them.
- The security review your first enterprise client will run on you, and the remediation it will produce.
The cost that is genuinely hidden
The largest cost of a built portal is not construction and not maintenance. It is that the portal becomes a permanent claim on the attention of the people who understand it, and those are usually the same people the firm most wants building whatever it actually sells.
A bought portal that breaks produces a support ticket. A built portal that breaks produces an interruption to your best engineer, at a time chosen by a client rather than by you. Over three years that interruption cost is usually larger than the licence fee it was avoiding, and it is paid in the currency the firm has least of.
The second hidden cost is bus factor. A portal built by one person becomes a system nobody else fully understands, and it stays that way until that person leaves, at which point the firm owns a client-facing production system with no maintainer and no vendor to call.
When building is genuinely the right call
The argument above is not that building is always wrong. There are four situations where it is clearly correct.
- The portal is the product. If clients are paying for the portal experience itself, it is not infrastructure and it should not be outsourced.
- The workflow is genuinely unlike anybody else's, in a way you can describe specifically rather than as a feeling that your firm is unusual.
- Regulatory constraints make every available product non-viable, and this has been confirmed by somebody who reviewed the products rather than assumed.
- You already run a mature engineering organisation with an on-call rotation, a security review process and a design system, so the portal is a small addition to an existing capability rather than a new one.
The middle path most firms should consider
The choice is not binary, and the framing as binary is what produces bad decisions. Buy the parts that are commodity and hard, and build the part that is specific to you.
Authentication, permissions, file storage, audit logging and notification delivery are commodity problems that have been solved better than you will solve them, and getting them slightly wrong is a security incident. The specific view your clients need of your specific work is not a commodity, and it is usually a small amount of code on top of a platform that exposes the underlying record.
The practical test is which side of that line the thing you want to build falls on. If your engineer's first sprint is authentication and file upload, you are rebuilding a commodity. If it is a view of your delivery data that no vendor could have anticipated, you are building the right thing.
If you build anyway, build these on day one
For firms that have made the decision, three things are dramatically cheaper to build at the start than to retrofit, and all three are commonly deferred.
An audit log of every read as well as every write, because a log that only records changes cannot answer the question a dispute asks. A permission model with an explicit scope object rather than a boolean on each record, because every portal eventually needs to share part of an engagement rather than all of it. And a way to see the portal exactly as a specific client contact sees it, because without it nobody on your team can verify a permission boundary, and unverified permission boundaries are how client data reaches the wrong client.