Build or buy a client portal?

Evaluate journeys instead of feature counts

Write the few tasks a client must complete, including a difficult case such as multiple contacts in one company or a project shared with a partner. Ask each option to demonstrate those journeys with representative data. A long feature checklist can hide the fact that the one permission boundary or approval step you need is awkward or unavailable.

Test information boundaries

Specify which client can see which records and documents, and who can invite another person. Test that a user cannot access another client's information by following an old link or changing a record identifier. Include account recovery and deactivated users. These requirements should influence the architecture and implementation, not be postponed until after visual design.

Compare ownership over the life of the portal

List who maintains integrations, handles support, applies updates, and responds when a source system changes. Check what can be exported if you switch platforms. For custom work, clarify code, hosting, documentation, and handover responsibilities. A lower upfront price is not a complete comparison if it creates a fragile process nobody can maintain.

WORKED EXAMPLE / ILLUSTRATIVE

A fictional evaluation scorecard

A firm compares a packaged portal with a custom option using the same client journeys. It treats a failed access boundary as a requirement gap rather than letting cosmetic strengths average it away.

Before you put it to work

• Demonstrate actual client journeys.
• Test access with separate accounts.
• Check exportability.
• Assign ongoing maintenance.

Do not choose solely from a demo or a weighted total. A mandatory access or workflow requirement remains mandatory even if an option scores well elsewhere.