A material study in bright daylight. A thick rope of clear turquoise glass strands arches over like a doorway, wound once with a pearl silver band, its feet planted in a rippled pale floor with a second arch continuing off frame.
  1. Home
  2. Services
  3. Web applications and portals

One of the eight services

Web applicationsand portals.

A web application is software built for one business's way of working. A portal is the part of it a customer signs into to answer their own question.

Four things a customer used to phone about, answered at nine at night. One of them still needs you, and the system says which.

Book a discovery call Request a performance audit

Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit.

HUREAL / Material studies

Block 02

Soundslike this?

  1. The phone rings all day with questions that already have an answer in a system.

  2. Somebody spends every morning telling customers where their order is.

  3. Booking happens by callback, and the callback is the bottleneck.

  4. The process that matters most runs on a spreadsheet, a shared inbox and one person's memory.

  5. When that person is away, the process waits.

  6. Documents go back and forth by email and nobody can say which version is current.

  7. Leadership asks for the same five numbers every Monday, and somebody builds them by hand.

If what you recognise is two systems that should be telling each other the truth rather than a customer who should be able to look something up, Integrations and Data is the page for that.

Block 03

What this is,in plain language.

What happens today

A customer wants to know where their order is. They phone at 10:40, somebody looks it up in two screens, reads out a date, and puts the phone down. Forty seconds of work and four minutes of interruption, eleven times before lunch.

Meanwhile the quoting process, the one the business is actually good at, lives in a spreadsheet, a shared inbox and one person's head. It works, because people make it work. That is not a failure of organization, it is what a process looks like before anyone has had a reason to write it down, and it holds until volume grows or until the person who carries it takes a week off.

What happens after

The customer signs in at nine at night and sees their own orders, their own documents, their own invoices and their own appointments, read from the system that owns them rather than from a copy somebody maintains. They book against real availability, with your buffers and your rules, and reschedule inside your policy without asking permission.

The quoting process becomes a system with the same steps, the same rules and the same approvals, including the exceptions, because the exceptions were mapped rather than discovered. Everything the rules do not cover still waits for a person, with the file attached and the reason shown, which is exactly where it should wait.

A portal that shows a copy is a second thing to keep up to date. A portal that reads the system of record gives the same answer your team would give, at nine at night.

That is the line between a project that removes work and a project that adds it. The moment the portal has its own version of the truth, somebody has to reconcile two versions, customers learn that the screen is sometimes wrong, and they go back to phoning, which was the thing the build was supposed to stop.

Both sides get built, always. The customer side fails without the staff side: a booking that lands in a calendar nobody controls, a document upload with no queue behind it, and an exception with nowhere to go are three ways to make a busy office busier.

Block 04

Who this is for,and who it is not for.

Where this pays for itself

  • The phone rings with questions that already have an answer in a system. Status, dates, documents, balances, appointments. The answer is fast; the interruption is not.
  • The relationship continues: appointments, matters, orders, tenancies, maintenance plans, anything where the same customer comes back.
  • There is a quoting, configuration or application process no product handles, and it is close to the thing the business is actually good at.
  • Approvals and multi-step work run on email, so the status of anything is a question rather than a screen.
  • Data sits in three systems and a person reconciles it by hand before anyone can answer a simple question.
  • Multiple locations or branches, where head office needs one consistent view and each site needs its own.
  • The same five numbers get assembled by hand every Monday and are out of date by Tuesday.

You probably do not need this if

  • There is no system of record. A portal reads from something true. Where the truth is a spreadsheet updated on Fridays, the first project is the system behind the portal, and it is a different job.
  • A standard product does it and the objection is the licence fee. Over three years a build usually costs more than the subscription. Where that is the arithmetic, we will say so and help you configure the product instead.
  • The process is still being argued about. A build freezes a process. Where two people in the room would describe it differently, the first work is agreeing it, and that is a much shorter engagement.
  • The volume is small. The arithmetic for a portal is the contacts it removes. Below a certain number of customers signing in, the phone is cheaper, warmer and better, and we will run that number with you before anyone designs anything.
  • Adoption has no owner. A portal gets used because somebody tells customers it exists and keeps telling them, in the confirmation email, on the invoice, on the phone. Where that job has no name against it, the usage curve stays flat and the build does not pay back.
  • The requirement is a dashboard and the sources disagree with each other. Then the first project is deciding which system is right about what, which is Integrations and Data, and a dashboard built before that argument is settled just publishes the disagreement.

