See for yourself what's possible.

Where it starts

Anyone who needs a website is usually shown a template and left to imagine the rest. But the real question is never “which color”. It is: what does my services page look like with nine services on it? Where do the opening hours go? What happens when someone wants an appointment at 11 at night? Those questions can only be answered on a complete site, not on a home page.

Decisions

• Five pages per business, not one

  A home page shows styling. Only the inner pages show structure — and that is where websites fall apart: on the second services page, on the contact form, on the map. So all fifteen demos can be walked through in full, navigation and footer included.

• Five archetypes instead of one house style

  A law firm and a garage built from the same template look like the same business in two colors. The demos therefore use five archetypes that change navigation, edge treatment and rhythm — plus eight drawing motifs, so the businesses differ by trade rather than by taste.

• Invented businesses instead of real clients

  A shop window full of real client logos would be a reference list — and ours lives under “Work”, with names, timeframe and role. This is about how the thing is built, and for that an invented business is the more honest choice: it can be tailored without a client having to answer for it.

Deliberately left outNo photography, no editing interface, no live form targets. Photographs of an invented business would have to be bought or generated, and would be the first untruth in the room; schematic drawings stand in their place and say so.

What is in it

Businesses

15

Pages

75

Content blocks

384

Languages

4

Every page exists in four languages and is readable without JavaScript. The booking flow, the basket, the menu and the image strip really do respond — they calculate and switch, but they send nothing. Images, map and form targets are indicated only, and each of those places says out loud what the finished site would put there.

How it would go on

• The company's own content

  Copy, photographs, prices, opening hours and the legal pages. That is the part that takes longest, and the part no website builder takes off your hands.

• Connections

  The form to a mailbox or a ticket system, the booking flow to a calendar, the shop to stock control, payment and shipping.

• Running it

  Hosting, domain, a privacy notice naming the services actually in use, backups, updates — and somebody who can change the content without asking us.

Talk through your project

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

Where it starts

Automation is usually sold as full automation, and that is exactly why it fails in practice: nobody lets software send quotations, post invoices or invite candidates on its own authority. What is actually needed is preparation up to the decision — and a visible point at which somebody agrees.

Decisions

• The person is a step, not a footnote

  In most of the processes the approval is the whole point: the account coding is proposed, not posted; the quotation is calculated, not sent. That step is marked out in the player, because otherwise it would look like any other — and the process would quietly claim to be fully automatic.

• Many processes, one on screen

  Every player side by side would mean as many timers running at once, all in view and none watched. You pick on the left and exactly one runs on the right — a process is something you watch, not something you skim.

• The before state stays visible

  Each process states how the same task gets done without it. That is the only figure the benefit can be read from, and it describes the manual work — it is not a measured result from one of our projects.

Deliberately left outNo connection to real systems, no sending, no percentage savings. The sample messages are stored, the sequence plays in the browser and touches nothing.

What is in it

Processes

12

Steps

75

Languages

4

Every process has a trigger, a sample message, its steps with realistic durations, and a result. Play, pause and reset all work; anyone who has turned motion off gets the whole sequence immediately and still.

How it would go on

• Access

  Mailbox, stock system, calendar, accounts — every connection with its own credentials, its own permissions and its own limits.

• Failure cases

  What happens when a document is unreadable, a service does not answer, or the same thing arrives twice. This is the part that decides whether anyone trusts it.

• Audit trail and responsibility

  Who approved what and when, what ran unattended, and how you get hold of a case that went wrong.

Talk through your project

Where it starts

The message no longer arrives through the contact form. It arrives over WhatsApp, at half past eight in the evening, with a voice note and three photos. Reply the next morning and the job is often already gone; reply at once and you are working through your own evening. So the task is not to type faster. It is to take over the part that can be answered without anyone having to think.

Decisions

• Every channel has its own rules — and they show up in the conversation

  WhatsApp Business allows free-form replies only within 24 hours of the last customer message; after that, only approved templates. Telegram has no phone number behind the sender, Instagram no account details. Treat all three the same and you build a demo that hits the first real rule and stops.

• The handover is in the conversation, not in the fine print

  Each of the sixteen conversations has the point where a human takes over — marked, not hidden. An assistant that keeps talking through a complaint costs more than it saves.

• Connected to what the business already runs

  Menu and booking calendar for the caterer, inventory and shipment tracking for the parts dealer, appointment book and price list for the photo studio. An answer without a source is a guess — and in a conversation you can read along, the difference is obvious.

Deliberately left outNo call to a language model and no connection to the real services. The sixteen conversations are scripted and run entirely in the browser. A demo genuinely wired to WhatsApp would need a verified business number and approval from Meta — both belong in your project, not in a preview.

What is in it

Channels

16

Turns

178

Languages

4

Sixteen conversations across three channels, in four languages, with sources, handover and limits marked visibly. Play and reset work; there is deliberately no input field, because it would promise something this demo does not deliver.

How it would go on

• Which channels you actually need

  Not all three just because they exist. Where do your customers write today — and where do you want them?

• The number and the approval

  WhatsApp Business requires its own verified phone number and a review by Meta. That takes time and belongs at the start, not the end.

• What gets stored from the thread

  A WhatsApp message is personal correspondence. What of it lands in your systems, how long it stays and who may see it is your call — not the platform’s.

Talk through your project

Where it starts

A chatbot that answers every question is more dangerous in customer service than none at all: it invents a delivery date and the company carries the consequences. The task is therefore not to get an agent talking, but to tie it to the systems an answer may come from — and to let it stay quiet where none does.

Decisions

• Every answer names its source

  Stock system, parcel tracking, price list, quality manual. Anything standing there without a source is guesswork — and in a conversation you can read along with, the difference is obvious straight away.

