Services
We build customer, partner, tenant and staff portals, and CRM systems whose record model matches how your organisation actually holds relationships — by site, by contract, by property, by matter — rather than by the account and opportunity objects a licensed platform imposes.
Most of this work replaces a heavily customised platform, a portal a marketing agency built on a CMS, or an email inbox performing the role of a queue.
When you need this
What we build
Our approach
Before any interface work, we produce a table listing every material field, which system owns it, which systems may read it, and what happens on conflict. Portal and CRM projects fail more often on ambiguous ownership than on technology: two systems both believing they own an address is how customers get letters at a property they left last year.
Prototypes are populated with a copy of your data, anonymised where necessary, not with invented sample rows. A screen that looks clean with three tidy records and unusable with four hundred messy ones is a design that has not been tested. This surfaces data quality problems while there is still budget to fix them.
Staff identity flows through your existing provider — Entra ID, Okta or Google Workspace — using OIDC or SAML with group-derived roles. External users sit in a separate pool with their own lifecycle. Portal accounts are scoped to the specific records they may see, and that scoping is enforced at the data layer, not just hidden in the interface.
Migration is planned, rehearsed at least twice against production volumes, and reconciled entity by entity with a report you sign off. Cutover has a written rollback point. We assume the legacy data is worse than anyone believes, because it usually is.
We instrument the system so you can see which screens are used, which queues are growing and where users abandon a task. In the first eight weeks after launch that data drives a short, funded change list rather than an argument about whether people are using it properly.
Technology
Backend
Frontend
Identity
Data and platform
Applied by industry
Patient portals for appointment booking, recall response and treatment plan acceptance, synchronised with EMIS Web, SystmOne or Dentally and scoped so a portal account can only ever reach its own record.
Customer and broker portals covering consumption, meter reads, contract renewal and switching status, fed from supplier APIs and settlement data rather than nightly CSV files.
Franchisee and supplier portals for ordering, compliance documentation and performance reporting, with EPOS sales data driving the figures each site sees.
Landlord and tenant portals covering rent statements, compliance certificates, maintenance requests and job status, integrated with Reapit or Alto and portal listing feeds.
Client collaboration portals for matter status, secure document exchange and fee estimates, connected to the practice management and time recording systems already in use.
Typical engagement
Questions
Usually you should configure. We are engaged at the point where the configuration itself has become the problem: hundreds of custom objects, flows nobody can trace, per-seat licensing on staff who use one screen, and a release process that depends on one contractor. When the platform is being used as a database with an unhelpful interface on top, a purpose-built system is often cheaper over five years.
Yes, and this is the most common shape. Sales keeps Salesforce or Dynamics; operations gets a purpose-built system for the work the platform models badly; the two synchronise through an integration layer with a defined system of record per field. We document that field-level ownership before any code is written.
Staff authenticate through Microsoft Entra ID or your existing identity provider via OIDC or SAML. External users — customers, partners, tenants, patients — go into a separate identity pool with their own registration, verification and multi-factor policy, so a portal user can never be granted an internal role by mistake.
Migration runs as its own workstream with a written mapping, at least two rehearsal runs against production-like volumes, and a reconciliation report per entity. We expect to find duplicate accounts, orphaned contacts and fields used for three different purposes; the rehearsal exists so you decide what to do about them before cutover, not during it.
For the areas where change is frequent — statuses, pick lists, form fields, notification rules, permission sets — we build configuration into the product with an admin interface and an audit trail. Structural changes to the domain model remain engineering work, and we say clearly at design time which is which.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us