Where the product you already pay for can do this, that is the recommendation, and we will help you turn it on rather than quote you for a build.

Block 05

What itincludes.

Sixteen capabilities, what each one does in plain words, and what it changes for the business. Nothing here is a category name standing in for work.

Web applications and portals, the capability table
Capability What it does What it changes
Before anything is builtThe arithmetic and the build-or-buy question
Counting the questions What customers contact you about, how often, and which system holds each answer. The business case is arithmetic before it is a build.
The build-or-buy requirement The requirement a standard product cannot meet, named and given a value, in writing. If we cannot name one, we recommend the product, and that recommendation is free.
Custom web applications Sub-service
Process mapping Sessions with the people who actually run the process, including the exceptions and the workarounds they invented. The exceptions get built in rather than discovered in month two.
The application Forms, workflow, rules, approvals, notifications, records and search, shaped to the task rather than to the database underneath it. The process stops depending on one person's memory.
Roles, permissions and the audit trail Who can see what, who can do what, and a readable record of who did. A question about what happened has an answer.
Customer portals and booking systems Sub-service
Accounts and sign-in Creation, recovery and security appropriate to what the account actually holds. A customer gets in without a phone call, and only ever to their own record.
The record view Orders, appointments, files, invoices, status and history, read from the system of record rather than from a copy. What the customer sees is true.
Booking against real availability Buffers, resources, staff rules, rescheduling and cancellation that respect your policies rather than ignoring them. The slot is real at the moment they take it.
Document exchange and intake Both directions, with permissions, versions and a record, and forms completed before the visit rather than in the waiting room. The email thread with the attachments stops.
Reminders and confirmations Email and text, in the customer's language, tied to real events rather than to a schedule somebody maintains. Fewer missed appointments, and fewer calls asking to confirm one.
Dashboards and business reporting Sub-service
The question list What leadership asks weekly and monthly, in their words, with the decision each answer drives. The screen answers questions instead of displaying data.
Metric definitions What counts as a lead, an order, a completed job, an active customer, written down and agreed. Two people stop meaning two things by one word, which usually settles an argument that predates the project.
Exceptions, alerts and the scheduled brief What is late, what is at risk and what changed, sent before the meeting rather than found during it. The Monday report is assembled before Monday.
What every build carriesWhatever else is in the scope
The staff side Calendars, exceptions, waitlists, overrides and the screen your team actually works in all day. The customer side does not succeed by making the staff side worse.
Your accounts, monitored Hosting in your own cloud accounts, with monitoring, backups and a restore that has actually been performed rather than configured. A bad day has a tested answer.
Privacy design, documented Scoped access, retention per record type, logging, and consent where it applies, written for your privacy officer. Your privacy officer has something to read on the day they ask for it.

Scroll the table sideways to read it.

Block 06

How itworks.

Four things a customer used to phone about, at nine at night. One of them still needs you, and the drawing says which.

Scroll the drawing sideways to read it.

The struck channel on the left is the only thing on the board that is being removed. Everything else is being connected.

What the system does

The work, the path it takes, and everything HUREAL builds. It never means anything else.

What stays with a person

The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.

What you already run

Present, named, and not for sale. The lowest contrast on the board, deliberately.

  1. It is nine at night and they want one of four things.

    To check a status, to upload a document, to book a slot, or to pay an invoice. Those four are not a guess: they are what the counting exercise in phase one nearly always finds at the top of the list, and the build is scoped to the ones your own tally actually shows.

  2. One login, and your rules decide what they see.

    Not a second system with its own idea of who somebody is. One account, scoped so a customer reaches their own record and nothing else, with security appropriate to what the record holds rather than security borrowed from a template.

  3. The portal reads and writes where the truth already lives.

    Orders, documents, the schedule, accounts. It reads from the system that owns each one and writes back to it. This is the whole design decision on this service: the portal never becomes a second copy that somebody has to reconcile.

  4. The phone call stops.

    The struck channel in the drawing is the four calls a day that no longer happen. It is drawn and then broken, rather than left out, because the thing being removed is the reason for the project and a drawing that omits it is a drawing of a feature.

  5. Anything outside the rules waits for you, with the file attached.

    The exception, the argument, the unusual request, the thing the policy did not anticipate. It stops at the line, in a queue your team actually works in, with the context already gathered. That is not the system failing. It is the system knowing the difference.

