WEB APP DEVELOPMENT / CUSTOMER PORTALS
Customer portal development for London businesses.
Give customers one controlled place to complete the service tasks that matter.
A customer portal is an authenticated web application for customers or clients to complete recurring service tasks. A useful first release gives one defined user a complete journey from access to confirmation and support, without exposing unrelated data or hiding essential staff work.
Request a scoped proposal
01 / DECISION
Choose a portal only when the service problem is real.
Start with the task customers are trying to complete and the people who deliver or support it. GOV.UK user-needs guidance treats untested stakeholder opinions as assumptions and recommends research with actual or likely users. That principle is useful for commercial portals even though the government process is not a private-sector requirement.
A portal is not automatically the right response to repeated emails, slow updates, or fragmented documents. First test whether clearer ownership, better content, an ordinary form, or an existing platform can solve the important problem with less software and operating risk.
| Approach | Best fit | Evidence before commitment | Main trade-off |
|---|---|---|---|
| Improve the existing service | Customers mainly need clearer information, forms, messages, or ownership | Observe the complete journey and test whether a content or process change removes the problem | Existing systems and manual hand-offs remain |
| Configure an existing platform | A product already supports the essential journey, permissions, data and integrations | Prototype the real workflow, verify limits and model the first-year operating and exit costs | The service must work within the platform’s rules and roadmap |
| Build a custom portal | The customer journey or operating model is valuable and materially different | Test the riskiest journey, data, integration and permission assumptions before full delivery | The organisation accepts responsibility for a live software service |
02 / FIRST JOURNEY
One complete journey beats a long feature list.
- One defined customer or client role
- One valuable task with a clear start and finish
- The staff, administrator and support path behind the interface
- Important exceptions, failure states and recovery
- The required systems of record and data movement
- A baseline, acceptance evidence and a next decision
Protect the boundary
- Name later customer roles and journeys as non-goals
- Keep manual fallbacks visible
- Separate prototype evidence from production readiness
- Assign every unresolved dependency an owner
A first release is a controlled service boundary, not a promise to replace every customer interaction.
03 / DELIVERY
Design the interface and the operating service together.
- 01
Map the customer and staff journey
Define who needs the portal, the task they must complete, the surrounding email, phone or offline steps, important exceptions, the current baseline, and the evidence that would justify a build.
- 02
Define identity, data and permissions
Map invitations, authentication, recovery, roles, access changes, systems of record, documents, retention, deletion, exports, integration failures, and the people accountable for each decision.
- 03
Prototype the uncertain boundaries
Test the priority journey with representative users and run technical proofs for any integration, migration, permission or operating constraint capable of changing the release plan.
- 04
Build, assure and operate
Deliver a controlled release with accessibility, privacy, security, support, monitoring, recovery, documentation, account ownership, and a measurable route for improvement.
04 / BUILD OR BUY
Compare the whole service, not the demo screen.
Configured software can be the responsible choice when it supports the real journey and its accessibility, data, integration, ownership, and exit requirements. A custom portal is justified when the valuable workflow is materially different and the organisation is prepared to own a live software service.
GOV.UK guidance on commercial off-the-shelf products recommends understanding the problem and testing alternatives before committing to technology. Blancc uses that as an adaptable comparison prompt; the government procurement rules and lifecycle are not presented as private-sector law.
| Decision | Configured platform | Custom portal | Staged hybrid |
|---|---|---|---|
| Journey fit | Use established workflows with bounded configuration | Model a materially distinct customer and staff service | Prove the journey before replacing constrained parts |
| Integration | Work within available connectors, APIs and provider rules | Design around verified interfaces and owned failure handling | Connect one system first and defer uncertain dependencies |
| Ownership | Rely on supplier terms, exports and roadmap | Define code, account, data, documentation and deployment control | Keep portable data and an explicit transition plan |
| Evidence | Prototype the real workflow in the candidate product | Test user, permission, data and technical assumptions | Set a decision gate before further custom delivery |
05 / ASSURANCE
Turn quality claims into reviewable evidence.
Customer portals commonly handle identities, permissions and personal information. The ICO says data protection must begin at design and continue through the lifecycle. The exact legal, security and assurance work depends on the data, users, decisions and risks in the specific service.
- User research and complete journey evidence
- Authentication, recovery, role and permission matrix
- Data-flow, retention, deletion and processor map
- Integration, failure-state and recovery tests
- Keyboard, browser, device and assistive-technology coverage
- Security requirements, verification scope and vulnerability response
- Monitoring, support, incident and supplier-exit ownership
Useful reference points
- W3C WCAG 2 overview
- NCSC secure development principles
- OWASP Application Security Verification Standard
- GOV.UK Service Standard
Standards and guidance help define testable requirements. They do not make a portal compliant, secure, accessible or suitable without context-specific implementation and review.
06 / COST
Estimate the service, not a screen count.
Portal cost follows the number of roles and journeys, permission complexity, data quality, integrations, migration, assurance, support, availability, and operating responsibilities. A screen list cannot expose the rules, exceptions and connected-system work that usually shape delivery.
Blancc’s web app development cost guide provides reproducible illustrative person-day scenarios, not market averages or a portal quotation. Replace every editorial assumption with a discovery-backed role plan, release boundary, third-party cost, risk allowance, and first-year operating model.
Request a scoped portal proposal07 / ILLUSTRATIVE RELEASE
A document-and-status portal for one customer role.
This example is illustrative and hypothetical. It is not a Blancc client project, performance result, quotation, schedule, or security assessment. A service business currently sends status updates and approved documents by email, while customers contact staff when they cannot find the latest version.
- Invite one customer role and complete a clear account-recovery path
- Show the current status and approved documents from one source of truth
- Let the customer submit one bounded request and receive a confirmation
- Give authorised staff a way to correct content, revoke access and handle exceptions
- Record representative journey, accessibility, permission and integration test evidence
- Keep a documented manual fallback when the portal or connected system is unavailable
Explicit non-goals
- Replacing the complete CRM or finance system
- Supporting every customer type, workflow and historical document
- Adding native mobile applications before the browser journey is evidenced
- Claiming savings, adoption, compliance, security or service outcomes before measurement
The release would proceed, change or stop according to observed journey and operating evidence—not the existence of working screens.
08 / SUPPLIER CHECKLIST
Make every proposal answer the same questions.
- The user problem, current baseline, intended customer roles and complete service journey
- The first-release boundary, non-goals, assumptions, dependencies and stop conditions
- Authentication, recovery, role, permission, audit and account-administration responsibilities
- Data purposes, sources, quality, migration, retention, deletion, export and processor roles
- Integration documentation, test access, failure handling, monitoring and fallback routes
- Accessibility scope, representative user research, manual checks and assistive-technology testing
- Security requirements, verification approach, vulnerability response and independent specialist work
- Source code, design files, domains, cloud accounts, credentials, documentation and handover ownership
- Support hours, service expectations, incident ownership, change control, operating costs and supplier exit
Before authorisation
- Compare the same release and responsibilities
- Separate supplier fees, client effort and external costs
- Require acceptance evidence for each phase
- Record who can approve, change, stop and operate the service
OWASP ASVS can help buyers specify web-application security verification requirements in procurement. Specialist scoping remains necessary.
09 / QUESTIONS
Customer portal questions, answered.
What is the difference between a customer and client portal?
Customer portal and client portal usually describe the same broad pattern: an authenticated web application where an external user accesses relevant information or completes service tasks. The right name should follow the audience’s language rather than imply a different technical product.
When is a portal better than an ordinary website?
A portal is appropriate when identified users need controlled access to customer-specific data, documents, status, requests, approvals, payments, or support. A public website is usually better when the same information and actions can be available safely to every visitor.
Can a customer portal integrate with our CRM or finance system?
A portal can integrate with a CRM, finance platform, document store, support system, or another documented interface. Feasibility depends on available APIs, authentication, permissions, data quality, rate limits, test environments, commercial terms, and recoverable behaviour when the connection fails.
How much does customer portal development cost?
Customer portal cost depends on the user roles, journeys, permissions, data, integrations, migration, assurance, support, and operating model. Blancc scopes a release before proposing a price; the existing web-app cost guide provides transparent illustrative planning bands rather than a universal portal quotation.
Does a customer portal need a mobile app?
Most portal journeys can start as a responsive web application when link access and broad device coverage matter. A native mobile app needs a separate product case based on installed repeat use, offline behaviour, notifications, device capabilities, distribution, and ongoing platform operations.
Who owns the portal after launch?
Ownership must be explicit before delivery begins. A proposal should state control of source code, design files, domains, cloud accounts, customer data, credentials, licences, documentation, exports, support, and deployment. Third-party terms and any supplier-retained rights should remain visible.
10 / SOURCES & LIMITS
Primary guidance, applied proportionately.
This page is a general commercial planning framework. It is not user research, a technical architecture, legal advice, an accessibility audit, a security assessment, a quotation, or a guarantee of adoption, savings, service quality or business results.
GOV.UK guidance is written for government services. Blancc uses selected problem, user, service and technology questions as adaptable prompts; it does not present public-sector rules, phases or assessment requirements as private-sector law.
- GOV.UK Service Manual: Learning about users and their needs
- GOV.UK Service Manual: Service Standard
- GOV.UK Service Manual: Using commercial-off-the-shelf products and services
- ICO: Data protection by design and by default
- National Cyber Security Centre: Secure development principles
- W3C Web Accessibility Initiative: WCAG 2 overview
- OWASP: Application Security Verification Standard