Start with the conservative path

Client portals are an established product category. Accounting-focused offerings already provide combinations of secure file exchange, document requests, messages, signatures, and client workspaces. For example, ShareFile's accounting material describes a central client portal and document-request functionality.

That does not prove ShareFile fits every practice. It establishes the first decision gate:

Can an established product solve the important job acceptably after reasonable configuration and process change?

If yes, buy or configure. A custom interface is not an advantage when it recreates commodity capabilities and leaves a three-person practice responsible for their failure.

Document the material gap if the answer is no. “We want it to feel like ours” is different from “the current products cannot represent the workflow that determines whether our service is complete.”

Hard stop 1: external identity has an owner

A client portal serves people outside the staff's managed company directory. It needs:

  • enrollment or invitation;
  • sign-in;
  • account recovery;
  • multi-factor or other appropriate authentication policy;
  • removal and lockout;
  • support for clients who change email addresses or cannot sign in; and
  • a record of which identity performed a material action.

The OWASP authentication guidance includes secure recovery and reauthentication considerations. “There is a login page” does not resolve them.

Google Cloud can support non-Google and other external identities through IAP and Identity Platform, as described in its external-identities documentation. That proves technical possibility, not that a particular platform or proposed application has configured, tested, and supports it.

Stop or narrow the build if nobody owns client onboarding, recovery, offboarding, and support.

Hard stop 2: client records are isolated on the trusted side

Every client must be prevented from reading or changing another client's documents and status. Hiding a row, route, or button in the browser is not that control.

No-code products make the distinction visible. Softr documents user groups, page and action permissions, conditional filters, and global data restrictions in its permissions model. Glide's client-portal guidance says Row Owners are important for preventing users from receiving rows they do not own, while visibility conditions are not a security feature. See Glide's spreadsheet-to-app guidance.

The specific products and plan requirements must be verified. The general decision gate is stable:

Stop the build until the team can test that one authenticated client cannot retrieve another client's records through the interface, API, export, or direct identifier changes.

Hard stop 3: file handling is treated as a security boundary

Document upload is not a neutral storage feature. A proposal must define:

  • allowed file types and sizes;
  • filename handling;
  • validation and scanning;
  • storage location and encryption;
  • who may upload, review, replace, download, or delete;
  • retention and deletion;
  • backup and restore;
  • audit evidence; and
  • behavior for duplicate, partial, corrupt, or password-protected files.

The OWASP File Upload Cheat Sheet describes controls including allowlisted extensions, type and signature validation, generated filenames, size limits, authorization, storage separation, and malware or sandbox checks where appropriate.

Stop or move document exchange to an established service if the custom system cannot own this boundary.

Hard stop 4: operation survives the original builder

Ask who can:

  • identify the live revision;
  • deploy a reviewed fix;
  • respond when sign-in or upload fails;
  • apply dependency and platform updates;
  • see critical workflow health;
  • disable a dangerous capability;
  • restore required state;
  • roll back code without corrupting data;
  • export data; and
  • transfer the system to another operator.

A friend, freelancer, or AI tool can create useful code. None is an operating model by itself.

Stop the build if the answer is “the person who made it” and no enforceable handoff or replacement path exists.

Hard stop 5: failure consequences fit the business

Write down what happens when the portal is unavailable for:

  • one hour;
  • one business day; and
  • four days.

Then assess incorrect behavior:

  • a client sees another client's information;
  • a submitted file is lost;
  • a reminder is sent after receipt;
  • an accepted item is silently replaced;
  • a report is published to the wrong client; or
  • staff cannot explain who changed a status.

The failure consequence determines required evidence and operational response. If a safe manual fallback exists, record how staff activate it without losing the authoritative state. If there is no tolerable fallback, the proposed system is more critical than its small user count suggests.

Find the smallest coherent custom layer

A full custom portal is not the only build option. Narrower alternatives include:

  • keep documents in an established portal and build a staff-only exception queue;
  • keep identity and file exchange in an established product and synchronize request status;
  • build a staff dashboard that does not expose client records externally;
  • automate reminder suppression while leaving the system of record unchanged; or
  • prototype the workflow with non-sensitive data before committing to external access.

Produce a decision record

Choose one outcome:

  • Buy: an established product meets the material need.
  • Configure: an established or no-code product can meet it with controlled configuration.
  • Build narrowly: custom software addresses one defensible gap while established systems retain commodity and high-risk responsibilities.
  • Investigate: a hard stop is unresolved and needs evidence.
  • Do not build: the value does not justify the ownership burden or failure consequence.

For every hard stop, record pass, fail, or unresolved; an owner; an evidence link; and a scope reduction if blocked. Do not compute a readiness percentage. One unresolved cross-client access failure outweighs many convenient features.

Frequently asked questions

Is no-code automatically safer than custom code?

No. It may provide managed infrastructure and permission primitives, but those controls still need correct configuration, plan verification, testing, operation, and ownership.

Is a small number of users evidence that the portal is simple?

No. User count affects scale, but external identities, sensitive documents, client isolation, recovery, and support create complexity even at low volume.

When is a custom portal most defensible?

When an important, well-understood workflow remains materially underserved, the business accepts the lifecycle responsibility, high-risk commodity capabilities are delegated where appropriate, and the smallest custom boundary has been tested.