Client portal buyer guide
How to choose a client portal development company
Choose the team that can turn your customer workflow, systems and risks into a clear, supportable delivery plan. Relevant judgement, evidence and commercial transparency matter more than the longest feature list.
The short answer
Choose a client portal development company that can demonstrate four things: it understands the operational problem, it can protect customer-specific data, it can connect the systems that must remain in place, and it has a credible method for delivering and supporting the application.
Ask every shortlisted team to work from the same outcome, users, systems and constraints. Compare the quality of their questions, assumptions, architecture reasoning, evidence, delivery plan and ownership terms. Do not select from a feature list or day rate alone.
01
Use criteria that reflect the real delivery risk
| Criterion | What good looks like | What to test |
|---|---|---|
| Workflow discovery | Maps customers, staff, systems, decisions, delays and exceptions before prescribing features | Can the team explain the current and future workflow in plain language? |
| Portal architecture | Defines organisations, memberships, roles, source systems and integration boundaries | How will it prevent one customer from accessing another customer's data? |
| Integration capability | Understands APIs, events, queues, synchronisation, legacy constraints and failure recovery | What happens when a connected system is slow, unavailable or inconsistent? |
| Security practice | Treats identity, authorisation, files, secrets, audit and operations as one system | Which controls are designed, implemented, tested and monitored? |
| Product and UX judgement | Prioritises a complete customer journey and internal support process | How will representative users review the workflow before the build expands? |
| Delivery method | Uses visible increments, clear acceptance criteria and active risk management | What will you be able to review at each stage? |
| Commercial clarity | States assumptions, exclusions, dependencies, change rules and total ownership costs | Which events would change the price or schedule? |
| Operational ownership | Plans deployment, monitoring, support, access administration and continuity | Who responds when the portal or an integration fails? |
02
Ask for evidence relevant to your hardest problem
A polished portfolio is useful, but it may not show whether the team handled the difficult parts of a portal. Request evidence at the level the supplier is permitted to share:
- a comparable customer, partner or operational workflow;
- an example of organisation and role-based access design;
- an integration involving the types of systems in your environment;
- a security, data-separation or file-handling decision and how it was tested;
- a project where discovery changed the proposed solution;
- an example of a difficult exception or production problem and what the team learned;
- the kind of documentation, test evidence and handover produced; and
- a reference who can discuss communication, decision quality and support after launch.
Respect confidentiality. A credible team may anonymise a client or decline to show sensitive architecture. It should still be able to explain its reasoning and delivery method without inventing results.
03
Judge the questions asked during discovery
Outcome
What should improve?
Strong teams ask about customer effort, handling time, errors, visibility, capacity and measurable service outcomes.
Users
Who belongs to what?
They investigate customer organisations, branches, memberships, roles, approvers, administrators and access lifecycle.
Systems
Where does truth live?
They identify the owner of each field and action, available interfaces, data quality, refresh needs and failure behaviour.
Operations
How will staff support it?
They include onboarding, exceptions, audit, support access, content ownership, monitoring and incident response.
Be cautious if the conversation moves directly from your idea to screens and features without examining customer separation, internal workflow, data ownership and operational support.
04
Compare proposals on the same foundation
Provide each shortlisted company with the same concise brief: target users, current workflow, desired outcome, known systems, data sensitivity, constraints, expected usage and decision date. Ask the proposal to cover:
- understanding of the problem and recommended first release;
- assumptions and questions that must be resolved;
- included and excluded capabilities;
- architecture and integration approach at an appropriate level;
- security, privacy, testing and operational responsibilities;
- team roles, availability and use of subcontractors;
- delivery stages, review points and acceptance criteria;
- price, payment schedule, contingency and change process;
- hosting, licences, third-party services and recurring costs;
- code, account, data, documentation and intellectual-property ownership; and
- warranty, support, maintenance and exit arrangements.
A detailed proposal based on weak assumptions is not safer than a smaller proposal that clearly identifies what discovery must prove.
05
Use a weighted scorecard, then discuss the judgement behind it
| Area | Example weighting | Evidence to score |
|---|---|---|
| Problem and workflow understanding | 20% | Discovery quality, proposed scope and treatment of exceptions |
| Technical and security fit | 20% | Architecture reasoning, permissions, integrations, testing and operations |
| Relevant delivery evidence | 15% | Comparable work, references, lessons and artefacts |
| Delivery team and method | 15% | Named roles, capacity, review cadence, risk and quality process |
| Commercial and ownership clarity | 15% | Assumptions, total cost, change rules, accounts, code and exit terms |
| Communication and working fit | 10% | Responsiveness, clarity, challenge, transparency and decision records |
| Price | 5% | Value and credibility relative to the same scope and risk |
Adjust the weighting to the project. Price may deserve more weight for a low-risk configured solution, while security, integration or operational continuity may dominate a sensitive portal. Use the scorecard to expose differences, not to replace reference checks and informed judgement.
06
Watch for warning signs before appointment
- a confident fixed price before the team understands users, systems and permissions;
- security described only as login, encryption or hosting provider responsibility;
- no clear answer about customer data separation or server-side authorisation;
- integrations assumed to be simple because an API exists;
- a proposal dominated by screens without an internal operating process;
- large upfront payment without reviewable milestones or acceptance criteria;
- unclear ownership of repositories, cloud accounts, domains, data or custom code;
- key work delegated to unnamed people whose experience you cannot assess;
- unverifiable claims, guaranteed outcomes or references that cannot be explained; and
- no plan for monitoring, support, access changes, backups or supplier exit.
07
A practical supplier selection process
- Prepare a short outcome brief. Include users, current workflow, systems, constraints and success measures.
- Create a credible shortlist. Use relevant evidence and working fit, not only search visibility or company size.
- Hold the same structured conversation. Let each team ask questions and explain its initial reasoning.
- Request comparable proposals. Use a shared response structure and declare the evaluation criteria.
- Review the proposed team. Meet the people responsible for discovery, architecture and delivery.
- Check evidence and references. Ask about difficult decisions, communication, changes and post-launch support.
- Resolve commercial terms. Confirm scope, ownership, accounts, change rules, support and exit before signing.
- Use paid discovery where uncertainty is material. Treat it as a decision stage with useful outputs, not an automatic commitment to the full build.
Use the client portal implementation checklist to test whether the proposed plan covers the full delivery lifecycle. Compare scope and ownership options in the build-versus-buy guide and planning costs in the South African cost guide.
Questions
Frequently asked questions
What should I look for in a client portal development company?
Look for evidence that the company can understand the customer workflow, design organisation-level permissions, integrate existing systems, manage security and data risks, deliver in reviewable increments, and support the application after launch. The strongest proposal explains trade-offs and assumptions rather than only listing features.
Should I choose a specialist or a general software company?
Choose the team whose relevant experience matches the hardest parts of your portal. A specialist label matters less than demonstrated judgement around external identity, customer data separation, integrations, workflow, administration and operations.
How many companies should I compare?
A small shortlist is usually easier to evaluate properly than a large tender list. Give each credible supplier the same outcome, constraints and evaluation criteria, then compare how they reason about the work rather than how many features they promise.
Should the developer provide a fixed price?
A fixed price can work for a well-defined scope with known integrations and acceptance criteria. When important assumptions remain unresolved, a paid discovery phase followed by a delivery estimate can be more credible than a low fixed price padded with exclusions or change requests.
Who should own the source code and accounts?
The agreement should state who owns the custom code, designs, data models and documentation, and who controls repositories, cloud accounts, domains, analytics and third-party subscriptions. Any retained supplier components or licences should be disclosed before appointment.
Evaluate LCR against the same criteria
Bring us the customer workflow and the difficult constraints.
LCR will help clarify the first useful scope, major assumptions, system dependencies and sensible delivery path before asking you to commit to a build.