You can do the first step of this yourself, this week, for nothing. Ask whoever answers the phone to keep a tally for five working days: what was the question, and which system held the answer. Most offices are surprised by their own list, and it is the single most useful thing you can bring to a discovery call. If the tally is short, that is an answer too, and it is the one that saves you a build.

Book a discovery call

Block 07

What youend up with.

  • The contact tally, and the arithmetic on it

    What customers contact you about, how often, which system holds each answer, and what the interruption is worth.

  • The process map

    The process drawn end to end with the people who run it named against each step, including the exceptions and the workarounds.

  • The build-or-buy requirement, in writing

    The thing a standard product cannot do, with a value against it, or our recommendation to buy the product instead.

  • The account design

    What a customer can see, do and change, what needs a person, and who can see what.

  • The portal, in your accounts

    Running in your own cloud accounts, under your admin access, from the first commit.

  • The staff side

    The calendar, the queue, the exceptions, the waitlist and the overrides, designed as a screen somebody works in all day rather than as an afterthought.

  • The connection to the system of record

    Built, validated during scoping, documented per connection, in the direction agreed.

  • The pilot record

    Real customers, real work, run in parallel with the old process, with the numbers that said it was safe to cut over.

  • The privacy design document

    Scoped access, retention per record type, logging and consent, written for your privacy officer.

  • The measurement

    How many contacts the portal handled, how many it handed over, and which questions are still arriving by phone.

V3. One account, at nine at night

your-company/portal/account Thursday, 21:14

What they can answer without you

Read from the systems that own it. One row still needs a person, and it says so.

  • 21:14

    Checked an order placed last week.

    The portalShowed the status and the date, read from the system that owns it, with the time it was last true.

  • 21:15

    Uploaded a document.

    The portalFiled it against the record, with a version and a receipt, and put it in your team's queue for the morning.

  • 21:16

    Moved an appointment from Tuesday to Thursday.

    The portalApplied your buffer and your notice rule, took the slot, released the old one, and sent the confirmation.

  • 21:17

    Paid an invoice.

    The portalTook the payment, marked the invoice, and wrote the reference back to accounting.

  • 21:18

    Asked to change the terms on their account.

    HeldTerms are on your side of the line. Logged the request, attached the account, and put it in front of a person for the morning.

  • 21:19

    Asked a question the rules do not cover.

    HeldGathered the file, the history and the question in one place, so whoever picks it up starts with everything rather than with an email.

Two of the six rows are the system declining to act, and they are the reason this is a deliverable rather than a feature list. A portal that answers everything is a portal that is guessing at something, and the customer finds out which one on the day it matters.

On every HUREAL engagement, whichever of the eight it is

  1. A written scope with a fixed price and a timeline, before any code.
  2. The working build, reviewed at every phase, in your own accounts.
  3. Full ownership of the code, the content and the data, with admin access from day one.
  4. A named contact who is accountable for the work.

Block 08

How anengagement runs.

