Short answer
A web application suits teams working at a desk; a mobile app suits users who work in the field, need device features or have unreliable connectivity. Most projects need both, and we decide what each takes on by looking at the user flow.
Web, mobile or both?
The decision depends on where the user does the work. For teams working at a desk, a web application is often enough. A mobile app makes sense when users are in the field, when you need device features such as the camera, location or Bluetooth, or when connectivity is not guaranteed. Many projects need both: web for the office and a mobile app for the field.
The hard parts of mobile
Offline work and synchronisation, notifications, device access, store publishing and release management, and subscription and payment flows each need their own design on mobile. We have experience building Bluetooth Low Energy device connections, field apps that work offline and mobile products published in the app stores.
Choosing the technology
We are not tied to one technology. On the web we use React, Next.js or Angular; on mobile, Flutter or React Native. For device-specific needs we add native modules in Kotlin and Swift. On the backend we build services and APIs with .NET or Node.js. The choice is driven by what your team can maintain later.
Deliverables
We define scope and acceptance criteria, screen flows, a working release, testing, error reporting and monitoring, handover documentation and, if needed, the store publishing process. Who owns the Apple and Google developer accounts is settled at the start. To narrow the scope of a first release, see our guide on scoping the first release of custom software.
When a mobile app is not needed
If users do their work at a desk and need no device features, a responsive web application is often enough, and you avoid the burden of store publishing, release management and maintaining two platforms. A mobile app can be added once the need is validated.
How we work
First we clarify what users do where and which device features they need. Then shared services and screen flows are designed for web and mobile. Development and testing happen on the target devices; if store publishing is needed, accounts, privacy policy and store content are prepared together. After launch, error monitoring and release management take over.
Frequently asked questions
Questions we often hear in web and mobile app projects.
Do you build the iOS and Android apps at the same time?
Usually we target both platforms from a single codebase with a cross-platform approach such as Flutter or React Native. If a very device-specific feature is needed, we write a native module for that part.
Can you build a mobile version of my existing web application?
Yes. We first assess whether your existing services and APIs are suitable for mobile and, if needed, adapt the backend together with the app.
What does app store publishing require?
It requires Apple and Google developer accounts, a privacy policy and store content. Review times are outside our control, so we leave room in the schedule.
Do you also build company-specific business systems?
Yes. Once the scope is clear, we also consider building CRM- and ERP-like modules for your specific workflow. For cases where ready-made products fall short, see our custom software page.
