Build or Buy a Client Portal? A Decision Guide for Service Teams
Compare complete client workflows instead of feature lists. Assess purchased software and custom development against access, integration, ownership and the work your team needs to finish.
Words byEskeil Editorial11 minute read
A client asks where the latest file is. A colleague sends the wrong version. Someone else updates a spreadsheet that the client cannot see. By the end of the week, the team is discussing a portal. The question quickly becomes which software to buy or which features to build, even though the process itself is still disputed.
Choose between a purchased client portal and custom development by comparing the real workflow, access rules, integrations, ownership and operating responsibilities. Start with a small set of complete scenarios. A portal that demonstrates an attractive dashboard but cannot support those scenarios is not yet a convincing solution.
This guide is for operations leads, agency owners and service teams coordinating recurring work with customers. It provides a way to compare options fairly and prepare a brief for a supplier. All workflow examples are illustrative, with no implied Eskeil client results or universal cost claims.
Identify the handoff that needs to improve
Describe one recurring task from beginning to end. For example, a client submits a brief, staff request clarification, an authorised reviewer approves the work and the client receives a final deliverable. Identify where information changes hands, which record is authoritative and who may change it.
Ask the team to show how the task happens today using invented data. You may find that the main problem is an unclear approval rule rather than a missing interface. Putting the same uncertainty into a portal can make it harder to resolve because a software status appears more final than an informal email.
Write a sentence describing the desired improvement: the client and team should find the current approved deliverable and understand what happens next. That sentence provides a useful test for proposed features. A complicated reporting panel might be valuable later, but it does not automatically help with this first problem.
Compare complete scenarios, not feature labels
Document the situations an option must support. Include ordinary work and inconvenient exceptions. A feature called document management can mean anything from a shared attachment list to versioned records with permissions and approval history. You need to see the behaviour your process requires.
A client submits an allowed file and can later identify its status.
A reviewer requests a correction without losing the previous decision history.
A staff member leaves and their access is removed appropriately.
A client cannot retrieve another client's records through a direct request.
An integration fails and the task remains visible for recovery.
The team exports the agreed records in a usable form.
These scenarios also improve a custom brief. Our web application MVP guide explains how to keep a first workflow coherent. A smaller scope should reduce optional breadth while retaining the access and recovery behaviour needed for real use.
Give each page a clear job in the buying decision. Build a connected professional content library with useful answers, consistent business facts and a practical publishing process.
When form submissions rise but sales conversations do not, measure the gap. A practical framework for qualification, attribution, outcome delays and better campaign decisions.
Understand when a purchased platform fits
A purchased platform may be appropriate when its existing workflow closely matches yours, its permissions meet the requirement and your team can maintain the configuration. It can offer established features without commissioning every interface. The fit still needs to be demonstrated rather than inferred from a product category.
Ask for a walkthrough using your scenarios and sample records. Note where the product works directly, where configuration is required and where a workaround changes the process. Include licensing assumptions, storage limits, account arrangements and support availability in the comparison. Confirm current terms with the provider rather than relying on a remembered plan name.
Be particularly careful with workarounds around client separation or approvals. A manual naming convention is not equivalent to an enforced access boundary. If users must remember several informal rules to avoid exposing a document, record that as a material limitation.
Understand when custom development is justified
Custom development can fit a workflow with specific business rules, distinctive interactions or integrations that available products cannot support acceptably. The case is strongest when you can name those requirements and explain the cost of the current alternatives.
It also creates responsibility for design, implementation, testing, release and ongoing care. A custom portal needs more than a login screen and a table. Accounts, permissions, data changes, error handling, backups and support arrangements must match the intended use.
Eskeil's custom web application service considers users, workflow and business rules before implementation. UI/UX design can make the important states reviewable before development. Neither step requires pretending that every request belongs in the first release.
Make the access model explicit
List who can view, create, edit, approve, export and archive each important record. Do not assume an administrator should automatically perform every commercial action. Some workflows need a distinction between managing access and approving work. Decide how organisation membership and shared projects affect access.
The server must enforce relevant permissions even when the interface hides a button. Test direct requests, changed record identifiers and downloads. Include what happens after access is revoked. A file link that continues to reveal private material can undermine otherwise careful screen-level controls.
The OWASP Authorization Cheat Sheet is a useful reference for an implementation discussion. For purchasing, ask the provider to demonstrate the relevant behaviour and explain the available evidence. A claim that a platform is secure does not answer your specific access questions.
Decide which record is authoritative
A portal may connect to a CRM, file store or project system. Choose which system owns each important fact. If a project status appears in two places, define where a change begins and how it is reconciled. Otherwise, staff may continue checking email because they cannot trust the displayed status.
Consider a deliverable that has several versions. Distinguish a working draft, a submitted version and an approved final version. Decide how corrections are recorded and whether a previous approval remains visible. A timestamp alone may not explain why a change occurred or who authorised it.
Keep the data model proportionate. Collect what the workflow requires and agree retention and removal responsibilities. Avoid importing every historical file merely because storage is available. A carefully selected migration can be easier to validate and more useful for the first release.
Review integration failures before signing off
An integration may successfully create a record in a demonstration and still behave poorly under retries, delays or expired permissions. Define the expected failure states and who will investigate them. The portal should accurately distinguish pending work from completed work.
Ask what happens if a file is stored but the notification fails. Does retrying send the same message twice? If the CRM is unavailable, can staff still find the client request? If a provider changes its API, who owns the repair and what agreement covers it?
Use the same scenarios when evaluating purchased and custom options. This makes the comparison fairer than asking detailed technical questions of the development team while accepting a provider's integration logo as sufficient evidence.
Compare ownership and exit conditions
Before committing, request an export demonstration. Can the team retrieve the records, files, relationships and history it actually needs? An export containing only display names and a flat status column may be insufficient for a later migration. Identify which information requires a separate process.
Clarify who owns the hosting, domain, source code where relevant and operational accounts. Record license and support responsibilities. For a purchased service, review available export and cancellation terms with the provider. For custom development, agree repository access, deployment documentation and handover obligations.
The GOV.UK Technology Code of Practice provides a broader public-sector reference for considering user needs, reuse, interoperability and technology lifecycle. It is not a certification for your portal. Use the underlying questions to make your own ownership and maintenance discussion more concrete.
Model the operating cost over a shared period
Compare options over the same planning period using transparent assumptions. Include implementation, licenses, hosting, support, integrations, staff administration, training and expected change work. State which costs are known and which remain estimates. Avoid presenting a precise total when important variables are unresolved.
Also identify the workload transferred to your team. A lower license fee may come with more manual configuration or reconciliation. A custom build may require a maintenance arrangement that has not yet been priced. These are responsibilities to account for, not automatic arguments for either option.
Test a realistic change request in the comparison: a new approval stage, a new staff role or an additional document type. Ask how the change would be specified, implemented and checked. The answer reveals more about long-term fit than a list of features already available on day one.
Use a first release to establish a dependable habit
Choose one client group or workflow for the initial rollout where appropriate. Provide guidance about what belongs in the portal and which channel remains authoritative during transition. Avoid leaving clients uncertain whether approval must happen in email or in the application.
Prepare a migration rehearsal, a validation method and a recovery plan. Check that the right users can access the right records after migration. Include the procedure for stopping the rollout if a serious issue appears. Operational readiness is part of the product, even when the interface is deliberately small.
Confirm workflow and access rules with the people responsible.
Demonstrate the core scenarios using realistic sample data.
Verify integrations, exports and recovery arrangements.
Train the initial users and define the source of truth.
Review completion, errors and remaining manual handoffs before expanding.
Measure whether the portal improves the task
Track measures related to the original issue: finding the current deliverable, completing an approval, avoiding duplicate entry or reducing unresolved handoffs. Establish a baseline with a consistent definition. Logins alone may indicate use without showing whether the work is easier.
Combine observations with staff and client feedback. Where do people still leave the portal? Which instructions remain unclear? Does the team trust the displayed status? Record the answers as findings and investigate before describing them as proven efficiency gains.
If a proposed next step is automated summarisation or an assistant, read the grounded AI evaluation guide. Adding AI to an unclear source-of-truth problem can introduce a more fluent description of the same confusion.
Questions to resolve in a portal decision
Is a custom portal always more flexible?
It can be changed through development, but useful flexibility depends on architecture, documentation and available maintenance capacity. A purchased platform may handle expected changes comfortably. Compare the actual change scenarios instead of treating custom as a universal advantage.
Can we combine purchased tools with a small custom component?
Potentially. Review whether the connection has supported interfaces, appropriate permissions and clear responsibility for failures. A hybrid approach needs an understandable boundary; otherwise, the team may inherit several systems without knowing which one owns the task.
What should a first development conversation include?
Bring the current workflow, user roles, systems involved, important exceptions and the outcome you want to review. Use invented sample records. Eskeil can help turn that material into a focused plan without requiring a finished technical specification in advance.
Make the comparison reviewable
Put the core scenarios, access requirements, integration assumptions and ownership questions into one decision document. Ask each option to answer the same questions. A useful decision identifies both its reasons and the unresolved conditions that could change it.