Five phases. You can stop after any of them, and every one produces a document you own.

  1. 01

    Discovery call

    A discovery call with the people who own the outcome and the people who answer the phone. We count the contacts, map the process including its exceptions, agree what a customer can do for themselves and what has to wait for a person, and name the requirement that justifies building rather than buying.

    How long
    One call. The written proposal follows it.
    Your people
    Whoever owns the process, plus whoever answers the phone all day.
    You end up with
    A written proposal: a scope, a price and a timeline you can sign or walk away from. Yours either way.
  2. 02

    Design

    The account, the data model and the permissions first: what a customer can see, do and change, and who internally can see what. Then the interface for each role, designed around the task rather than around the database, and reviewed with the people who will actually use it.

    How long
    Set in the signed proposal.
    Your people
    One approver per role, plus a real user of each screen.
    You end up with
    The account design, the permissions written down, and the screens for both sides reviewed by the people who will work in them.
  3. 03

    Build

    The core path first, working and usable, then the surrounding cases. Built in slices against the real system of record rather than against samples, in your own cloud accounts, under your admin access, from the first commit.

    How long
    Set in the signed proposal, with the review schedule agreed in it.
    Your people
    One reviewer per review, plus whoever owns the system of record.
    You end up with
    Working software at every review, reading and writing real records from the first one.
  4. 04

    Launch

    A pilot first: a subset of real customers doing real work, with the phone line still open and the old process running in parallel, until the numbers hold. Then the same fourteen published checks every HUREAL build passes, then cut over.

    How long
    A pilot of the length agreed in the proposal, then the checklist against the finished build.
    Your people
    The team that will work the queue, plus an admin sign-in before launch day.
    You end up with
    A pilot record showing it worked before you depended on it, and a launch record against fourteen named checks.
  5. 05

    Run

    Adoption work, because a portal is used when people are told it exists, plus reporting on how many contacts it actually handled and which questions are still arriving by phone. Monthly, and cancellable.

    How long
    Monthly, for as long as you want it. Cancellable at any time.
    Your people
    One read of the monthly report and one call to pick what changes next.
    You end up with
    A written report: what the portal handled, what it handed over, what changed, and what did not work.

What makes it longer: how many systems the portal has to read from and write to, how old and how locked down those systems are, how many roles need their own screen, how many exceptions the process really has, and how long you want the pilot to run alongside the old way. What does not make it longer: how many customers will eventually use it. The second role and the second workflow are faster than the first every time, because the account, the permissions and the connections are already built.

Read the whole method, including the fourteen launch checks

Block 09

What itconnects to.

By category, because the category is the question. The first real objection is whether this works with what you already run, and the honest answer is a list plus a qualifier, not a wall of logos.

  • Your system of record

    The one system that is the truth about the thing the customer is asking about. Usually the one that matters most and the one nobody else connects to.

    practice management, dispatch, estimating, case management, property management

  • ERP and accounting

    Where the order, the invoice, the balance and the credit note are true.

    NetSuite, SAP Business One, Sage, QuickBooks, Xero

  • CRM

    Where the relationship, the owner and the history live.

    Salesforce, HubSpot, Zoho, Dynamics

  • Scheduling and calendars

    Where a slot is held, moved or released, and where your staff's real availability is.

    Microsoft 365, Google Workspace, an in-house dispatch board

  • Identity and sign-in

    How a customer proves they are themselves, at a strength that matches what the account holds.

    email and passcode, Microsoft or Google sign-in, multi-factor where the record warrants it

  • Payments

    Where an invoice, a deposit or a plan payment is taken.

    Moneris, Stripe, Square, pre-authorized debit

  • Documents and storage

    Where the files the customer is exchanging actually live, with their versions and their permissions.

    SharePoint, Google Drive, Dropbox, a document management system

  • Messaging and notifications

    Where the reminder, the confirmation and the "something needs you" alert go out.

    email, SMS, and the reminder that has to arrive in the customer's language

  • Your own database

    Where a system has no interface to connect to, the connection is built rather than assumed.

    read-only views, scheduled exports, a purpose-built interface

Every connection is validated by HUREAL's engineers during scoping and confirmed in writing before signature. Where a system genuinely cannot be connected, you hear it during discovery rather than during the build, and the scope is drawn around it instead of making a platform migration the price of entry.

Block 10

What we do,and what we will not do.

What we do

  • Count the contacts firstThe business case is arithmetic. What was asked, how often, and which system held the answer.
  • Read the system of recordThe portal shows the truth, on a connection built and validated during scoping.
  • Build both sidesThe customer experience and the staff screen, because one fails without the other.
  • Pilot before you depend on itReal customers, real work, the phone line still open, the old process still running.
  • Design for the customer who will never sign inThey are not going away and they should not get a worse service.
  • Write down who can see whatRoles, permissions, retention and logging, in a document your privacy officer can read.
  • Put it in your accountsHosting, repository and data in your name, with your admin access from the first commit.

