A customer portal needs a project-specific budget, driven mainly by user permissions, data access and integrations rather than the number of screens. For illustration only, forty days of delivery at six hundred pounds a day would cost twenty-four thousand pounds, before tax and ongoing costs. That is a calculation, not a market benchmark or a FullyCoded price. To get a meaningful quote, define what customers must accomplish and which systems the portal must connect to.

A document library and an ordering platform might both be described as a customer portal. Yet one could involve publishing approved files, while the other must enforce account-specific prices, approval rules and stock checks. Pricing them as equivalent projects would hide the work that makes the second system dependable.

Separate the build budget from the cost of running it

Ask for three distinct figures: discovery and specification, implementation and launch, and ongoing operation. Discovery establishes the workflows, technical constraints and acceptance criteria. Implementation covers the agreed design, development, testing and release. Operation keeps the live service maintained and supported.

A useful planning calculation is: agreed delivery effort multiplied by the applicable rates, plus external charges and an explicit allowance for unresolved risks. If a supplier offers a fixed price, ask which assumptions make that price possible and what triggers a change request.

In the illustrative forty-day calculation, those days would need to cover all agreed delivery work, not just coding. If discovery, interface design, security testing or deployment sit outside that allowance, the total is incomplete. Ask suppliers to state whether tax, licences, data preparation and your team's contribution are included or excluded.

User roles determine more than the login process

Authentication establishes who a person is. Authorisation determines what that person can see and do. A successful login does not establish that a user should have access to a particular invoice, document or customer account.

Consider a hypothetical trade customer with several branches. A buyer can submit requests for their branch, a manager can approve them, and a finance user can view invoices across the organisation. An internal administrator may need to manage access without being allowed to change commercial terms. Each distinction creates rules to implement and test.

Before asking for a quote, create a permissions matrix: a simple grid of user types against actions and records. Include who invites users, grants access, changes roles and removes leavers. Specify whether a person can belong to more than one customer organisation.

The important cost driver is not simply how many roles you name. It is how those roles interact with account boundaries, record ownership and exceptions. Access checks belong on the server, not just in hidden buttons. Testing should include attempts to retrieve another customer's records directly, even when the normal interface does not offer that route.

Data access changes the size of the job

A portal that displays information has a different scope from one that changes it. Showing an invoice requires secure retrieval and display. Allowing a customer to amend an order introduces validation, timing restrictions, approval decisions and confirmation that the source system accepted the change.

For each record type, identify the authoritative source: the system whose version takes precedence. Then agree what customers may view or change, how quickly updates must appear and what to display when fresh information is unavailable. An empty order list should not silently stand in for a failed connection.

Data preparation also needs its own allowance. Duplicate customer records, inconsistent account identifiers and files without clear ownership can prevent reliable access decisions. Ask who will clean the data, how records will be matched and whether migration includes historical material or only active accounts.

If you are still deciding which customer tasks deserve that investment, the customer portal examples guide provides useful starting points. Choose the journeys first, then cost their data requirements rather than requesting every possible feature.

Integrations need an investigation, not a checkbox

An application programming interface, or API, lets software exchange information. The existence of an API does not prove that an integration will be straightforward. The required records or actions might be unavailable, access may need separate approval, or a safe test environment may be missing.

Before fixing an integration price, ask the developer to examine documentation, representative data and access arrangements. A small technical investigation can establish whether the proposed workflow is feasible before the wider build depends on it.

  • Define direction: does the portal only read information, submit changes, or synchronise records both ways?
  • Define freshness: must customers see an immediate update, or is a clearly labelled scheduled refresh acceptable?
  • Define failure handling: who sees a rejected update, who resolves it, and how is the customer informed?
  • Define recovery: how will the system avoid creating duplicate orders if it retries after an uncertain response?

For example, an order request can time out after the receiving system has already created the order. Retrying without checking could create a duplicate. Preventing that outcome requires more than connecting a form to an API. It requires agreed identifiers, status handling and a recovery process.

Reduce scope without removing the safeguards

The most useful way to reduce an initial budget is to narrow the customer journey, not omit the controls that make it safe. Start with one complete task, such as retrieving an account document, rather than partially building documents, ordering, messaging and reporting.

A read-only first release can be sensible if visibility solves the immediate problem. A scheduled data refresh may suit historical documents but be unsuitable for a promise about current stock. Make those compromises explicit so a cheaper first version does not mislead customers.

Also assess whether an existing platform can support the journey. Compare its permissions, integration options, export arrangements and recurring charges against your requirements. Bespoke development is worth considering when important rules cannot be accommodated cleanly, not merely because a custom interface would look different.

Include the work that starts after launch

Request a running-cost schedule covering hosting, storage, transactional email, external service licences, maintenance and support. Ask which charges vary with users, files or activity. Keep corrective maintenance separate from the budget for new features so neither disappears inside an ambiguous support allowance.

Agree who receives failure alerts, handles access problems and contacts integration suppliers. Backups need a restoration plan and testing, not just a statement that copies exist. Set recovery expectations around how long customers can reasonably be without the portal and how much recent data the business could tolerate losing.

Your staff also need time for testing, customer onboarding and exception handling. Those tasks remain a business cost even when they are not on the developer's invoice. Nominate someone who can approve workflow decisions and organise realistic acceptance testing before launch.

Compare quotes against the same brief

Give each supplier the same customer journey, permissions matrix, data sources and launch requirements. Include sample records with sensitive information removed. Ask each supplier to identify assumptions, exclusions, dependencies and the evidence needed to resolve uncertain items.

Look for explicit acceptance criteria. For invoice access, these might include a customer seeing only their organisation's invoices, a removed user losing access, and a source-system outage producing a clear message. These are more useful for comparing delivery scope than a line reading 'invoice dashboard'.

At FullyCoded, clients work directly with founder Mark Grice and the people doing the work. If you are considering a project, use the bespoke software development page as a next step and bring the workflow, data sources and unresolved questions to the discussion.

Before accepting a price, ask the supplier to walk one customer task from login through to its final record in the source system, including a failed update. The quote should account for that whole journey, not stop at the screen the customer sees.