Mobile apps

Mobile apps your teams actually open.

As a freelance process engineer, I build custom mobile apps, iOS and Android from a single React Native codebase, for SMBs with a real operational need: field teams, B2C customer apps, companions to an existing online service, startup MVPs.

I start by observing how your people actually work, not by drawing screens. At the end, the source code, documentation and store accounts are in your name.

When a mobile app makes sense

A mobile app isn't a better website.

It makes sense in three cases: your team or customers open the tool several times a week; you need the phone itself (camera, GPS, barcode scanning, notifications); or usage conditions require it (field work, hands full, no network zone).

Outside of those, a well-built website is enough, and costs 3 to 5 times less.

The use cases

What I build (and for whom).

01

Internal ops apps for field teams

Drivers, delivery teams, technicians, mobile sales reps. People working on their feet, in a vehicle, or on a client site.

Example: Dispatch, the driver app I built for a mobility startup (React Native + Firebase + n8n). GPS tracking, real-time rides, live status.

02

B2C customer apps

Brands with a loyalty program, a catalog, or a customer account that justifies an app over just a mobile site.

Typical case: retail with digital loyalty card, in-store scanning, targeted promo notifications, offline-accessible purchase history.

03

B2B SaaS companion apps

You already have a working web SaaS, and your users want a mobile app for fast actions (notifications, validations, quick access).

Typical case: document management SaaS adding an app to sign from a phone, or get an alert when a signature comes in.

04

Startup MVPs (market validation)

You're testing a product before a fundraise or heavier investment. The app must prove measurable traction in 3-6 months, without overspending.

Approach: minimal scope validated with you, build in 4-6 weeks, analytics from day 1 to measure real usage before extending.

Tech stack

React Native by default. And why.

I build with React Native + Expo by default. The rest of the time, I point you toward Flutter (partner specialist) or propose a PWA if the need doesn't require a true native app.

React Native + Expo

  • → One TypeScript codebase for iOS + Android
  • → Full access to native features (camera, GPS, push, biometrics)
  • → One codebase instead of two (Swift + Kotlin)
  • → Build and store deployment via Expo EAS
  • → If you have a Next.js site I built: shared code (auth, API, types)

What I don't do

  • → Gaming or heavy 3D apps (Unity/Unreal are better suited)
  • → Ultra-custom UI with complex animations (Flutter is better)
  • → Apps needing undocumented proprietary Swift/Kotlin SDKs
  • For these cases, I refer you to a specialist in my network.

How I structure the project

Four steps. Always in this order.

01

Map

2 days observing the actual flow. Who uses the app, in what context (standing, walking, driving), for what decision. Identifying screens that have no reason to exist. Without this step, we build 12 screens instead of 5.

Deliverable · User flow map + list of screens to build (and screens to skip)

02

Optimize

No Figma stage. I code the key screens directly as a clickable prototype, installed on your phone via Expo Go in 48-72h. Validation with actual users (not just the decision-maker). The criterion isn't aesthetics: it's the tap count to complete the main action. A successful ops app stays at 2-3 taps per action.

Deliverable · Clickable prototype coded on your phone (Expo Go) + scenarios tested with 3-5 target users

03

Build

2-week sprints. End of each sprint: demo of what actually works on a phone (not just in a simulator). You test in hand between sprints. No surprise at launch because we don't wait until the end to show.

Deliverable · Testable app installed on your phone at the end of each sprint (TestFlight iOS, Play Console internal Android)

04

Ship

App Store + Play Store submission (3-7 days Apple review, faster on Google). Analytics setup. 2h training for internal users. 3-month follow-up included for bugs and first adjustments from the field.

Deliverable · App published on both stores + analytics dashboard + user manual PDF

Case study

Dispatch · Driver app for a mobility startup.

Complete ecosystem: React Native / Expo app for drivers (Android), web dashboard for admin, n8n automations for communication flows, Firebase backend for real-time. GPS tracking, live ride management, multi-channel communication (in-app + SMS + email).

App designed for driver use (large buttons, minimal taps, critical info visible). Repetitive tasks automated to free up the admin.

Read the full case study

Pricing

Custom quotes. Here's why.

I don't publish entry prices. A simple app (3 MVP screens, no backend) is nothing like a working app (auth + custom backend + integrations + store submission). Posting "from €4,990" would be honest for a few projects and misleading for most.

