Service
Web and mobile apps
We build the screens people touch — a website, a kiosk or a phone — and the server side that makes them work.
Who it is for
A team with a clear job for the end person: buy something, service a machine, or see a status.
What it covers
- A web app or site with a clear structure
- A kiosk interface fit for touch
- Android and Flutter for an operator or a customer
- Checks on a phone and on a wide screen
What you get
- One team for the screen and the server
- Kiosk and phone are designed apart, because they are used differently
- A regular showing of a working slice, not of a picture
How we do it
We start not from a list of screens but from the action: on a kiosk that is “pay and take”, in the operator app it is “see which machine is waiting”. Kiosk and phone are designed separately, because they are used differently — one is tapped with a finger on the street, the other is glanced at on the move.
We work in short cycles and regularly show something you can press, not pictures. At the end we hand over code another programmer can read — no hidden builder only we can run. One team holds both the screen and the server, so nothing gets bounced between two vendors.
How an engagement runs
01. Paths
We write what the person does from the start to a successful end.
02. Skeleton
We settle the screens and the data before adding detail.
03. Build
Short cycles with something that can be clicked.
04. Handover
Code, a short note on how to run it, and what to look at when it fails.
Questions on this topic
Do you only build kiosks?
No. A kiosk is a common case. We also build ordinary sites and internal dashboards.
Native Android or Flutter?
Both. The choice depends on whether the app is tied to one device, or one codebase should cover more screens.