React Native: One Codebase, Two Platforms

• Release vs debug parity

  Hermes, minification and native module linking behave differently in release builds; most “works on my machine” crashes live here.

• Build pipeline

  Expo EAS profiles (development, preview, production), environment variables and secrets, signing credentials for iOS and Android, and a CI run that reproduces the store build.

• Dependencies

  Libraries with native code (chat, payments, maps, push) that lag behind the current React Native version or the New Architecture.

• Upgrade path

  A staged move to a supported React Native and Expo SDK version, with a smoke-test checklist per step.

• Handover

  Written notes on structure, build commands and known risks, so another team can pick the project up.

You get the findings in writing before we change anything, and the fixes are scoped from them.

• 

  Fitblast - live in both stores

  React Native and Expo on the front end, Python (FastAPI) and PostgreSQL on the back end. On the App Store since October 28, 2025, and on Google Play.

  Read the Fitblast case

• Live in both stores

  On the App Store since October 28, 2025, and also live on Google Play: the MVP shipped in both stores.

• Stack

  React Native and Expo on the front end, Python (FastAPI) and PostgreSQL on the back end, OpenAI API with LangChain for plan generation, and vector search for exercise matching.

• One team, start to finish

  Design, development and QA from one team: a project manager, a team lead, mobile and AI/backend developers, a UI/UX designer and a QA engineer.

“The Kultrix team brought our idea to life faster and better than imagined. They built a living product that understands and motivates people. The AI logic feels like real coaching magic!” - Laurent D., CEO of Fitblast

• React Native and Expo SDK upgrades

  Staged moves to a supported version, one step at a time, with a smoke-test checklist per step so a release never depends on one big jump.

• Crash and performance monitoring

  Crash reporting wired to both stores’ builds, so a failing release shows up in a report before it shows up in reviews.

• Dependency patches

  Regular updates of libraries with native code (push, payments, maps, chat) and security fixes, checked against the current React Native version.

• Maintenance and support terms

  An agreed response window and scope for fixes and small changes after launch, written down before the work starts.

If the app was built by another team, we begin with the audit described above and take over the upgrade path from there.

• Offline-first apps

  The app keeps working without a connection: local storage, a sync queue and a rule for resolving conflicts when the device reconnects. Offline mode is scoped as its own module, typically 40-90 hours.

• Commerce and checkout

  Cart, checkout and payouts through a payment provider, with server-side validation of every transaction.

• AI features through an API

  The app calls an AI backend instead of running models on the phone. In Fitblast, a Python (FastAPI) service uses the OpenAI API with LangChain to build workout plans, and the React Native app shows them.

• Backend and API integrations

  We connect the app to your existing REST API or a new Python or Node.js backend, and agree the contract before screens are built.

Fitblast is the project behind the AI example above; the other types are described as our approach, not as published cases.

• Do they ship release builds, not only demos?

  Ask how the app is built and signed for the stores. We use Expo and EAS profiles for development, preview and production, and a CI run that reproduces the store build.

• Who owns the repository?

  The source code should live in your repository, not behind the agency. Ask for access from the first week and a written handover of structure, build commands and known risks.

• What happens after launch?

  React Native and the Expo SDK move on every few months. Ask who does the upgrades and crash monitoring, and on what terms. Ours are agreed in writing before the work starts.

• Who is on the team?

  Design, development and QA from one team, led by a project manager, as on Fitblast: mobile and backend developers, a UI/UX designer and a QA engineer.

• Can you open something they shipped?

  Ask for live apps and a client voice. Fitblast is in the App Store and on Google Play, and its founder says on the page what working with us was like.

Give two or three companies the same one-page brief; the differences show in the questions they ask back.

• Agency

  Design, development, QA and project management in one team, so one person leaving does not stop the project. Fits a product that needs to go from idea to both stores. Costs more process than a single freelancer.

• Freelancer

  One person, a fast start, good for a small and well-defined scope. The risk is a single point of failure: no second developer, no QA or designer, and the project depends on one calendar.

• In-house team

  Full control and long-term product knowledge. It takes time to hire, needs steady work for the people you hire, and needs someone who has shipped React Native to the stores before.

An agency can ship the first version and hand the code to your own team later; written handover notes make that possible.

• A 30-minute call first

  You describe the app and the device features it needs, such as camera, biometrics or Bluetooth. No payment and no commitment at that stage.

• A written scope with hours

  The estimate comes back as hours per module, a timeline and a budget range, built from tracked hours on past projects. You can change the module list and see how the hours move.

• Typical timeline

  A mobile MVP with accounts, payments, content and an admin panel is 370-750 hours over 7-14 weeks. Put your own modules through kultrix.com/cost-calculator.

• Working across time zones

  We agree the working-hours overlap with you before the start and send a written weekly update.

The calculator shows hours and weeks; the budget range comes with the written scope after the call.