A material study photographed in bright daylight. Pleated turquoise glass layers curve up and meet overhead to form one open arch in the right half of the frame, daylight passing straight through the opening so the inside of the arch reads paler than the glass around it. The left of the frame is empty pale mint.
  1. Home
  2. Services
  3. Web Applications and Portals
  4. Custom web applications

Part of Web Applications and Portals

Custom webapplications.

A custom web application turns a process that currently lives in a spreadsheet, a shared inbox and one person's memory into a system. It is one of three services under Web Applications and Portals.

A process that used to depend on individual memory, recorded, visible, and measurable for the first time.

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

In your words

Soundslike this?

  1. One spreadsheet holds a process the business depends on.

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

  3. Approvals happen in an email thread, and nobody can find the thread.

  4. A customer asks for status and three people have to be asked.

  5. We reconcile two systems by hand every week.

  6. Our quoting rules are in a document nobody has opened in two years.

  7. We looked at four products and none of them handles the part that matters.

If the thing that needs to happen is a customer getting their own answer, a customer portal is the smaller and usually better project.

In plain language

The process already exists.It just has no system.

Every established business runs at least one important process that lives in a spreadsheet, a shared inbox and one person's memory. It works, because people make it work. It stops working when volume grows, when that person is away, or when a customer asks for status.

The hard part is not the software. It is the exceptions.

A custom application turns the process into a system: the same steps, the same rules, the same approvals, but recorded, visible and available to everyone who needs it. The work of building it is mostly understanding the process precisely, including the workarounds, because the exceptions are where the value is.

We build custom only where custom pays for itself, and that test has a shape. Name one requirement a standard platform cannot meet, and put a number on why it matters. If we cannot do that with you, we recommend the platform instead, and that recommendation is free.

When buying beats building. If the requirement can be named and a configured platform meets it, buy the platform. It costs less than anything we would build, somebody else maintains it, and a configured tool that fits is a better outcome than a custom one that merely exists. Where what you actually want is a screen of numbers rather than a process, the page is Dashboards and business reporting.

The capability table

What a custombuild includes.

Fifteen capabilities, what each one does in plain words, and what it changes for the business. The first group is the longest part of the project and the one that decides whether the rest is worth doing.

Custom web applications, the capability table
Capability What it does What it changes
Understand the processWhere most of the value is
Process mapping Sessions with the people who do the work: what happens, what breaks, and what the workarounds are. The exceptions are in the build rather than discovered after it.
The build or buy test The requirement a standard platform cannot meet, written down with what it is worth. You can hold the justification up a year later and check it.
Data model and permissions What a record is, who may see it, and who may change it. Access is designed rather than granted by request.
Build itIn slices, the core path first
Interface design per role Built around the task rather than around the database. People use it without being trained twice.
Forms, workflow, rules and approvals The process as it actually runs, including the branches. The rules stop living in one person's head.
Notifications Who is told what, when, and what a reminder does. Work stops waiting silently.
Records, search and history Every state change kept, with who did it and when. A question about last March has an answer.
Integrations The systems the process touches, read and written in the right direction. The re-keying between systems stops.
Reporting and exports For the people who have to answer questions about the process. A process nobody could measure becomes a number.
Make it surviveAfter we leave
Import of existing data Spreadsheets and legacy systems, mapped and checked against a figure you trust. You start with your history rather than from empty.
Configurable rules Thresholds, steps and approvals changed by your admin rather than by a developer. The system changes when the business does.
Testing including the edge cases your team names The awkward ones, written down during discovery rather than met in week one. The first hard week is not the first test.
Documentation and training per role Written for a new hire, and for a developer who has never met us. You are not locked in by obscurity.
Hosting in your accounts With monitoring, backups and a recovery plan. The system is yours including on the day something breaks.
A pilot alongside the old process Real users, real work, in parallel until it is trusted. The cutover happens when the pilot holds rather than when the plan says so.

Scroll the table sideways to read it.

How it works

One system,one set of rules.

The parent's drawing, read as a process rather than as a customer. The actions on the left are the steps people take, the systems on the right are what the application reads and writes, and the line is where a case that does not fit the rules waits for a person.

Scroll the drawing sideways to read it.

