Customer apps
Booking, payments, and status connected to your own systems, with push notifications on changes.
Service / App development
Apps for employees, customers, and field work.
A good app solves something a website does not solve as well: work without coverage, camera and notifications in the pocket, or a flow employees and customers repeat daily. Aprex builds mobile apps for field teams, employees, or customers, connected to data, booking, payments, and existing systems. The choice between an app, a PWA, or a website depends on which platforms you need to cover, how deeply the solution needs to use the device, and how the workflow actually runs. This page explains when an app is right, how Aprex moves from prototype to the App Store and Google Play, and when you should choose something else.
Last updated: September 26, 2026
- 01
When does an app fit best?
Choosing between an app, a PWA, and a website comes down to which platforms you need to cover, how deeply the solution needs to use the device (camera, push, offline storage), and how the work actually happens. Aprex assesses this together with you before choosing a solution. An app fits best when users are daily and mobile, when camera, location, push, or offline storage is central to the flow, or when distribution through the App Store and Google Play brings trust and reach. A PWA can hold where needs are simpler and the install threshold should be low. A website wins when content rarely changes per user and findability in search matters most. The wrong choice here is expensive, so Aprex settles the platform question before anything is designed.
- 02
Connected to your systems
Mobile apps for field teams, employees, or customers connect to data, booking, payments, and existing systems, so the app becomes part of operations instead of another standalone tool. That means APIs, data models, and access are planned together with the app itself: which data the app reads and writes, how conflicts are resolved when the same record changes in two places, and what happens offline. Login follows business requirements, with secure session handling and roles that mirror the responsibility the user already has. Payments and booking go through established providers where possible, so sensitive card and personal data is never stored in the app itself.
- 03
From prototype to the App Store and Google Play
Aprex keeps the same quality from the first prototype through publishing on the App Store and Google Play, and follows up with operations and further development after launch. The prototype is tested on real devices with real users, because simulators hide network drops, battery use, and how the app behaves with cold fingers in the field. Before submission, store listings, screenshots, privacy statements, age ratings, and test accounts for Apple and Google reviewers are prepared. After launch, Aprex follows up with fixes, adaptation to new OS versions, and development based on actual use, not guesses.
- 04
Three concrete cases as illustration
Illustration 1: Cleaners check in with geofence at buildings, tick off room checklists, photograph deviations, and sign digitally. The office sees per-building status in real time and exports documentation to the customer. Illustration 2: Customers book appointments, pay, and get push notifications on changes, while the company calendar and CRM update automatically without manual double entry. Illustration 3: Service technicians work offline in basements and plant rooms, register measurements and spare parts, and sync when coverage returns, with conflict handling that never silently loses data. These examples are illustrations, not descriptions of customer setups.
- 05
How we work, step by step
Step 1, platform choice: Aprex settles together with you whether app, PWA, or website fits, based on device use, offline needs, distribution, and maintenance budget. Step 2, prototype: One core flow is built and tested on real devices with real users. Step 3, first version: A complete flow with login, offline support, integrations, error handling, and accessibility. Step 4, store readiness: Store listings, privacy texts, and reviewer test flows are prepared, and submission is followed to approval. Step 5, operations: Monitoring of crashes and performance, updates for new OS versions, and development against measured use. Each step has clear deliverables before the next starts.
- 06
Typical systems and integration points
Apps rarely create value alone. Typical categories they connect to are CRM and case tools for customer and order data, booking and calendar systems for appointments, payment providers for purchases and subscriptions, map services for location and routes, push services for notifications, and internal APIs and databases for operations figures. Aprex builds against documented interfaces with versioning, so the app does not break when a backend system updates. Offline storage is designed deliberately: users should always see what is stored locally and what is confirmed received.
- 07
When an app is the wrong choice
An app fits poorly when users are rare and new every time, when content is static and findability in search matters most, or when the budget cannot carry maintenance on two platforms over time. It also fits poorly when the core need is covered by a good mobile-friendly website or PWA at a fraction of the cost. Aprex will say so when the analysis points there, and suggest a website or PWA instead. An app nobody installs or maintains is worse than no app.
- 08
Proof from our own products
Aprex builds and operates apps itself, not just for customers. TapInn, which is in operation, is built for mobile field work: geofenced check-ins, checklists, images, HSE, and deviations are registered where the job happens, even on poor coverage, and flow on to follow-up and documentation. The lessons from there - offline sync, simple registration with gloves on, clear notifications - are reused directly in customer projects. Farled is in pilot with no launch date decided, and explores mobile sales flow where meetings and activity are captured where the seller is. 24AI and 24Markets are lab products showing that Aprex also masters web surfaces with continuously updated content where no app is needed.
Overview
Typical app surfaces
These are the surfaces where an app often creates more value than a website or PWA.
Field apps
Check-ins, checklists, images, and deviations for employees working in the field. TapInn is Aprex's own example of this in production.
Read more →Employee apps
Internal tools, notifications, and approvals for teams in the field or the office. See how field teams can work mobile.
Read more →Offline and secure access
Holds up on poor networks, handles secure login, and stays traceable. Read how Aprex works with security.
Read more →Push and notifications
Notifies employees or customers about status, deviations, or deadlines directly in the app.
Websites where no app is needed
Sometimes a website is the right choice. Aprex builds both and recommends honestly.
Read more →Ongoing operation
Maintenance, updates, and further development after launch, including new OS versions.
AI agency for small business (resource)
How a small business picks the right technology and AI partner.
Read more →FAQ
App development FAQ
- Do we need an app, or is a website enough?
- It depends on platform requirements, how deeply the solution needs to use the device, and how the workflow runs. Aprex assesses together with you whether an app, a PWA, or a website fits best, and says so when a website holds.
- What does app development cost?
- Scope drives the work: number of platforms, flows, integrations, and requirements for offline, payments, and operations. An internal app against one API is different from a customer-facing app with booking, payments, and two platforms. Aprex gives no fixed price without seeing the need; send a description of users, devices, and systems for a concrete assessment.
- Does Aprex build for both iOS and Android?
- Yes. Aprex builds apps for both platforms and can connect them to data, booking, payments, and existing systems.
- Can the app connect to our existing CRM or operations system?
- Yes, when the systems have APIs, exports, or other safe integration points. Integrations are clarified early in the project, before the app flow is locked.
- How does an app project start?
- Start with one clear user group and one core flow. The first version should be tested on real devices before it is extended. Read about the method Aprex uses from mapping to operations.
- Do you handle the App Store and Google Play?
- Yes. Aprex prepares store listings, screenshots, privacy texts, and test flows, follows submission to approval, and handles updates afterwards.
- What happens with new iOS and Android versions?
- New OS versions can require app adjustments. Agreed operations and maintenance cover testing against new versions and necessary updates.
- How is privacy handled in the app?
- Data minimization, clear consent where required, secure storage, and deletion on need. Location and camera are used only where the flow requires it, and users are informed. Read more on the security page.
Built for actual use
The app holds up against poor networks, bad input, and actual use in the field or with customers. Aprex apps are therefore tested on real devices with real users before launch, and operations with monitoring and updates are part of the delivery, not an add-on discovered afterwards.
Do you need an app for employees, customers, or field work?
Send a short description of the users, devices, and what the app should connect to.
Discuss your app →