Custom business web apps
Give clients one place to keep things moving.
When updates, documents and requests live across several inboxes, simple tasks take longer. A client portal gives customers a signed-in place to find the information and actions relevant to them.
When a client portal is useful
A portal is worth considering when existing clients repeatedly ask for updates, send information across several channels or need access to records specific to their account. It brings those actions into a defined place, with a clear next step for both the client and your team.
A public website is usually the starting point when people only need service information and an enquiry form. If your current software already provides the required client access, configuring it may be the simpler option. We review that before proposing a custom build. Our website, app and client portal comparison helps you choose.
What we can scope for your portal
Start with the work clients need to complete, then choose the features that support it. These are possible requirements to discuss; your proposal confirms the actual build.
| Feature | Client task | Confirm in the scope |
|---|---|---|
| Client requests | A client submits a request, sees its status and supplies missing information. | Who receives it, which updates the client can see and when a person takes over. |
| Project updates | Clients check agreed milestones, next steps and shared resources. | Which system owns the status and who is responsible for keeping it current. |
| Documents and approvals | Permitted users access the right files or review an item. | File access, version history, retention and the actual approval process. |
| Bookings and account information | Clients see relevant appointments or connected account details. | Supported calendar or account access, changes, cancellations and failed connections. |
Define who can see and change each record
A login screen is only one part of a portal. We need to define which client account owns each record, what assigned staff can do and what an administrator can manage. Those rules belong in the build and its checks, including attempts to open another client's record through a changed link.
- List client, staff and administrator roles and the actions each can take.
- Agree invitation, account recovery and access-removal behaviour.
- Decide which files and actions need a history, review or approval.
- Confirm hosting, backups, data export and the person responsible for support.
Tell us early if the project involves sensitive information, regulated work or unusual access requirements. We assess the necessary controls and feasibility before agreeing the scope. A visual prototype does not establish that account isolation or a connected system is working.
Connect the portal to the right source of information
Your CRM, calendar or project tool may already hold the records the portal needs. We identify the source of truth, the permitted read and write actions and the account access needed for each connection. Availability depends on the actual system and subscription; a connection stays unconfirmed until its required behaviour is checked.
The plan also covers a failed connection, a repeated submission and an update that needs staff review. Existing-data cleanup, migration, payments and third-party licences are separate scope items when required. For the wider handoff, explore our CRM and business automation service.
How your portal project moves from brief to launch
First, we map one complete workflow and the users involved. Next, we confirm the first-release scope, key screens, connections and acceptance checks. Development and review follow that agreed plan. Before launch, the relevant checks cover the client task, staff handoff, account boundaries and failure cases. The proposal sets who approves the work and maintains it afterwards.
Portal projects are quoted individually. User roles, data movement, integrations and ongoing responsibilities affect the work required. A managed website subscription does not automatically include a portal. Build charges, hosting, licences and ongoing support are identified in the written proposal; there is no automatic price or delivery date from this page.
Use the app-project brief builder to organise your requirements. To explore something we have actually built, see the working planning tools on our own website. They demonstrate focused browser tools; they are not a production client portal or evidence of customer results.
Questions before we scope the build
Can clients use it on a phone?
We can scope a responsive web portal for phone and desktop browsers. Native iOS or Android apps, app-store release and offline behaviour require a separate assessment.
Can we keep the tools we already use?
Often that is the first option to assess. Share the required task and your existing systems; we check whether supported access can deliver the workflow before recommending replacement software.
What do you need for a useful first conversation?
Describe one client task, the people involved, the information they need and where it is stored now. Include the main exception and what successful completion looks like. Keep customer records and live credentials out of a public brief.
Start with one complete client task
Tell us what clients need to do and what your team handles next. We will discuss the approach and confirm a feasible first release in writing.