The same board, read from inside the business. The actions on the left are your team's rather than your customers'.

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. The actions on the left are the work.

    Start a job, upload a document, book a slot, record a payment. On a customer portal these are things a customer does. On an internal application they are things your team does, and the drawing is the same because the design problem is the same.

  2. One application, one login, your rules.

    Every action goes through one place that knows who you are and what you are allowed to do. That is what replaces the spreadsheet, and it is also what makes the history exist at all.

  3. It reads and writes the system of record.

    Orders, documents, schedule and accounts stay where they already live. The application is not a second copy of your data, because a second copy is a second version of the truth.

  4. The phone call stops.

    The struck through line on the drawing is the point of the project. Work that used to require asking somebody no longer requires asking somebody, and that is the saving that pays for the build.

  5. Anything outside the rules waits for you.

    With the file attached and the reason stated. A system that forces every exception into a shape it does not fit is a system people route around, and the routing around is how you end up with a second spreadsheet.

The test is one sentence. Name the requirement a standard platform cannot meet, and put a number on why it matters. If we cannot do that with you, we recommend the platform instead, and that recommendation is free.

Book a discovery call

The deliverables

What youend up with.

  • A system that holds the process

    Which used to depend on individual memory.

  • The build or buy justification

    The requirement, the number attached to it, and the decision, in writing.

  • The process map

    End to end, with the exceptions and the people named against each step.

  • The code, the data and the infrastructure

    In your own accounts, with admin access from day one.

  • Reporting on a process nobody could previously measure

    Including how often the exceptions fire.

  • Configurable rules

    Thresholds, steps and approvals your admin can change without a developer.

  • Documentation good enough for a new hire

    And for a developer who has never met us.

  • A pilot record

    Real users doing real work in parallel with the old process, before you depended on it.

What is not on this list. The customer facing half. Where the people using it are your customers rather than your staff, the design problem changes and the page is Customer portals and booking. Where the output is a screen of numbers rather than a process, it is Dashboards and business reporting.

By category

What a custom applicationconnects to.

By category, because the category is the question. On a custom build the connections are usually the reason the process was manual in the first place.

  • CRM

    Where the customer and the opportunity already exist.

    Salesforce, HubSpot, Zoho, Dynamics

  • ERP and accounting

    Where price, cost, stock and invoices are true.

    NetSuite, SAP, Sage, QuickBooks

  • Document storage

    Where the files the process produces have to land.

    SharePoint, Google Drive, Dropbox

  • Email and calendar

    Where a notification or an approval request arrives.

    Microsoft 365, Google Workspace

  • Identity

    Where sign in and roles are already managed.

    Microsoft Entra ID, Google Workspace, single sign on

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

    estimating, dispatch, practice management, property management

  • Spreadsheets and legacy databases

    Where the process lives today, and where the history has to come from.

    Excel, Access, an old in house system

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.

Asked and answered

Questions peopleactually ask.

  • How do we know custom is justified?

    Name one requirement a standard platform 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 recommend the platform instead, and that recommendation is free.

  • What if our process changes after launch?

    It will. The build separates the rules from the code where it can, so thresholds, steps and approvals can be changed by your admin rather than by a developer. The rest is handled in the monthly improvement work, and a change is costed before it starts.

  • Who owns it, and can someone else maintain it?

    You own it, in your 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.

  • What happens to the spreadsheet we use now?

    It gets read carefully, because it is the specification nobody wrote. The data is imported, the rules inside it are made explicit, and the exceptions it quietly handles are the first thing we ask about. It stays available until the pilot says it does not need to be.

  • How do you avoid the project that never launches?

    The build runs in slices: the core path first, working and usable, then the surrounding cases. There is a pilot with real users doing real work alongside the old process, and the cutover happens when the pilot holds rather than when the plan says so.

  • Will our team actually use it?

    They are in the room while it is designed, which is the only reliable answer. The interface is built around the task each role performs rather than around the database, and the exceptions they name in discovery are in the first version rather than in a later phase.

  • 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, and here the scope is the process itself. Fixed scope, fixed price, fixed timeline, agreed before any code.

Three pages next to this one

Where thissits.

Close

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

Book a discovery call

For when you know which process is costing you and want the scope before the spend. A discovery call with the people who actually run it. We map it end to end including the exceptions, name what a system would take over, and afterwards you get a written proposal with 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
A material study photographed in bright daylight. A thin sliver of the monumental pleated turquoise glass wave enters from the right edge of a very wide frame, its fins and one polished silver ribbon catching the light at the crest, above a pearl reflective floor that runs the full width. The left of the frame is an almost empty pale mint room.

Software for the way one business works.

HUREAL / Material studies