A material study photographed in bright daylight. One slender pleated element of clear turquoise glass stands alone on a pale reflective floor to the right of centre, no taller than a hand span, a pearl silver ribbon wrapped once around its waist and a long reflection beneath it. The left of the frame is empty pale mint.
  1. Home
  2. Services
  3. Mobile products

One of the eight services

Mobileproducts.

A mobile product is an app built around one valuable action somebody takes often, on a phone they already carry, using the things a browser tab cannot reach.

Whether the app earns its place is decided with your own numbers, before anything is designed.

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 same accounts order the same things every week, and every order still starts with a phone call.

  2. Our crews work off printed sheets and ring the office to find out what changed this morning.

  3. Somebody photographs a job on their own phone and emails the pictures in at the end of the day.

  4. Our repeat customers reach us through a marketplace, and we pay for that relationship every time they use it.

  5. Two of our biggest accounts have asked us for an app, and we do not know whether anyone would open it twice.

  6. We have an app, and changing a price in it means waiting for a release.

  7. The work happens in basements and rural yards, where there is no signal for most of the day.

If none of those is familiar, what you are describing is more likely something a customer would do from a browser at nine at night, and Web Applications and Portals is the page for that.

Block 03

What this is,in plain language.

What happens today

A customer who buys from you forty times a year finds you the same way each time: a search, a saved email, a phone call, or an app that belongs to somebody else and charges you for the introduction. Each order is a small negotiation with a browser.

The field version is the same shape. A technician carries a sheet of paper, rings the office twice, photographs the work on a personal phone, and types it all in on Friday. The information exists all day and arrives at the end of it.

What happens after

The action lives on the home screen. The customer is already signed in, the app remembers what they ordered last time, and the thing they came to do takes seconds rather than a browser session. When there is a reason to come back, the app can say so, once.

In the field, the job is on the device, the photographs attach themselves to it, the signature is captured where the work happened, and it all syncs when there is signal. The office finds out at eleven, not at six.

Frequency times value times convenience. A zero in any of the three is a zero.

How often the action happens, what it is worth each time, and how much easier the app makes it. That arithmetic is run with your numbers in the first session, because it is the only honest way to decide whether an app earns its place, and it is also the fastest way to find out that it does not. Some of the strongest mobile products never appear in a public store at all: they are the tools a field crew, a warehouse team or a sales force uses every day, and those usually pay back first.

An app has five things a browser tab does not: a place on the home screen, an identity that persists, memory of what happened last time, access to the camera, location and wallet, and a voice through notifications. Every mobile product worth building uses at least two of them, and the value test is really a question about which two.

Block 04

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

Where this pays for itself

  • The customer action happens weekly or more, and it is the same action: ordering, booking, reordering, checking.
  • Accounts reorder on negotiated pricing, and the price is the reason they phone rather than the reason they do not.
  • Repeat buying already exists and the relationship is currently rented from a marketplace.
  • People work away from a desk: technicians, drivers, inspectors, crews, merchandisers.
  • The task needs the phone itself, for the camera, the scanner, location, the wallet, or an offline stretch.
  • The visit is the moment that matters, which is the shape of membership, loyalty and service businesses.

You probably do not need this if

  • Every requirement is see information and maybe fill in a form. That is a website, it costs a fraction of this, and more people will use it because nobody has to install anything.
  • The action happens once or twice a year. An icon nobody taps for eight months is an icon that gets deleted when the phone runs out of room.
  • The reason is that competitors have one. There is no action in that sentence to build around, and the value test has nothing to score.
  • Nobody will own it after launch. Both platforms change their operating systems and their policies on a schedule that is not yours, so an unmaintained app degrades whether or not anybody touches it.
  • It is for five internal people once a month. A web application reaches them on any device, needs no store, and can be changed on a Tuesday afternoon.

Most businesses need a better website before they need an app. If that is you, we will say so, and we will build the website.

Block 05

What itincludes.

