If customers need to check a job, send a document or approve work, you may need a portal. You probably do not need to replace the software that already runs the business. Start by checking what that software can show or accept safely. Buy a portal if the workflow is standard. Build a focused layer only when the missing customer journey is valuable enough to justify its upkeep.
That answer sounds less exciting than a new platform launch. It is also a better starting point for a small business that already has customer records, invoices and jobs in several places. A portal is another product to operate. Its purpose is to make a particular customer task easier, not to become a second copy of every system behind it.
What should a customer actually be able to do?
Write one sentence from the customer’s point of view: “I can see whether my order is ready and download the right document without calling the office.” Then identify the action and the information it needs. A status page that is updated by hand might answer the question for a few customers. A portal with accounts, permissions and live data is a larger commitment.
Look at the work around the task as well. Who records the status today? How often does it change? Does a customer need to correct it, approve it or only read it? Which person in your business resolves a disagreement? If the team cannot agree what “ready” means, software will expose that disagreement more quickly. Define the status and its owner before designing a screen.
Ask for a short list of real customer questions from the people who answer them. Do not turn every internal field into a customer feature. An internal job note may contain a supplier name or a provisional date that should never be shown outside the business. The first useful release may be one status, one document type and a way to ask for help.
Could the software you already pay for do it?
Check your current accounting, job, CRM and document products before commissioning anything. Some include customer access, secure file sharing or an approval flow. Others have a portal option in a higher tier or through an existing integration. Ask the vendor to demonstrate your specific task using test records. A feature list is a starting point, not an acceptance test.
Product capability changes. In its October 2026 product update, FreeAgent describes broader integrations, bulk imports and more detailed practice controls. That does not mean it supplies the portal your business needs. It does mean an older assessment of the product may be out of date. Check current permissions, export options and the price of the exact feature before assuming a replacement is necessary.
I would test the built-in route with one customer account and one awkward record. Can the customer find the correct document? Can they see another customer’s material by changing a link or using an old invitation? Can your team correct a mistake without emailing a file around? If a built-in feature passes those checks at an acceptable running cost, stop there.
When does a bought portal make sense?
A separate portal product can be sensible for standard tasks: sharing files, collecting forms, raising support requests and sending approvals. You gain a maintained product and a quicker route to launch. You also take on a supplier contract and a new place where customers sign in. Those costs may be entirely reasonable when the process is common and the connection to your other systems is simple.
Test the complete journey, not just the portal’s home screen. A customer uploads a revised document. Where does it land? Who gets notified? Is the correct job updated? What happens if the same customer has two accounts or a contact leaves their company? Ask to see the ordinary case and the exception. If the portal only makes a tidy front page while your team copies data into the job system, count that manual work in the decision.
Get a quote at today’s customer count and at a plausible higher count. Include external users, storage, API access, branding and support. Ask whether you can export files, account relationships and activity history in a usable form. A subscription with managed maintenance can be better value than a build. A cheap entry price is not enough to prove it.
What would a small bespoke portal add?
A custom portal can put one clear customer experience over the systems you already use. For example, it might show a job status from the job system and an invoice from the accounts system, while leaving each record in its original home. This is a design option, not a promise that every vendor exposes the required data. Confirm the supported API, permissions, limits and commercial terms before designing around it.
Xero’s custom development guidance describes an API route for bespoke workflows and UK Custom Connections. Its API limits guidance also sets per-connection rate limits and explains what happens when an app makes too many requests. A portal that refreshes every customer’s financial data on every page load needs a different design from one that retrieves a small, authorised view on demand. These details affect performance, support and cost.
Xero’s 21 October 2026 announcement describes an embedded integration for a US accounting partner. It is a current illustration of extending a platform rather than replacing it. It does not establish that the same arrangement, price or payment functions are available to a UK SME. Your own integration must be assessed against the systems and contract you actually have.
Keep the first release narrow. A customer can view the status of their own open job and download an approved document. Your team continues to edit the source record in the existing system. Once that read-only path works, assess whether customers genuinely need to submit changes through the portal. Each write introduces validation, audit and support questions. Our guide to who fixes an integration when an API changes covers the maintenance obligation behind that choice.
Which system owns each piece of information?
Draw a small table before any development: customer identity, job status, invoice, document, approval and message. Name the system that owns each item and the person who can correct it. If two systems can both change a status, specify which wins and how a disagreement is resolved. Do not rely on “they will sync” as the answer.
The portal should display enough context for a customer to act, without becoming an uncontrolled database of copied records. Sometimes a small, temporary copy is needed for speed or reliability. Decide how it is refreshed, protected and deleted. The ICO’s guidance for privacy in the product design lifecycle calls for personal information to be considered from initial design through operation, rather than added as a final check.
For a customer-facing portal, access is a product feature. Decide who can invite a colleague, which company an account belongs to, and what happens when a contact changes employer. Test a revoked user, a mistaken invitation and an old browser session. The ICO’s access-control toolkit covers role-appropriate rights, reviews and timely removal. Your implementation and legal responsibilities depend on the data and the parties involved, so get the right advice for sensitive use cases.
How would you test it before inviting everyone?
Use invented records in a test environment and define a pass condition for one complete customer journey. A useful pilot might cover five steps:
- Your team changes a job’s status in the source system and the correct customer sees it in the portal.
- Another customer cannot reach that job or its documents, including through a copied link.
- A correction in the source system appears without a second manual edit.
- The portal explains a delayed or unavailable connection rather than showing an old status as current.
- Your team can remove an external account and confirm access has ended.
Then let a small group of real users try the workflow with permission and support available. Record the questions they ask, the calls that still arrive and the mistakes your team has to repair. Do not call the pilot successful because the page loads. Its value depends on the work customers can finish and the effort required to keep the information right.
If the portal will accept payments, signatures or regulated information, the test plan and supplier review need to grow accordingly. Those features should not slip into a simple status pilot because a vendor demo makes them look easy.
What will it cost to run and leave?
Compare the options over the same period and workload. For a built-in feature, include the required subscription tier and the time to configure it. For a bought portal, include licences, external users, storage, integration fees, support and manual work that remains. For a bespoke layer, include discovery, design, development, hosting, monitoring, security updates, API changes and someone accountable for support. Avoid a comparison between one option’s first-year price and another’s full lifetime cost.
Ask what happens if you change suppliers. Can the business keep the domain, source code, deployment instructions, access credentials and usable data exports? Can a new team maintain the portal without reconstructing the architecture from scratch? Our total running cost guide gives a fuller comparison of ownership and subscription costs. Ownership has value only when the handover is practical.
A custom portal can cost more than a bought one for its whole life. It can also save work where the customer task is unusual and the integration is stable. Neither result follows from the word “bespoke”. Price the actual task and revisit the decision when the workload or vendor offering changes.
What should you decide now?
Choose one customer task, the system that owns its data and a pass condition for a small pilot. Ask your current vendors to demonstrate it. If they cannot, test a bought portal with the same records and failure cases. Scope a focused build only when those routes leave a material gap and you can name who will maintain it.
If you want help turning that test into a realistic brief, Ajairu’s software development work starts with the workflow and the systems already in place. Get in touch with the task customers need to finish and the software your team uses today.