What we will not do

  • Build a portal on top of a copyA screen showing yesterday's answer creates a second thing to maintain and a customer who trusts neither. Where there is no system of record, the first project is the system.
  • Build what you can buyName the requirement a standard product cannot meet. If we cannot, we recommend the product and help you configure it, and that recommendation is free.
  • Make the phone worse for the people who will never use itThe portal is a second door, not a replacement for the first one.
  • Put health information anywhere the storage region and the handling are not settledWhere they are not settled, the work is scoped to exclude it rather than scoped around it.
  • Cut over on a weekend and find out on MondayThe pilot runs in parallel until the numbers hold. If they do not hold, the cutover moves.
  • Certify your complianceWe design to the standard, test against it, and document what we built. The determination belongs to your counsel or your privacy officer.
  • Hold your passwordsAccounts are opened in your name and we work under our own access, which you can revoke.

The second one is the expensive commitment. Naming the requirement that justifies a build is the first thing we do and the thing most likely to end the conversation, because a lot of processes are genuinely well served by a product somebody else maintains. We would rather lose that project in week one than deliver it in month six.

Block 11

The portal you already have, a packaged one,or a built one.

Three ways to let a customer answer their own question. The first one is already paid for, and it is the one most likely to be the right answer.

The three approaches, on ten deciding factors
Deciding factor The portal your system already shipsIncluded A packaged portal or booking productSubscribed A portal built to your processBuilt
What you are buying A module of something you already licence. A product that does one job for many businesses. A system shaped to one business's rules and one business's exceptions.
Cost to start Nothing, or close to it. Low, and per user or per location after that. Highest. It is a build.
Cost to keep Included in what you already pay. A subscription that grows with use. Hosting, plus the monthly arrangement if you want one. Both declinable.
Connection to the system of record Already connected. This is its single biggest advantage and it is a large one. A connector if one exists, an export if not. Built and validated during scoping, in the direction you chose.
How much of your process it can express Whatever the vendor built, for everyone. Whatever the product models, configured. Yours, including the exceptions, which are usually the point.
Booking rules: buffers, resources, multiple staff Usually simple. Sometimes exactly enough. Usually good, if your rules look like the rules it models. Whatever your rules actually are, including the ones nobody wrote down.
Documents both ways, with versions and a record Sometimes. Sometimes, and often as an add-on. Yes, with permissions and an audit trail.
What it looks like to your customer The vendor's, with your logo if you are lucky. The vendor's, themed. Yours.
Who maintains it The vendor. A real advantage, and it costs you nothing. The vendor. You own it. We document it for a developer who has never met us.
When the vendor changes it You find out when your customers do. Same. It does not change unless you change it.
When it is the right answer It covers the questions your tally actually shows, and it is already connected. Booking, and only booking, with no account, no documents and no exceptions. The process has rules a product cannot express, the answer comes from more than one system, and the exceptions are the point.

The verdict, including where it goes against us

If the system you already run ships a portal, turn it on before you talk to anybody. It is already connected to the truth, which is the hardest and most expensive part of this entire project. It costs nothing more. Somebody else maintains it. Compare it against the tally from the counting exercise: if it covers the questions that are actually arriving, you are finished, and we will help you configure it and send you an invoice for nothing.

If the requirement is booking and only booking, buy the packaged product. No account, no documents, no exceptions, no unusual rules: a subscription does that well for a monthly fee, and building it would be us charging you for a problem that is solved. This is the second place the table goes against us and it is the more common of the two.

A built portal earns its cost in a specific place, and it is worth naming exactly: your process has rules a product cannot express, the answer a customer needs comes from more than one system, the exceptions are the interesting part rather than the rare part, and the portal has to be the staff tool as well as the customer one. That is the whole case. The counting exercise is where we find out whether your project is in it, and you can run the counting exercise yourself before you call anyone.

Block 12

What a Canadian buildhas to be designed around.