Fifteen capabilities, what each one does in plain words, and what it changes for the business. The three groups are the stages of one build rather than three products, and none of them is a link, because the pages beneath this service have not been written yet and a heading that promises one is a heading that lies.

Mobile products, the capability table
Capability What it does What it changes
Decide whether to build itBefore anything is designed
The value test Frequency, value and convenience, sized with your own numbers rather than with an industry average. You find out whether the app earns its place while it still costs a conversation.
The one action The single thing the product exists to make faster, named, with everything else ranked behind it. A first release that is finished for one job instead of rough at five.
The platform decision Native or cross-platform, decided on the product's requirements, with the reasoning written down. The choice can be defended to a developer who joins in two years.
Build the productThe app, the server side, and the connections
Design for both platforms Each platform's conventions where they matter to the person using it, one product where they do not. It behaves like it belongs on the phone it is on.
The core path The fastest honest route to the action, counted in taps rather than in screens. The thing they came for takes seconds, which is the whole reason the app stays installed.
Accounts and sign-in An identity that persists, with a face or a fingerprint where the phone offers one. Nobody retypes a password to place the order they place every week.
Notification rules Which events are worth a message, who receives them, when they are allowed to fire, and what a person can switch off. The app stays welcome, which is the only condition under which it stays on the phone.
Offline and synchronization The work continues with no signal, and reconciles safely when signal returns. A basement, a rural yard or a lift does not stop the job being recorded.
Camera, scanning and location The phone's own hardware, used where the task calls for it and left alone where it does not. The paperwork ends at the job instead of after it.
Payments and saved methods Where the action involves money, with the rails and the wallets that work in Canada. The repeat purchase takes one thumb.
Integrations Your CRM, ERP, e-commerce, booking or dispatch systems, connected and validated during scoping. The app writes into the systems the business already runs on.
The admin console Content, offers, rules and messages changed by your team without a release. A price change does not wait in a store review queue.
Ship it, and keep it aliveRelease one, and the years after it
Store accounts and listings Developer accounts opened in your name, the listings written, the review submission handled. The product is published under your company rather than under ours.
Analytics on what people did The measures agreed in discovery, instrumented before launch rather than added after it. The roadmap comes from behaviour instead of from the loudest person in the room.
Platform maintenance Operating system releases and policy changes, tracked and handled on the schedule the platforms set. The app does not quietly degrade because somebody else changed something.

Scroll the table sideways to read it.

Block 06

How itworks.

Five steps and a loop. The drawing is a circle rather than a line because the second open is the whole argument: an app that is only ever opened once is a website with an icon on it.

Scroll the drawing sideways to read it.

Three steps across the top, one line, and a return path. The only dark plate on the board is the decision that stays with you.

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. Something starts it.

    A habit, a job landing on a board, a delivery arriving, a message you approved. The trigger is the frequency half of the arithmetic, and it is the part most app projects never name, which is why so many of them are opened once.

  2. The action takes one thumb.

    Thirty seconds, standing up, on a phone that may be at ten percent battery in a loading bay. Everything that is not the action is behind it rather than in front of it, and the count that matters is taps.

  3. They get the thing they came for.

    The order placed, the slot held, the job closed, the proof captured. This is the value half of the arithmetic, and it is the sentence a customer would use to explain why the app is still on their phone.

  4. It stops at the line.

    A notification is a letter to a customer, so it is your decision and not a default. Which events are worth a message, who gets them, when they may fire, and what a person can switch off, are set by you and changed by you without a release.

  5. They open it again, and the loop closes.

    On Thursday, not only on the day it was installed. The return path is the measure the roadmap is built from: if the second open is not happening, the answer is not a redesign, it is that the action was the wrong one, and that is a conversation rather than a sprint.

The first question on the discovery call is the one that can end the project. Frequency, value and convenience, run with your numbers rather than ours. If it fails, we say so before anything is built, and build the website instead.

Book a discovery call

Block 07

