One app for iOS and Android, still building next year.
We build iOS and Android apps from one Expo and React Native codebase, connected to the backend you already run: Laravel, WooCommerce or an existing API. We handle the store accounts, reviews and privacy forms, then keep the app current as Apple and Google change their requirements every year.
Who this is for, and who it is not.
A good fit if
- You run a Laravel platform, WooCommerce store or API, and customers keep asking for an app.
- Your app was built once, has not been touched since, and no longer builds or passes review.
- You need push notifications, the camera, location or offline access that a website does poorly.
- Your product has a core task people repeat often enough to keep an app on their phone.
Probably not the right call if
- Customers use you a few times a year; a responsive website or PWA will serve them better.
- The product depends on deep native work, such as custom AR, heavy audio processing or watch-first features.
- You want an app shipped once and left alone; without yearly upgrades it will stop building.
What changes for your team.
Updates reach customers on their lock screen
Order updates, bookings and reminders arrive as push notifications that open the right screen, not as emails in a crowded inbox.
One backend, one set of rules
The app, the website and the admin read the same data through the same API. Prices, stock and permissions do not drift apart between them.
Store deadlines stop being emergencies
Target API levels, Xcode versions and SDK upgrades are handled on a schedule, before the stores enforce them. The app stays listed and updatable when you need a fix out.
The parts that make it hold up in production.
iOS and Android app from one codebase
Expo and React Native in TypeScript, with navigation, authentication and the screens agreed in design. Native modules only where a feature needs them, such as camera, location or biometrics.
API on your existing backend
Authenticated endpoints on your Laravel application, the WooCommerce REST API or an existing service, or a new API where there is none. Versioned, so older installs keep working after the backend changes.
Push notifications
Sent through Apple Push Notification service and Firebase Cloud Messaging, triggered by events in your backend. Deep links open the order, booking or message the notification is about.
Offline behaviour and sync
Data cached on the device so the app opens and reads without a signal, with changes queued and retried on reconnect. We decide per screen what must work offline and what can simply say so.
Store accounts in your name
Apple Developer and Google Play Console accounts registered to your company, with signing credentials and listings you own. App Store privacy details and the Play Data safety form match what the app actually collects.
Crash reporting and release pipeline
Crash reporting wired in before the first beta, with builds on EAS Build tested through TestFlight and Play testing tracks. JavaScript fixes ship over the air; native changes go through store review.
An app in front of the system you already run.
The app is a new front end, not a new business system. Orders, accounts and content stay where they live today, and the app reaches them through an API we build or extend.
-
Where people use it L4iPhone Android phones Tablets Push notifications
-
The app L3Expo / React Native Offline cache Deep links Over-the-air updates
-
API and services L2REST API Authentication Push delivery Crash reporting
-
What you already run L1Laravel platform WooCommerce store Existing API Your database
From first call to running in production.
Each step ends in something you can look at. Scope grows after something is live, not before.
-
01
Decide app, web or both
We look at which tasks people repeat often enough to justify an install, and whether a responsive web app would do. If it would, we say so and scope that instead.
-
02
API and store accounts first
We shape the API against your backend and start the Apple and Google accounts in your company's name early. Organisation verification takes time, so it runs alongside design.
-
03
Build with testers on real devices
Builds go to TestFlight and Google Play testing tracks from the first weeks, so your team uses the app on their own phones. Crashes and feedback surface before any customer sees them.
-
04
Submit, release and maintain
We prepare listings, privacy disclosures and review notes, and deal with rejections if they come. After launch we ship fixes and the yearly SDK and platform upgrades that keep the app building.
Published prices, fixed before we start.
€1,000
delivered within a week
We read the system you already have and tell you what is actually wrong with it, what it would take to fix, and what it would cost.
€5,000 – €20,000
typical project
Fixed scope, fixed price, agreed before anyone writes code. Most of what we do sits in this band.
from €750
per month
We take the system over and keep it alive. This is the part most people discover they needed about six months after launch.
What moves the price for Mobile Apps
- How much of the API already exists, versus endpoints and authentication we have to add to your backend.
- Whether the app must work offline and sync changes back, which is more work than read-only caching.
- Native features beyond the common ones, such as background location, Bluetooth devices or custom native modules.
- Payments and subscriptions, including whether Apple and Google in-app purchase rules apply to what you sell.
What we work with
Questions we get asked.
If people use you a few times a year, a responsive website or PWA is usually the better answer: no store review, no install, one release. An app earns its place when people come back often, need reliable push notifications, or use the camera, location or offline access. On iPhone, web push only works after a user adds the site to their home screen, and many users never do.
You do. The Apple Developer and Google Play accounts are registered to your company, the signing credentials sit in accounts you control, and the code is in your repository from the first commit. We work in those accounts as invited team members, so removing us is a permissions change, not a migration. Apple asks for a D-U-N-S number to enrol an organisation, so we start that early.
Apple and Google move their requirements every year: Google Play raises the Android version apps must target, and Apple raises the Xcode version uploads must be built with. An app nobody upgrades eventually cannot ship an update at all. On a Run plan we handle Expo SDK upgrades, store policy changes, crash reports and the small changes your team asks for.
Often, yes. Changes to JavaScript, styling and images can go out as over-the-air updates through EAS Update to apps already installed. Anything touching native code, permissions or the Expo SDK version needs a new build and a store review. We use over-the-air updates for fixes, not to change what the app does behind the reviewers' backs.
Only what the features need, and we list it before submission, because both stores require privacy disclosures that match the app's real behaviour, third-party SDKs included. Tokens are kept in the device's secure storage and the app talks to your backend over HTTPS. If users can create an account in the app, Apple requires that they can also delete it from within the app, so we build that in.
