Stop Answering the Same Question Forty Times a Week
Most UK companies who ask us for a web application are really asking for one thing: somewhere their customers can look something up, book something or upload something without ringing the office. We build that — portals, booking systems, member areas and the internal tools your staff live in — with roles, accessibility and UK data residency settled before a screen is designed.
Your Inbox Has Already Written the Specification
Before we scope a portal we ask for something unglamorous: a week of your inbound enquiries. Not a wish list, not a competitor site — the actual emails and the actual calls your team logged. The pattern is remarkably consistent. Where is my order. Can you send that certificate again. Has the engineer been booked. What did we pay last quarter. Can you change the address on the account.
Every one of those is a query your systems can already answer. Somebody is just being paid to be the interface. A portal is the decision to stop paying for that, and the week of enquiries tells us which five screens do most of the work — which is usually a far smaller build than the one people arrive asking for.
How we scope a buildWhat It Looks Like Before There Is a Portal
If three or four of these are familiar, the business case usually writes itself.
Self-Service, Booking, Membership, Back Office
They share a technology stack and almost nothing else. The differences decide the cost.
Customer self-service portals
- A tenant of a letting agent raising a repair, tracking it and seeing the contractor assigned
- Documents, certificates and statements available on demand instead of by request
- Account and contact details the customer can correct themselves
- The measurable result is fewer inbound calls, so we instrument that from day one
- Hardest part: deciding exactly what a customer is allowed to see about themselves
Booking and scheduling systems
- A private clinic taking appointments against real practitioner availability
- Rules that matter more than the calendar: notice periods, buffers, room and equipment clashes
- Reminders by email and SMS, and a cancellation policy enforced rather than described
- Deposits or payment at booking through Stripe, with refunds handled properly
- Hardest part: the twelve exceptions your staff apply without realising they are rules
Member and subscriber areas
- A trade association or professional body gating content, events and CPD records
- Renewals, lapsed members, grace periods and the awkward category of honorary members
- Organisation-level membership where one invoice covers fifteen named people
- A committee or branch structure that decides who administers whom
- Hardest part: migrating a membership list that has been curated in a spreadsheet for years
Internal operations tools
- A logistics firm tracking consignments and the customs paperwork attached to each one
- Built for speed rather than beauty, because the same person uses it four hundred times a day
- Keyboard-first, bulk actions, and no confirmation dialogue for the routine case
- An audit trail, because someone will eventually ask who changed that field
- Hardest part: replacing a spreadsheet that one person understands completely
Who Is Allowed to See What, Written Down Before Anything Is Drawn
Signing in is a solved problem. Deciding what each person may do once they are in is the part that quietly consumes budgets.
A person is not an account
One human may be a tenant at one address, a guarantor at another and a contractor on a third. Modelling the relationship rather than the login is the difference between a portal that grows and one that gets rebuilt in year two.
Delegated and shared access
A finance manager who should see invoices but not clinical notes. A landlord who has asked their agent to act for them. A carer acting for a family member. These are ordinary UK cases and they need to be a feature, not a workaround.
Staff view, with a record
Your support team needs to see what the customer sees to help them. We build that as an explicit, logged action rather than a shared password, so a subject access request can be answered with an actual list of who looked at what.
Second factor where it earns it
Mandatory for staff and administrators, optional for customers unless the data justifies it. Forcing a second factor on an eighty-year-old member checking a newsletter buys you support calls rather than security.
Single sign-on, later usually
Microsoft Entra ID or Google Workspace sign-in is straightforward to add for staff and frequently demanded by corporate and public sector customers. It is rarely worth building in version one unless a named client has asked for it in writing.
Leavers and lapsed accounts
What happens the day someone leaves the client company, the tenancy ends or the membership lapses. Deciding this early avoids the common finding that a former employee still has a live login eighteen months on.
The Long Tail You Cannot Ignore If You Sell to Institutions
Consumer products can follow the market. A portal used by a council team, a hospital department or a two-hundred-person professional services firm cannot.
Managed corporate and public sector desktops move on a procurement cycle, not a release cycle. The practical effect is not that we support ancient browsers forever — it is that we agree a named list at scoping, test against it deliberately, and choose techniques that degrade sensibly rather than blanking the screen.
| Where it is used | What you typically meet | What we do about it |
|---|---|---|
| General public, consumer-facing portal | Recent Chrome, Safari, Edge and Firefox, heavily weighted to mobile | Current standards, mobile layouts designed first rather than squeezed down |
| Public sector and NHS desktops | Managed Edge and Chrome builds, sometimes a version or two behind, on modest hardware | Keep client-side work light, avoid the newest browser features, test on a throttled profile |
| Large corporate estates | A locked-down standard build with extensions and policies applied centrally | Nothing that needs a plug-in, careful with pop-ups and downloads, an IT-facing notes page |
| Site and field staff | Android handsets of very mixed quality, patchy mobile data | Small payloads, forgiving forms, clear offline messaging rather than silent failure |
| Assistive technology users | Screen readers, magnification, keyboard-only and switch access | Tested with a keyboard and a screen reader before launch, not after a complaint |
Illustrative categories drawn from the kinds of audience we scope for, not measured statistics.
The Report That Takes Ninety Seconds
Portals rarely fail at launch. They fail in month fourteen, when three years of records have accumulated and the screen everybody uses has quietly become the slowest thing in the business.
Test against the volume you will have
We seed the development database with the number of records you expect in three years, not the forty rows a demo needs. Almost every slow query in a portal is invisible until then, and free to fix before launch.
Paginate, filter and index deliberately
Nothing loads a whole table. Lists are paged, searches are indexed against the columns people actually search, and the default view is the one the user wants rather than everything ever recorded.
Long jobs move to the background
A quarterly export across every account does not run inside a web request. It queues, the user carries on working, and an email or a notification arrives when the file is ready. This also stops a single large report taking the site down for everyone else.
Aggregate once, read many times
Figures that never change once a month closes get calculated once and stored. Recomputing four years of history every time somebody opens a dashboard is the single most common cause of a portal that gets slower every quarter.
Files are not database rows
Certificates, photographs and scanned paperwork go to object storage with signed, expiring links rather than into the database or a public folder. Portals that email document links with no expiry are a common finding when we audit an existing build.
Watch the slowest pages, continuously
Response times per endpoint are monitored after launch, with an alert when a page crosses a threshold. That turns a gradual decline into a ticket in a sprint rather than a complaint from your biggest client.
WCAG 2.2 AA Is a Procurement Requirement, Not a Nice Gesture
If your portal will be used by a council, an NHS trust, a university or a housing association — or by the public on behalf of one — accessibility stops being a design preference and becomes a condition of the contract. The public sector accessibility regulations require conformance with WCAG 2.2 AA and a published accessibility statement that is honest about anything not yet conforming. Procurement teams ask for both, and an evasive answer loses tenders.
Retrofitting is where the money goes. A portal built with div elements pretending to be buttons, colour-coded statuses with no text label and modal dialogues that trap focus is not fixed with a plug-in; it is fixed by rebuilding the components. Doing it correctly the first time costs very little, which is why we do it by default on every build regardless of who the buyer is.
What that means in the work
- Semantic HTML first, so a button is a button and a heading structure genuinely describes the page
- Every interactive element reachable and operable by keyboard, with a focus state you can actually see
- Contrast ratios checked against the standard during design rather than argued about afterwards
- Form errors tied to their fields, announced to screen readers, and written as instructions rather than complaints
- Target sizes and drag alternatives, which is one of the practical additions WCAG 2.2 brought in
- A manual pass with a keyboard and a screen reader before launch, because automated checks catch only a portion of real problems
- A draft accessibility statement handed over with the build, for you to publish and keep current
We will not tell you a build is certified, because there is no certificate. What we will give you is a tested application, a written record of what was checked and how, and an honest list of anything we know falls short.
Data Protection Decisions Belong in the Database Design
A customer portal is, by definition, a pile of personal data with a login on the front. Under UK GDPR and the Data Protection Act 2018 that puts several decisions on the table before the schema is written, because each of them is expensive to change once there are records in the system.
- What you genuinely need. Every field on a signup form is a field you must justify, secure, and eventually delete. The cheapest personal data to protect is the data you decided not to collect.
- How long you keep it. Retention is a per-category decision: a maintenance photograph, a signed tenancy agreement and a marketing preference do not belong on the same clock. We build retention as a scheduled job, not a note in a policy document.
- How a subject access request is serviced. Someone will ask for everything you hold about them. If the answer involves a developer writing a one-off query, it will be late. We build the export.
- What erasure actually means. Deleting a user row that a hundred invoices reference is not an option. Deciding in advance which records are anonymised and which are legally retained avoids an urgent architectural argument during a live request.
- Where it is stored. UK or EU regions where you need that, with the region written into the infrastructure configuration rather than left as a default.
- Who processes it on your behalf. Every third party the portal sends data to belongs on a list you can hand to the ICO, with a data processing agreement behind it. We will sign ours.
None of this is legal advice and we do not pretend to give it. It is the set of questions we ask so that when your solicitor or data protection officer does have an opinion, the software can implement it without a rebuild.
Sixteen Weeks, Set Out Honestly
A mid-sized portal with two or three user types. Smaller builds compress this; anything with a serious integration extends it.
Week 0 — The enquiry audit and the sterling range
We go through a week of your real inbound enquiries and a walkthrough of the systems that already hold the answers. You leave with a written scope, a feature list split into launch and backlog, and a fixed price excluding VAT. Nothing has been designed and nothing has been built, which is deliberate — this is the stage where scope is cheapest to cut.
Weeks 1–2 — The permissions map and the data model
The least visible fortnight of the project and the one that decides the rest. Every user type, every relationship between a person and a record, and every rule about who may see or change what, written down and signed off. We design the database from that map rather than from the screens, because the screens will change and the data model will not.
Weeks 3–4 — Screens and a clickable prototype
Designs for every screen and a prototype you can click through and put in front of two or three real customers before it exists in code. Accessibility is reviewed here, at the point where contrast, focus order and labelling cost nothing to change. You sign off the prototype before production code starts.
Weeks 5–12 — Fortnightly sprints on a real environment
Accounts and permissions first, then the core self-service journeys, then the staff-facing side, then integrations. At the end of every second week there is a build on a staging URL you and your team can log into and use. You get a written update at the close of every working day and a call inside the morning overlap whenever you want one.
Week 13 — Volume, browser and accessibility pass
The database is loaded with three years of representative data and the slow pages are found and fixed. The named browser list is worked through by hand. A keyboard and screen reader pass is run against every journey, and anything outstanding is written into the accessibility statement rather than quietly left.
Weeks 14–15 — A cohort, then everybody
We go live with a small group of cooperative customers rather than the whole list, which surfaces the things no amount of internal testing finds. Your staff get a short handover session and a one-page crib sheet. Only then does the email go out to everyone.
Week 16 onwards — Watching the call volume
Monitoring and error alerting are live from day one, and we look together at whether the enquiries that prompted the project have actually dropped. That number, not a feature count, is how we judge whether the build worked. Most clients move onto a maintenance retainer at this point.
Four Times We Have Told Someone Not to Build One
The customer count is too small. A consultancy with fourteen clients who each make two enquiries a year does not have a portal problem. It has an email problem, and a shared folder with sensible naming will fix it for nothing. We have said this in first calls and lost the work, which is the correct outcome.
The system you already pay for does it. A surprising number of practice management, property management and accounting platforms include a client portal that nobody has switched on. It will be less pleasant than a bespoke build. It will also be included in a licence you already hold, and we would rather point at it than charge you to duplicate it.
The underlying process is the problem. If the reason customers ring is that nobody knows the answer internally either, a portal simply publishes the confusion. Fix the process, then build the interface. We have turned projects down on exactly this basis and taken them up again six months later.
Nobody internally will own it. A portal needs someone whose job includes answering the messages that come through it and deciding what the next change should be. Where that person does not exist and is not being hired, the portal gets quietly abandoned and the phone starts ringing again by month four.
If you are somewhere between these cases and a genuine build, a short paid discovery is usually the cheapest way to find out. It is a fixed fee, it produces a written recommendation, and the recommendation is sometimes that you do not need us.
Portal Questions We Are Asked Before the Estimate
How many customers do we need before a portal pays for itself?
There is no magic number, but the arithmetic is straightforward. Count the enquiries your team answers each week that a customer could have answered themselves, multiply by the time each one takes, and put a cost on it. A letting agent fielding two hundred maintenance chases a month is usually well past the threshold. A firm with eleven clients who each ring twice a year almost certainly is not. We will do that sum with you on the first call, and we have talked people out of portals on the strength of it.
Can the portal read and write to the system we already keep records in?
Usually, and that is normally the whole point. If your records live in a system with a documented API such as Sage, Xero, a practice management system or a property management platform, we connect to it so the portal shows one version of the truth rather than a second copy that drifts. Where no API exists we look at scheduled exports, a database view, or a small adapter service. The awkward case is a system whose vendor charges heavily for API access, and that cost belongs in the business case before you start.
What does WCAG 2.2 AA actually require us to do?
In practice it means the whole portal can be operated with a keyboard alone, every form field has a label a screen reader announces, text contrast meets a measured ratio rather than a designer opinion, focus is always visible, error messages say what to fix rather than that something is wrong, and nothing important is conveyed by colour alone. If you sell to a council, an NHS trust or a university, the public sector accessibility regulations also require a published accessibility statement, and procurement will ask for it. We build to that standard by default and test with a keyboard and a screen reader before launch.
Some of our customers use very old computers. Is that a problem?
It is a constraint rather than a problem, provided you tell us early. We agree a named browser list at scoping and test against it, and we will be blunt about the cost of anything unusual on it. Older managed desktops in the public sector and in large corporate estates are the common case, and the practical effect is that we avoid the newest browser features, keep the interface working without heavy client-side rendering, and check the awkward combinations by hand rather than assuming.
Can different customers see different things without building separate portals?
Yes, and that is far cheaper than separate builds. One application with a permission model lets a tenant see their own tenancy, a landlord see their properties, a contractor see only the jobs assigned to them and your staff see everything. The work is in defining those rules precisely, which we do as a written permissions map before any screens are designed, because retrofitting roles into a portal built without them is one of the more expensive rewrites we get asked to do.
Where will the data live, and can we keep it in the UK?
Yes. We deploy into UK or EU regions where you want that, and we write down where every category of personal data is stored, how long it is kept and how a subject access or deletion request is serviced. Those are architecture decisions under UK GDPR and the Data Protection Act 2018, so we settle them before the schema is written rather than answering them for the first time when your first request arrives. We will sign a data processing agreement.
What happens if the portal goes down on a Saturday?
You get told before your customers tell you. We put uptime and error monitoring on every application we launch, with alerts going to a named route rather than a shared inbox nobody watches at the weekend. What we will not claim is round-the-clock cover from a team working Indian Standard Time. A support retainer defines the response window honestly, and for anything where a Saturday outage genuinely costs you money we agree that window in writing before launch rather than afterwards.
What Usually Sits Either Side of a Portal
Backend & Integrations
The connections to Sage, Xero or your existing platform that make a portal show one version of the truth.
Learn moreSaaS Products
When the portal is the product and other companies pay a subscription to use it.
Learn moreMVP Development
If the portal is a new commercial idea rather than a fix for an existing operation, start here.
Learn moreSend Us a Week of Your Enquiries
Genuinely — the questions your team answered this week. We will tell you which of them a portal removes, what that portal costs in sterling excluding VAT, and whether it is worth building at all. Reply within two working days.