What youend up with.

  • The value test, written down

    Frequency, value and convenience scored with your numbers, and the recommendation that came out of it, including when the recommendation was a website.

  • The product definition

    The one action, the core path, what is in the first release, and what was deliberately left out of it.

  • The app on both platforms

    Published under your own developer accounts, in your company's name, with the listings written and submitted.

  • The server side and the data

    Running in your own cloud accounts under your admin access, from the first commit rather than at handover.

  • The admin console

    Content, offers, rules and messages, changed by your team without waiting for a release or for us.

  • The notification rules

    Every event that can send a message, who receives it, when it may fire, and what a person can switch off. Agreed before launch.

  • The integrations, validated

    Each connection to your CRM, ERP, booking or dispatch system, confirmed in writing during scoping rather than assumed.

  • Analytics against agreed measures

    Instrumented before launch day, so the first month produces evidence instead of a question.

  • The launch record

    The fourteen published checks, run in full against the finished build, with the result of each one written down.

  • The maintenance plan

    What the platforms are going to change, roughly when, and who handles it. Written before launch, because it starts the week after.

V3. The notification rules, drawn

your-company/app/notifications 5 events, 3 of them send

What is allowed to interrupt somebody

Agreed before launch, changed by your team without a release.

  • The order shippedSends

    To the person who placed it, once, at the moment it leaves. It is the message people say they want, and the only one nobody switches off.

    On
  • The job was assignedSends

    To the crew member it was assigned to, in working hours only, and it does not fire again if they are already in the app.

    On
  • The thing they reorder is backSends

    To people who have ordered it before, at most once a month, and switchable off in two taps inside the app.

    On
  • We have not seen you in a whileNever sends

    Held. It is a message about our interests rather than theirs, and it is the one that gets an app's notifications turned off for good.

    Held
  • A promotion, to everybodyNever sends

    Held unless somebody asked for it. Commercial messages carry consent rules and an unsubscribe, and the app is not a way around either.

    Held
Two of the five events are deliberately never sent, and that is the design working rather than the design failing. Notification permission is granted once and withdrawn once, so the rules are the part of this product that decides whether it still exists in a year.

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. We run the value test on your numbers, name the one action, and decide whether this is an app at all. A recommendation against building is a legitimate result of this phase.

    How long
    One call. The written proposal follows it.
    Your people
    Whoever owns the customer relationship or the field operation.
    You end up with
    The value test written down, and a written proposal with a scope, a price and a timeline you can sign or walk away from. Yours either way.
  2. 02

    Design

    The core path first, in as few taps as it can honestly be, on both platforms. Native or cross-platform is decided here on the product's requirements, and the reasoning is written down rather than asserted.

    How long
    Set in the signed proposal.
    Your people
    Whoever can approve how the action works, plus one person who does the job today.
    You end up with
    The product definition, the core path, and the platform decision with its reasoning.
  3. 03

    Build

    The app, the server side and the integrations, with a working build on a real device at every review. Not a prototype and not a video: something a person on your side installs and uses.

    How long
    Set in the signed proposal, with the review schedule agreed in it.
    Your people
    One reviewer per review, plus whoever owns the systems being connected.
    You end up with
    A build on your own phone at every review, and the code and the server side in your accounts from the first commit.
  4. 04

    Launch

    Store accounts in your name, the listings written, the submission handled, and the same fourteen published checks every HUREAL build passes. Then a plan for how anybody is going to find out the app exists.

    How long
    The checklist against the finished build, plus each platform's own review, which is theirs and not ours to promise.
    Your people
    Whoever can sign the developer agreements in your company's name, plus a tester on each platform.
    You end up with
    The product live under your own accounts, and a launch record against fourteen named checks.
  5. 05

    Run

    Operating system releases, policy changes, the measures agreed in discovery, and the next release when the evidence says what it should contain. 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 changed, what people actually did, what it produced, and what did not work.

What makes it longer: how many systems the app writes into, whether the work has to continue without signal, whether money moves inside the product, and how much of the phone's own hardware the task needs. What does not make it longer: how many screens you eventually want. The second release is faster than the first every time, because the accounts, the sync, the console and the release pipeline already exist.

