Request a discovery call
  1. Home
  2. How we work

How we work

From problem to working system,in the open.

Five phases, what you hold at the end of it, and the checks a build passes before it goes live.

The method

Five phases, each ending in something you hold.

  1. DiscoverProposal
  2. DesignSigned scope
  3. Build and testWorking software
  4. Launch and hand overYour sign-off
  5. ImproveWritten report
The method in five phases: discover, ending in a proposal; design, ending in a signed scope; build, ending in working software; launch, which waits for your sign-off; and improve, with a written report.

What every engagementcommits to.

What every HUREAL engagement commits to, in writing

  1. Scope, price, and timing agreed before implementation.
  2. A working build, shown at review points agreed in the proposal, running 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.

Phase 1 of 5, Discover

The call, or the audit.

The discovery call

You know what you want built. A free conversation with the people who own the outcome about the work as it runs today, what a system could take over, and the systems involved. A written proposal follows.

Request a discovery call

The Performance Audit

You want the evidence first. A written report on what your site does today, with the findings ranked by what to fix first. The delivery date is confirmed in writing when you request it.

Start with an audit

Phase 1 of 5, Discover

Scope, price, and timeline.

Scope, price, and timing are agreed before implementation. Where discovery resolves the scope, the proposal carries a fixed quote. Where something is still unknown, it carries a bounded estimate and names what remains open.

What a signed scope includes, and what it does not

What a signed scope includes

  • Everything named in the scope document, at the price and for the date printed on it.
  • The fourteen launch checks, with a result recorded against each one.
  • The build running in your own cloud accounts.
  • Reviews with working software, at points agreed in the proposal.
  • Documentation written for a developer who has never met us.
  • Correcting anything that does not do what the scope said. That is the work.

What it does not include

  • Work that is not in the scope document. New work gets its own scope, number, and date.
  • Third party licences, hosting, and vendor bills, paid on your own accounts, in your name.
  • Content, photography, and product data, unless the scope says HUREAL provides them.
  • Migrating data nobody has opened yet. Looking at it is scoped before moving it is priced.
  • Improvement after launch. That is ongoing support, and the build works without it.
  • A compliance determination. That belongs to your counsel or your privacy officer.
your-company/proposal/scope

Scope, price, and timeline

Ready to sign
  • Included: customer portal, CRM connection
  • Included: fourteen launch checks
  • Excluded: migrating the old archive
  • Excluded: product photography
  • Price: quoted from the resolved scope
  • Timeline: dates and review points

Illustration, sample data

What it excludes, printed next to what it includes.
01

Request a discovery call

A conversation with the people who own the outcome. If you would rather have the evidence first, start with the audit.

02

Receive the proposal

A scope, a price, and a timeline, with what it excludes next to what it includes. It is yours whether or not anything follows.

03

Sign it, or do not

Code starts after the signature and not before. What is still open is named in the document, not discovered later.

What moves the number is explained in what moves the price of a website build.

Phase 2 of 5, Design

Design.

The decisions that are expensive to reverse are made here, while they are still cheap to change: what the build will not do, where a person stays in the loop, which system owns which field, and the accessibility target. Every approval point is designed here, before it is built.

The three levels, drawn as one scale
01 Automate

The system does it.

Repetitive, deterministic, and reversible work.

  • Routing
  • Data entry
  • Reminders
  • Reports
02 Review

AI prepares. A person approves.

Work the system can prepare, where a person signs off.

  • Quotations
  • Sensitive replies
  • Publishing
03 Decide

Human only.

Decisions that stay with a person.

  • Legal commitments
  • Unusual financial decisions
  • Exceptions
Three levels drawn as one scale: work the system does, work it prepares for a person to approve, and decisions that stay with a person.

Where the line is drawn, in full

Phase 3 of 5, Build

Build.

Working software shown at review points agreed in the proposal, not a reveal at the end. The build runs in your own cloud accounts. If something is going to be late, you hear it from us in the review, with the new date and the reason.

A review where the software does not work is reported as a failed review.

Build/Reviews

Review points

From the proposal
ReviewShownResult
1Sign-in and account pagesPassed
2CRM connection, live dataFailed, new date
2bCRM connection, retestedPassed
3Booking flowNext

Illustration, sample data

A failed review is recorded, with the new date and the reason.

Phase 3 of 5, Build

Test: fourteen checks, by name.

The fourteen checks, and a sample launch record