A portal holds records about identifiable people and lets them reach those records from anywhere, which is a different set of obligations from a public website. These are the requirements this service is designed around, and the line between what we build and what your counsel or your privacy officer decides.

  • PrivacyPIPEDA, Quebec's Law 25, and the provincial private-sector statutes where they apply

    What we design forA stated purpose for every record the portal exposes, access scoped so an account reaches its own record and nothing adjacent, sign-in strength matched to what the record holds, consent captured where it is required rather than assumed, and every read and write of a personal record logged.

    What we document for your counselWhat the portal exposes, to whom, under which rule, where it is stored, which processors see it, and how long each record type is kept.

  • Health informationWhere the work touches it at all

    What we design forNo health information in the portal until the storage region and the handling are settled, and where they are not settled the workflow is scoped to exclude it rather than scoped around it. Booking and account work that touches no health information is a different question and a normal build.

    What we document for your counselWhich data classes were excluded and why, so the boundary is something your privacy officer reads rather than infers.

  • Records and retentionIncluding the obligations your own sector carries

    What we design forRetention set per record type rather than left at a default, deletion and archival that are designed rather than improvised, an export that produces a readable record, and a log that survives the record it describes.

    What we document for your counselThe retention schedule per record type and where each one is enforced, so your counsel or your regulator is reviewing a schedule rather than a screen.

  • AccessibilityWCAG 2.2 AA, plus AODA and the provincial equivalents, and the Accessible Canada Act where it applies

    What we design forBoth sides. The customer surface, because a portal a person cannot use is a service they cannot reach, and the staff surface, because it is the screen somebody works in for eight hours. Keyboard, screen reader, contrast and reduced motion, tested rather than asserted, including every error and empty state.

    What we document for your counselThe test results per surface and the standard tested against, so a barrier report can be answered with a measurement.

  • Electronic messagesCASL, for the reminders, confirmations and anything commercial

    What we design forA clear separation between the message that confirms something a customer asked for and the message that is selling something else, consent and its basis recorded against the record, no pre-ticked boxes, and an unsubscribe on commercial messages that works in one action.

    What we document for your counselThe consent basis per contact, the send log, and the classification we built against, so the determination is theirs to confirm rather than ours to assert.

  • LanguageQuebec's Charter of the French Language, where the business operates there

    What we design forThe portal, the booking flow, the reminders, the confirmations and the error states authored per language rather than translated at the end, because these are the surfaces a customer meets when something has gone wrong.

    What we document for your counselWhich surfaces are authored per language and which are not yet, so the gap is a list somebody owns rather than a surprise.

  • Where the data livesAnd which processor sees it

    What we design forThe hosting region, the messaging processor, the payment processor and the backup location named in the scope before the build, chosen rather than inherited from whatever a vendor defaults to.

    What we document for your counselEach processor, what it sees, the region it sees it in, and what changes if you move region later.

HUREAL designs to a standard, tests against it, and documents what was built. The determination is your counsel's or your privacy officer's to make, and a vendor offering to make it for them is offering something they do not have. Our own conformance target and how to report a barrier are on the accessibility page.

Block 13