Read the whole method, including the fourteen launch checks

Block 09

What itconnects to.

An app that does not write into the systems you already run is a second set of records to reconcile. By category, because the category is the question a buyer actually has.

  • CRM

    Where the account, the contact and the history live, and where an app signup has to arrive.

    Salesforce, HubSpot, Zoho, Dynamics

  • ERP, inventory and pricing

    Where stock, account pricing and credit are true, which is what makes a reorder screen worth opening.

    NetSuite, Sage, SAP, QuickBooks

  • E-commerce

    Where the catalogue, the order and the customer's account already exist, so the app is not a second store.

    Shopify, WooCommerce, BigCommerce

  • Booking, dispatch and scheduling

    Where a slot or a job is held, moved or closed, which is most of what a field app does all day.

    Calendly, Acuity, an in-house dispatch board

  • Payments and wallets

    Where money moves, with the rails that work in Canada and the wallets that live on the phone.

    card rails, Interac, Apple Wallet, Google Wallet

  • Identity and sign-in

    Where a person is proven to be themselves, including your own staff directory for an internal product.

    Microsoft Entra, Google Workspace, an existing customer login

  • Messaging and push delivery

    How a message actually reaches a device, and how consent and switch-offs are recorded against the person.

    the platforms' own push services, email, SMS

  • Analytics and crash reporting

    What people did, and what broke on the phone models your customers actually carry.

    product analytics, crash reporting, your existing web analytics

  • Your industry system

    The one system that runs your trade, which is usually the one that matters most and the one nobody else connects to.

    dispatch, estimating, practice management, warehouse management

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

  • Test the idea firstFrequency, value and convenience, on your numbers, before anything is designed.
  • Build one job properlyFinished and polished for a single action, rather than rough at five of them.
  • Design for the phone in the handOne thumb, standing up, in a loading bay, on a mid-range device on a cellular connection.
  • Publish under your nameDeveloper accounts, listings and releases in your company's name, opened by you.
  • Write the notification rules downEvery event that can interrupt somebody, agreed before launch and switchable off after it.
  • Connect it to what you runValidated during scoping and confirmed in writing, so the app is not a second set of records.
  • Say when it is a websiteWhere the requirement is see information and fill in a form, that is the recommendation, and it is free.

What we will not do

  • Build an app to be seen to have oneThere is no action in that sentence, so the value test has nothing to score and we would be selling you an icon.
  • Ship five features at fifty percentA first release that is complete for one job beats one that is rough at five, and the second version is the cheap one.
  • Hold your developer accountsThey are opened in your name. We work under our own access, which you can revoke on any afternoon.
  • Send a notification you have not approvedA notification is a letter to a customer. Nothing fires that is not in the rules you signed.
  • Buy installsA number bought is a number that leaves. Distribution is designed into the product and the launch, or it is not claimed.
  • Promise a store approval or a date for oneBoth platforms review on their own schedule and against their own guidelines. We design to them and we do not speak for them.
  • Leave an app running with nobody maintaining itOperating systems and policies change on their schedule. If nobody will own it, we will say so before the build rather than after it.

Every one of those is in the scope document before you sign it, which is the only place a commitment is worth anything. The first line in the right column is the one that costs us the most, and it is the one we would ask you to test first: bring us a project where the honest answer is a website, and see what we say.

Block 11

A mobile website, an installable one,or an app.

Three ways to be on somebody's phone. They cost different amounts, they reach different numbers of people, and the cheapest of the three is the right answer more often than anyone selling apps will tell you.