Every HUREAL build passes these before it goes live

  1. Speed on a mid range phone on a cellular connection. Not on a new phone on office wifi.
  2. Keyboard and screen reader. Every path completed with no mouse, and read aloud end to end.
  3. Contrast and text sizing, checked against the WCAG 2.2 AA standard on the surface we shipped.
  4. Reduced motion, honoured. Anything that moves has a still version that still communicates.
  5. Every language read by a person who writes it, including forms, errors, and automated email.
  6. Forms tested to the inbox and to the CRM, with the acknowledgement received.
  7. Tracking verified end to end, from the click to the recorded conversion to the report.
  8. Redirects mapped from every old URL, so existing search rankings survive the move.
  9. Structured data validated on each page type.
  10. Crawler access checked, for search engines and for AI crawlers.
  11. Security: certificates, headers, dependency versions, admin access review, and rate limits.
  12. Backups taken and a restore actually performed, not just configured.
  13. Error monitoring and alerting live, pointing at a person.
  14. Admin access confirmed in your accounts, with your team signed in before launch day.
your-company/launch/record 14 checks, 6 shown

What was run, and what it said

One row per check, with the result and the evidence. Kept whether or not everything passed first time.

  • 01

    Speed on a mid range phone on a cellular connection.

    Passed measured on the page a stranger lands on, not on the homepage.

  • 02

    Keyboard and screen reader, every path, read aloud end to end.

    Passed the booking path and the account path, both with no mouse.

  • 03

    Contrast and text sizing against WCAG 2.2 AA.

    Failed, then fixed two labels on the filter panel measured under the floor. Retested and recorded.

  • 10

    Crawler access, for search engines and for AI crawlers.

    Passed checked per crawler rather than assumed from one file.

  • 12

    Backups taken, and a restore actually performed.

    Failed, then fixed the first restore came back missing uploaded files. Configuration corrected, restore repeated, second attempt recorded.

  • 14

    Admin access confirmed in your accounts.

    Passed your operations lead signed in and removed a test collaborator, before launch day.

This is a designed representation of the artefact, not a record of anybody's launch. Two of the six entries are checks that did not pass first time, because that is what the record is for: a list with nothing but passes on it is a certificate, and a certificate is not evidence that anything was run.

Phase 4 of 5, Launch

Launch.

The same fourteen checks every time, run against the finished build, with the result recorded per check. The last check is not technical: your own team signed in to your own accounts, with admin access confirmed, before launch day.

Phase 4 of 5, Launch

Handover.

your-company/launch/handover
  • Documentation written for a developer who has never met us
  • Training for the people who will run it
  • The launch record, all fourteen checks
  • Admin access confirmed in your accounts before launch day

Illustration, sample data

A handover checklist with four items complete: documentation, training, the launch record, and admin access confirmed in your accounts.

Phase 5 of 5, Improve

Improve.

After launch, HUREAL can keep improving the system on evidence, with monitoring and a regular written report. You can stop at any point, and the system keeps running.

Ongoing support

What you own, from day one.

  • The domain and the accounts

    Registered and opened in your name, including the developer and platform accounts.

  • Admin access from day one

    Not at handover. Your team signs in during the build, not after it.

  • The code, the content, and the data

    Yours. There is no licence to renew and no component you rent from us.

  • Your data is not used to train a model

    And that commitment sits in the contract.

  • We do not hold your passwords

    Access is granted to a named collaborator account that you can remove yourself, at any time.

  • Nothing has to be handed back

    If you stop working with us there is no handover to negotiate, because you already had all of it.

  • Documentation for a developer who has never met us

    Written for the person who picks it up next.

Who has access to your project, and how to remove us
your-company/production Region Canada, Toronto

People with access

The owner was set when the account was created and has not changed since.

3 people
  • YouOwner

    Everything. Billing, transfer, deletion, and every key.

    Owner
  • Your operations leadAdmin

    Deploys, logs, and environment settings. No billing, no transfer.

  • HUREALCollaborator

    Deploys, logs, and error reports. No billing, no transfer, no deletion.

Remove is enabled on our row, and it always is. Nothing here is held by a HUREAL login, so removing us changes who can reach the project and nothing else about it.

Questions about the process.

  • What happens if something is going to be late?

    You hear it from us in the review, with the new date and the reason, rather than finding out when the date passes. Review points are agreed in the proposal so lateness surfaces early instead of at the end.

  • Can we stop partway through?

    Yes, and you keep what was produced up to that point. The proposal is yours after discovery, the signed scope and exclusions after design, and the working build in your accounts during the build. Nothing is held back to keep you here.

  • What does built in the open actually mean?

    Working software shown at review points you agreed before the build, running in your own cloud accounts under your admin access from the first commit. You can sign in and look without asking.

  • What if a launch check does not pass?

    The launch stops until it does, and the record keeps the failure rather than overwriting it. That is the reason the fourteen are published by name.

  • Do you work with our existing developer or agency?

    Yes, and who owns what is written down so nothing sits in the gap. The usual shape is that HUREAL is brought in for the platform, the connections, and the measurement while an in-house team keeps the day to day.

The first step is a conversation.

A free discovery call, then a written proposal with scope, price, and timing.

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.

Published before you hire us.