I build mobile apps with Flutter and React Native, progressive web apps and portals where customers and employees handle their own business – as a freelancer, remote across Europe and on-site in North Rhine-Westphalia.
An application is rarely judged by how cleanly it is built underneath. It is judged by whether anyone actually uses it day to day: on a company phone in the warehouse, on the road with poor reception, on a five-year-old office machine. This page is about exactly that side of software – the interface your customers and employees really hold in their hands.
Mobile development has been part of my work since the first hybrid apps with Cordova and PhoneGap. Today I mostly work with Flutter and Dart or with React Native – among other things on companion applications around a tax consulting suite and on a React Native app for e-prescriptions in pharmacies. The standard is always the same: an app that launches when you need it and can be used without anyone sitting through training first.
Not every project needs an app in the store. Often a progressive web app is enough – installable straight from the browser and still working offline – or a portal that fits into the application landscape you already run. And when a website turns out to be the right answer, I build it with WordPress or Astro so your team can maintain the content itself. Which route fits is something we settle before the first line of code.
Four building blocks around interface, device and release – on their own or combined.
One codebase, two platforms: with Flutter and Dart or with React Native you get an app that behaves the same on both systems while still looking at home on each. Camera, location, push notifications, biometric sign-in, scanners or file access are wired up through the device APIs – with platform-specific code where that is what it takes.
Where no store is needed, the application runs as a progressive web app: installable from the browser, updatable without a review process and still usable without a connection. Entries are stored locally first, for example in SQLite, and synchronised once the device is back online – including a clear rule for when two devices changed the same record.
Interfaces where people handle their own cases: viewing documents and contracts, filing requests, tracking status, updating master data, booking appointments. Sign-in and roles run through Keycloak and OpenID Connect, so everyone sees exactly what they are entitled to – and nothing beyond it.
Sites that load fast and stay maintainable without a developer: WordPress when your editors need a familiar interface, Astro when speed, security and low running costs come first. Plus a clean structure for search engines, measurable load times and a look that matches your corporate identity.
The kind of work that regularly lands on my desk.
Customers view their contracts, invoices and open cases themselves, upload documents and follow the processing status. It takes noticeable load off phone support and turns a back-and-forth email thread into a single click.
Technicians and field staff capture jobs, photos and signatures right where the work happens – including basements with no reception. As soon as the device is online again the data moves into the target system, with nobody typing up forms in the evening.
Shift plans, shift swaps, leave requests, announcements or checklists in an app that also reaches colleagues without a fixed desk. Push notifications replace the notice board in the break room.
A site that works on a phone just as well as on a desktop, gets found in search engines and can be updated by your team without raising a developer ticket – including migration of existing content and redirects.
Most app projects do not fail on technology. They fail because nobody held the interface early enough. Hence this sequence.
Who uses the application, on which devices and in which situation? That determines whether a native app, a progressive web app or a browser portal is the right answer. I will say openly when a website is enough and the store route only adds effort.
Instead of a gallery of screen designs you get a running version on your own device early on, covering the two or three most important flows. Real taps then decide whether navigation and wording work, before the rest is built.
Expansion in short increments with automated tests. Along the way I watch load times and data usage, keyboard operation, contrast, font sizes and screen reader labels – guided by the WCAG criteria, not only once someone complains.
Setting up store listings, signing, test distribution through TestFlight or internal test tracks and automated builds via CI/CD. After that: updates, adjustments to new operating system versions and a documented handover to your team.
What is used depends on your audience, their devices and the software you already run.
Describe briefly who should use the application and what it has to do. I will come back with an assessment of platform, effort and a sensible first step.