• The limit is highlighted, not hidden

  “I can't judge that.” “I don't give out reasons for absence.” Sentences like these are the strongest argument for an agent, and at first they looked like any other answer. Now they are marked out — exactly like the handover to a person.

• Narrow briefs instead of one know-it-all

  Customer service, appointments, frequently asked questions, quotations, product information, faults, complaints, purchasing, internal knowledge, rota, class booking, membership fees, order taking on WhatsApp, order status on Telegram, Instagram direct messages. Each agent has a narrow brief and a short list of connected sources — an agent for everything would have a reliable answer for nothing.

Deliberately left outNo call to a language model. The conversations are stored and run entirely in the browser. A live agent on a demo page would have to be wired to invented systems — and would then invent precisely what this section argues against.

What is in it

Conversations

12

Turns

102

Languages

4

Stored conversations — how many there are and how many turns they have is shown above, counted rather than typed — in four languages, with source, handover and limit as visible markers. Play and reset work; there is deliberately no input box, because it would promise an answer that never comes.

How it would go on

• Connecting your sources

  Which systems the agent may read, which it may not, and what happens to data that has no business going near a language model.

• Handover to people

  To whom, at what hours, with what context — and what the person on the other end is told when nobody is free.

• Supervision

  Reading along, reviewing, correcting. An agent nobody looks at after launch drifts — usually in exactly the place where it gets expensive.

Talk through your project

Where it starts

A call nobody answers is a lost job or an annoyed customer. An assistant that picks up instead is an obvious idea — and at the same time the place where most can go wrong: it must not quote prices, must not offer a medical opinion, and must not take a transcript without consent.

Decisions

• Consent comes first, not in the small print

  In most places we work, a transcript requires the caller's consent. So the announcement is the first sentence of every call and is marked out in the transcript — and anyone who objects still gets through, just without a verbatim record.

• Every call gets an address of its own

  A call is not a chat: it has second markers, a switchboard that diverts and hangs up, and a note left behind in the business afterwards. So it gets its own data format — and its own address rather than a place in a picker column. Anyone showing a client the one conversation where the assistant hands over has to be able to send that one; and without JavaScript, not just one of them may survive.

• More than one call shows the failure on purpose

  The call to the law firm shows an assistant with no business being there: it does not advise, does not soothe, discards the transcript after the objection and names the route to a human being. Next to it stand the caller it cannot make out and tells so, rather than guessing at a name — and the one who asks for a person straight away and gets one, without being asked what it is about. Nobody believes an assistant that can always do everything.

• The sound comes from the browser, not from us

  A phone assistant is the one thing we offer whose essential part cannot be seen. So the reading is done by the speech synthesis built into every browser — no service of ours, no account, no recording. One thing we spell out, because nobody would otherwise see it: some of those voices do not run on the device but at the browser vendor, and they send the text being read there. Which voice is speaking, and whether it sends anything, is stated at the control, and a switch beside it allows only the voices that stay on the device. The sound only starts on a button press, can be stopped at any time, and the transcript stays readable beside it. What this demo therefore does not claim is how the delivered assistant sounds.

Deliberately left outNo recording, no imitated voice, no telephony connection. The transcript is made audible through the reading voice built into the browser; it sounds different on every device and is not the voice of the delivered assistant. Where no suitable voice is installed, the page says so and stays with reading. Playback is compressed while the time markers stay those of the real conversation.

What is in it

Calls

12

Turns

148

Languages

4

Fully scripted calls with transcript, note and outcome, each at an address of its own — the number is above and is counted, not typed. The directory says of every call what it demonstrates and how it ends; its own page then carries the whole thing. Plus the cases where we advise against it and the legal framing. Start, pause and reset work, and so does reading aloud; the whole conversation can also be shown at once.

How it would go on

• The phone system

  Number, diversion rules, hours — and the question of how many rings should pass before the assistant picks up at all.

• Calendar and callbacks

  Appointments have to land in a real calendar and callback requests on a real desk. Without that route the note is just a file.

• Retention

  How long transcripts and notes are kept, who may see them and when they are deleted. The business decides that, not us.

Talk through your project

Where it starts

In most companies the thing that ought to be an application lives in spreadsheets: the outstanding invoices, the rota, the inspection deadlines, the stock. That works surprisingly long and always breaks in the same place — as soon as two people write into it at once, or somebody asks what the position was last Tuesday.

Decisions

• Every application says what it replaces

  Two shelf meters of binders, a magnet board, the calibration list taped to the metrology room door. Without that sentence a business application is a screen with tables on it; with it, it is an answer to something somebody recognizes.

• Five screens instead of a dashboard

  A dashboard photographs well and answers no question. So each of the ten applications has an overview, a list, a single record and two specialist screens — the single record being where you find out whether a data model holds up.

• Invented companies, real terminology

  The firms do not exist; the vocabulary does: work stages, batches, measuring equipment, working-time accounts, outstanding items. A demo that stays generic convinces nobody who works in the field — and that is exactly who is sitting at the table.

Deliberately left outNo login, no database, no search. Nothing is stored, sent or fetched; the forms are shown as operable but do nothing — anything that appeared to be “saved” in a demo would be a claim.

What is in it

Applications

10

Screens

50

Content blocks

182

Languages

4

Ten applications with five screens each, sidebar, header and stated role, complete in all four languages. Navigation between screens works; tables, calendars, charts and forms are rendered and labeled as samples.

How it would go on

• Data model and migration

  What comes across from the existing spreadsheets, what has to be captured fresh, and how the two run alongside each other for a while.

• Roles and permissions

  Who may read, who may change, who may approve. In a business application that is not an afterthought; it is half the domain logic.

• Interfaces

  Accounting, stock control, time recording, calendars — and the question of which system wins when two of them disagree.

Talk through your project