Skip to main content

Demos

See for yourself what's possible.

Instead of descriptions: working examples. Click through complete sector websites, play a workflow through, follow a conversation with an agent — or have a phone call read aloud to you.

Apps you hold in your hand

Apps to click through — each with several views, a device frame, tabs along the bottom and the states a website never has: loading, empty, failed, offline. In full screen the device fills the whole display.

The project frame

How Awelior would approach this project

The businesses shown here are invented — the way they are built is not. None of this is work delivered for a client. It is the shape we would give such a project — with the same depth, but without a client who would have to answer for it.

Where it starts

“We could do with an app” usually means there is a process with paper stuck to it — the printed day plan, the timesheet in the van, the attendance list in the training room. Whether that really needs an app, or whether a website would do, comes down to one question: does it have to work without a signal?

Decisions

  • Roles, not industries

    What shapes an app is the role, not the trade. The same building services firm needs two completely different apps for its customers and for its engineers; conversely a driver, a meter reader and a site foreman work in businesses with nothing in common and need the same shape of app — offline, one-handed, in gloves. So the demos are ordered by role rather than by sector.

  • Four states in every app

    Loading, empty, failed, offline. These four screens decide whether an app stays usable in a basement, and they are the ones routinely missing from a design. Every demo in the section shows them explicitly.

  • iOS and Android side by side

    Every demo sits in either an iOS frame or an Android frame, with the real differences in title bar, back route and system bar; across the section the two platforms appear about equally often. The point is not the device chrome; it is that one codebase serves both — and that the platform is a decision rather than a default.

Deliberately left outNo login, no storage, no push notifications. Everything is laid out and nothing acts: buttons are disabled, tick boxes fixed, input fields have no target — otherwise the demo would be a prototype promising something that is not behind it.

What is in it

Mobile apps
27
Screens
135
Content blocks
444
Languages
4

Each app runs in the browser, has a tab bar, pushed detail views and a way back. What responds is the navigation between screens; everything beyond that is laid out and labeled as such. All four languages are complete, including the state screens.

How it would go on

  • Accounts and permissions

    Sign-in, roles, device binding — and the question of what happens when a phone goes missing.

  • Synchronization

    Whatever was captured offline has to be merged once there is a signal again. That is the most demanding part of a field service app, and the reason it gets a screen of its own.

  • Stores and operations

    Submission to Apple and Google with their own demands on privacy and age rating, plus updates and a route for bug reports coming back from the field.

Talk through your project

For customers

For field service

Booking, appointments, access

Learning and records

Tell us what you have in mind.

Answer a few questions about your project. At the end you book an appointment and see a guide figure for the effort — free, without obligation and with no sales pitch.

  • You'll hear back within 24 hours
  • No sales pressure
  • Fixed price before work starts