Questions peopleactually ask.

  • Will our customers actually use it?

    Some will immediately, and adoption grows when the portal is genuinely faster than phoning. We design for that and we measure it. We also design what happens for the customers who will never use it, because they are not going away and they should not get a worse service than they had before.

  • Our data is sensitive. Is a portal safe?

    Sensitive data is the reason this should be designed rather than added on. Scoped access, sign-in strength matched to what the record holds, encryption, logging, retention rules and consent are requirements from the first session, and we document what we built so your privacy officer or your counsel can review it. That determination is theirs.

  • Can it connect to our practice management or ERP system?

    Most modern systems can be connected and some are much harder than others. We check the specific system by name and version during discovery and tell you what is involved before it becomes your problem. Older and locked-down systems are where the surprises live, so we look at those first.

  • How do we know a custom build is justified?

    Name one requirement a standard product cannot meet, and put a number on why it matters. If you and we can do that together, the build is justified. If we cannot, we will recommend the product and help you configure it, and that recommendation costs you nothing.

  • What if our process changes after launch?

    It will. The build separates the rules from the code wherever it can, so thresholds, steps, notice periods and approvals are changed by your admin rather than by a developer. What is left is handled in the monthly improvement work, and it is not an emergency either way.

  • What about customers who will never sign in?

    They keep phoning, and the person who answers has a better day because the other calls stopped. Nothing about this build removes a channel. It removes a category of question from a channel, and the design explicitly includes what happens for everyone who still prefers the phone.

  • What does it cost?

    The build price is set after the discovery call and sent in a written proposal, because an honest number needs the scope. Fixed scope, fixed price, fixed timeline, agreed before any code. Not hourly, and not a range that moves once work starts.

  • How do we check that you can actually do this?

    Four ways, all of them before you sign anything. The method is published phase by phase. The fourteen launch checks are published by name. This page is the sample: open it on a mid-range phone, tab through it with a keyboard, turn on reduced motion. And phase one produces a written scope, price and timeline that is yours whether or not you continue.

  • Who owns it, and could somebody else maintain it?

    You own it, in your own accounts, with documentation written for a developer who has never met us. We build on mainstream, well documented technology for exactly that reason. Being difficult to replace is not a business model we are interested in.

  • Our data is messy. Is a dashboard premature?

    Messy is normal and the mapping stage finds it. Some questions can be answered today, some need a source fixed first, and you get told which is which before you commit. Waiting for clean data is how companies wait for years.

  • Do we need a data warehouse?

    Sometimes. With a handful of sources and modest history, direct connections are simpler and cheaper. With many sources, real history, or sources that change, storage pays for itself. The recommendation comes with its reasoning and its cost, and staying without one is a legitimate outcome.

  • What happens if it goes down at nine at night?

    Monitoring alerts a named person rather than a shared inbox, backups are taken and a restore has actually been performed before launch rather than configured and assumed, and the recovery plan is written down. The old channel still exists, which is the other reason the phone line is never closed on launch day.

Block 14

Three servicesnext to this one.

Block 15

Where thismatters most.

Four sectors, and the reason in each

  • Healthcare and clinics

    Booking, rescheduling, reminders and intake completed before the visit rather than on a clipboard in the waiting room. Named here with a limit: anything touching health information is only in scope once the storage region and the handling are settled, and where they are not, the work is scoped to exclude it and that boundary is written into the scope.

  • Professional services

    Matters, files and documents, exchanged in a system with a record instead of in an email thread where nobody can say which version is current. The status question is the one that arrives most, and it is the one with an answer already sitting in a system.

  • Manufacturing and distribution

    Order status, shipping dates and account documents are three systems and one phone call. The call is the part the portal removes. The account price and the credit decision are the parts that stay behind the line.

  • Real estate and property

    Tenants, owners and buyers all want different things from the same records: documents, statements, maintenance requests and dates. One portal with three kinds of account is a normal shape here, and the permissions are the hard part rather than the screens.

Read on this topic

Every article about this service lives under one index, so a reader who wants depth has one place to go rather than a tag cloud.

The web applications and portals index

Everything we have published on this

Block 16

Two ways to start.Both end with a document you own.

Book a discovery call

For when you know which questions are costing you. A discovery call with the people who own the outcome and the people who answer the phone. We count the contacts, map the process with its exceptions, agree what a customer can do for themselves and what has to wait for a person, and list the systems involved. Afterwards you get a written proposal: a scope, a price and a timeline you can sign or walk away from.

Book a discovery call

Request a performance audit

For when you want the evidence before the decision. We look at what you have against the job you want it to do, and give you a prioritised plan with the arithmetic attached. The document is yours either way.

Request a performance audit

Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit. If neither is right for you, we will say so, and tell you what is.

Not ready for either? Talk to the demonstration in your browser for three minutes, or paste your own address and hear it answer as your business. No form and no booking, and the transcript arrives by email a minute later.

Hear it work

What every HUREAL engagement commits to, in writing

  • A fixed scope, price and timeline, agreed before any code is written.
  • A working build, reviewed at every phase, running in your own accounts.
  • Full ownership of the code, the content and the data, with admin access from day one.
  • A named contact who is accountable for the work.
A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Their own answers at nine at night, and yours when it matters.

HUREAL / Material studies