The three approaches, on ten deciding factors
Deciding factor A fast mobile websiteVisited An installable web appAdded A built app on both storesInstalled
Who it reaches Anyone with the link, on the first visit. Anyone with the link, and a smaller group who add it to their screen. The people who install it, which is always fewer people and usually better ones.
Cost to start Lowest. It is part of the website you already need. Low. It is the website, plus the work that makes it installable. Highest. It is a build, on two platforms, with a server behind it.
Cost to keep Hosting, and whatever the site already costs. The same, plus testing that installation still behaves on each platform. Hosting, plus work the platforms schedule for you when they change an operating system or a policy.
A place on the home screen A bookmark, if somebody makes one. Yes, once somebody adds it. Yes, and it arrives there by installing rather than by being explained.
Working with no signal No. Some of it, and how much varies by platform and version. Designed for it, including what happens to the work when signal comes back.
Camera, scanning, wallet, background location The camera and a rough location. Not the rest. More than a tab, less than an app, and the list changes with each platform release. All of it, on both platforms, with permission asked at the moment it is needed.
Notifications No. On some platforms and versions, and not on others. Yes, under rules you wrote, with a switch a person can use.
An identity that persists A login that a cleared browser forgets. Persists while it stays added. Persists with the phone, opened by a face or a fingerprint.
Store review and platform rules None. You publish when you like. None. Every release is reviewed against guidelines that are not yours and can change.
When it is the right answer The action happens rarely, or the requirement is read something and maybe fill in a form. The action is frequent but needs nothing the phone itself has to provide. The action is frequent, it needs the hardware or the offline stretch or the identity, and somebody owns the product after launch.

The verdict, including where it goes against us

If the action happens once or twice a year, buy the fast mobile website. It reaches everyone on the first visit, nobody has to install anything, and it costs a fraction of this service. This is the most common honest answer to the question on this page, and it is the recommendation we make most often.

If nobody on your side will own the product after launch, the app is the worse buy. A website sits still safely. An app does not: operating systems and store policies change on a schedule set by other people, so an unmaintained app degrades whether or not anybody touches it, and a year later it is an icon that crashes on the newest phone in the office.

An app earns its cost in a narrow place, and it is worth naming exactly: the action happens weekly or more, it needs something only the phone can give it, and there is a person whose job includes the product on Monday. That is the whole case. The value test is where we find out whether you are in it, and we would rather find out in the first session than in month four.

Block 12

What a Canadian buildhas to be designed around.