Indicative ranges (non-binding)

  • Simple MVP · 3-5 screens, 1 business function, no custom backend · 4-6 weeks
  • Working app · auth + Firebase + push + 8-12 screens · 8-12 weeks
  • Complex app · multi-role, third-party integrations, store submission · 12-20 weeks

Process: free 30-min express audit → scope definition → detailed quote within 5 business days → 30% deposit / 60% on delivery / 10% on handover. All invoices VAT-exempt (French small-business scheme, article 293 B of the CGI).

Frequently asked

Everything I get asked before signing.

React Native, Flutter, or PWA: what's the difference for my project?

Three techs for three different uses. **React Native** (my default): one JavaScript/TypeScript codebase for iOS + Android, full access to native phone features (camera, GPS, push notifications, biometrics). My default choice for an SMB app. One codebase instead of two: less development, a single maintenance track. **Flutter** (Google, Dart language): better performance for custom UI with heavy animations, but further from the web ecosystem. I point you to a Flutter specialist if your need justifies that stack. **PWA** (Progressive Web App): your website installable on the phone home screen. No app store, limited iOS push notifications (Apple still blocks most). Good for an ultra-fast MVP or an app used only occasionally. My rule: we pick the tech after the diagnosis, not before.

How long does it take to deliver a mobile app?

Between 4 weeks (simple MVP) and 16 weeks (complex app with custom backend). **MVP 3-5 screens, 1 business function, no custom backend**: 4-6 weeks. **Working app 8-12 screens, auth + Firebase backend + push notifications**: 8-12 weeks. **Complex multi-role app, third-party integrations, store submission**: 12-20 weeks. Every 2-week sprint, you get a testable version on your phone via TestFlight (iOS) or Play Console internal (Android). No waiting until the end to see what's being built.

Should I publish on the App Store, Play Store, or both?

Both in most cases, unless a specific need. App Store (iOS): smaller audience than Android in France, but users with a higher average basket. Apple review with strict rules, to plan for in the schedule. Play Store (Android): most smartphones in France. Less friction on editorial rules. Exception: internal ops app deployed only on Apple or only on Google, without going through public stores (distribution via MDM or TestFlight / Play Console internal). Possible and sometimes faster.

How do I keep control after delivery?

The source code is yours, on your GitHub, with full documentation. What you get at handover: - GitHub repo with admin access - Technical documentation (architecture, stack, dependencies, build commands) - Apple + Google developer accounts (in your name, not mine) - Basic update manual (changing text, color, adding a simple screen) - 3-month follow-up included for critical bugs and first adjustments If you want to manage maintenance in-house after 3 months: your dev can take over. If you want me to continue: monthly maintenance plan quoted separately (store updates, fixes, small improvements).

Do I need a dedicated backend for a mobile app?

Depends what the app does. Three typical cases. **No backend needed**: app consuming only public data (third-party APIs, static content). Rare in practice. **Firebase (Google) is enough**: needs authentication, real-time database, push notifications, file storage. Covers most common SMB needs, with no backend to build from scratch. **Custom backend needed**: complex business logic, multiple integrations, full data control (strict GDPR, regulated sectors). We go Next.js API routes or a dedicated Node server, hosted on Vercel or a European VPS. The choice happens after the diagnosis, not before.

Do you work remote or on-site?

Both depending on the project, with a remote preference for the build phase. **Diagnosis and field observation**: on-site is ideal for internal ops apps (drivers, technicians). I spend 1-2 days on-site to see the real flow, talk to users, understand physical constraints (gloves, sun, cracked screen, dead battery). This step doesn't happen on video. **Design + build phase**: 100% remote. 2-week sprints with video demo at the end of each sprint. You test the app between sprints on your phone. **Launch + training**: on-site if needed (group user training). Otherwise, video training + PDF manual. Travel possible: Paris, Île-de-France, Lyon, Bordeaux for France · Kinshasa and Francophone Africa per mission.

Amina Ouadday

Amina OuaddayProcess & AI engineer · I'm the one you'll talk to

Shall we talk about your app project?

30-minute free express audit. We look at whether an app really makes sense for your need, and if so, which of the 4 use cases fits. You leave with a clear picture.