A mobile product carries two sets of requirements at once: the law where your customers are, and the published rules of the two platforms it has to live on. These are the ones this service is designed around, and the line between what we build and what your counsel decides.

  • AccessibilityWCAG 2.2 AA, each platform's own accessibility interfaces, plus AODA, the provincial equivalents and the Accessible Canada Act where they apply

    What we design forEvery path completed with the screen reader each platform ships, text that reflows when somebody has set a larger size, contrast checked on the surface we shipped rather than in the design file, touch targets a gloved or unsteady hand can hit, and motion that honours the reduced motion setting.

    What we document for your counselThe test results per screen, on both platforms, with the standard tested against and the date, so a barrier report can be answered with a measurement rather than with an assurance.

  • PrivacyPIPEDA, and Quebec's Law 25 where it applies

    What we design forA stated purpose for every permission the app asks for, asked at the moment the task needs it rather than on first launch, the smallest set of data that does the job, analytics and tracking behind a consent the person actually gave, and a way to delete an account from inside the product.

    What we document for your counselWhat the app collects, what the phone gives it, where it is stored, which processors see it, how long it is kept, and what deleting an account actually removes.

  • App store requirementsThe published review guidelines and declarations of both platforms

    What we design forThe privacy declarations each store asks for, account deletion where an account can be created, the age rating the content calls for, the platform's own payment rules where digital goods are involved, and permission prompts that say what they are for.

    What we document for your counselEvery declaration made to each platform in your company's name, so the answers a store has on file are answers somebody on your side has read.

  • Electronic messagesCASL, for anything commercial the app or its server sends

    What we design forConsent and its basis recorded against the person before any commercial message, no pre-ticked boxes, a switch inside the app that works in one action, and the identification the legislation asks to be present in a commercial message.

    What we document for your counselThe consent basis per person and the send log, which is the evidence the legislation asks you to be able to produce.

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

    What we design forPer-language authoring as a first design decision rather than a translation pass at the end, which on a mobile product includes the store listing, the permission prompts, the notifications, the error states and the automated email, not only the screens.

    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 storage region, the push delivery service, the analytics processor and the crash reporting processor named in the scope before the build, chosen rather than inherited from whatever a framework 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.

  • Do we actually need an app?

    Often not, and we would rather tell you that in the first conversation. If customers interact once or twice a year, a fast mobile website usually serves them better and costs far less. If the action happens weekly, or if your own people are working off paper in the field, an app earns its place.

  • Native or cross-platform?

    That is decided during discovery on the product's requirements, and we explain the reasoning. What we will commit to up front is that it runs properly on both iPhone and Android, and that the maintenance cost stays sensible over years rather than months.

  • How long does an app need support after launch?

    For as long as it is used. Both platforms release operating system updates and change their policies, so an unmaintained app degrades on a schedule set by other people. Maintenance is part of the plan from the start, and it is monthly and cancellable.

  • 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.

  • Who owns the app and the developer accounts?

    You do. Developer accounts on both platforms are opened in your company's name, and the app is published under them. The code, the server side and the data run in your own cloud accounts under your admin access from the first commit, so there is nothing to hand over at the end.

  • What happens if a platform rejects the release?

    We answer the reviewer, change what needs changing, and resubmit, and it is part of the engagement rather than an extra. We design to the published guidelines and we read them before the build rather than after a rejection, but the review is theirs and we do not speak for it or promise a date for it.

  • How does anyone find out the app exists?

    Distribution is part of the launch phase, not an afterthought: the people who already deal with you are told where they already deal with you, in the order confirmation, at the counter, on the invoice, by the person on the phone. We do not buy installs, because a number bought is a number that leaves.

  • Will it work where there is no signal?

    Where the work happens without signal, yes, and that is a scoping decision rather than a switch. What is captured offline, what it does when two people changed the same record, and what a person sees when a sync fails are designed deliberately, because an app that loses a day of work loses the crew as well.

  • Can our team change things without a release?

    Yes, for everything in the admin console: content, offers, rules, prices and the notification settings. Anything that changes how the product works still needs a release and a store review. Which is which is agreed in design, because it decides how often you will be waiting on somebody else.

  • 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. The demonstration answers you in the browser right now. And phase one produces a written scope, price and timeline that is yours whether or not you continue.

  • Do you build apps for our own staff rather than for customers?

    Yes, and those often pay back first. A field tool for technicians, drivers, inspectors or a warehouse team never appears in a public store, is distributed inside your company, and is measured on hours rather than on downloads. The value test is the same arithmetic with your own people in it.

  • We already have an app. Can you work on it?

    Yes. The performance audit is the usual way in: we look at what you have against the job you want it to do and give you a prioritised plan with the arithmetic attached. Where rebuilding honestly costs less than repairing, we show you that arithmetic rather than asserting it.

Block 14

Three servicesnext to this one.

Block 15

Where thismatters most.

Four sectors, and the reason in each

  • Construction and trades

    The work happens where the desk is not, and often where the signal is not either. Job details, photographs, signatures and hours captured on the phone at the job arrive the same day instead of on Friday, and the office stops phoning the crew to ask.

  • Manufacturing and distribution

    Accounts reorder the same lines on negotiated pricing, week after week. That is the highest-scoring shape in the value test, and it is also the one where the reorder currently arrives as a phone call somebody has to type up.

  • Real estate and property

    Inspections, keys, showings and maintenance requests all happen in a building rather than at a desk, and the photograph taken there is the record. A phone is the only device that is reliably present at the moment the fact is created.

  • Healthcare and clinics

    Named here with a limit rather than a pitch. HUREAL does not yet build a mobile product that holds health information: the Canadian-region infrastructure and the health-information posture that would need are not settled. Booking, reminders and administrative work that touches no health information are a different question, and we will scope that one.

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 mobile products 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 action you want people carrying in their pocket. A discovery call with the people who own the outcome. We run the value test on your numbers, name the one action, decide whether it is an app at all, and list the systems it has to write into. 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.

An app that earns its second open.

HUREAL / Material studies