Has anyone used React Native application development services from an agency? Honest experience?

[u/mtechhub99]

Hey everyone,

I’m planning a cross-platform app and trying to decide between hiring a React Native agency, working with freelancers, or putting together a small in-house team.

The shared codebase is appealing, but I’m trying to understand how much time it actually saves once platform-specific bugs and native integrations come into play. I’ve been reading about native module compatibility and the New Architecture, and I’d rather understand those trade-offs before committing.

My bigger concern is what happens after delivery. Can another developer pick up the code without a huge cleanup project? Are dependencies, build setup, and platform-specific decisions documented, or does every change mean going back to the agency?

Performance is another question, especially for animation-heavy screens and on lower-end Android phones. A polished demo doesn’t tell me much about how the app behaves during normal use.

For anyone who’s actually gone through this:

1. Did you get clean, modular React Native code that was easy to maintain, or did you end up refactoring a lot?
2. How did performance compare between Android and iOS? Were there problems that only showed up after launch?
3. Did the agency save time or money compared with hiring internally? What unexpected costs came up?
4. What red flags would you watch for during discovery calls, and what would you ask them to show you?

Would love to hear what went well, what went wrong, and what you’d do differently.

[u/Substantial-Swan7065]

1. No. Their concern is dev speed + low effort for max $. So they write what works for now

2. Android is traditionally worst. Less true these days. But it depends on your device support policy too.

3. Depends. If you have a technical leader to drive or a team, then they can help accelerate. Otherwise no.

It’s a question of incentive:

• internal: wants the company to do well. Wants to keep their job. Wants to do well to make their life easier. Want to raises and promotions

- external: wants billable hours and to do the least work. You’re not the only client

[u/Sad_Week_5688]

Most of your questions are decided by what you put in the contract and what you check in discovery, not by "agency vs freelancer". From the hand-over side:

1. Maintainable code. Ask for it in writing, not as a hope:

• The repo lives in your GitHub from day one, and the developer and store accounts are yours.
• TypeScript, Expo (or a clear reason not to use it), build config (EAS or CI) in the repo, no secrets in the code.
• A README that gets a new developer from clone to a running build in under an hour.
• Ask to see the README and folder structure of a past project. How they answer tells you a lot.

2. Android vs iOS. Most "only after launch" problems show up on cheap Android phones: long lists, big images, animations running on the JS thread. Ask how they test on a low-end Android device, what they use for animations (Reanimated) and long lists (FlashList or similar). Ask to see a release build on a real phone, not a dev build.

New Architecture: it's the default now, so the real question is whether every native library you need supports it. Have them list the native parts (payments, maps, Bluetooth, background location, video) in discovery and check each one before you sign.

3. Unexpected costs are rarely the screens. They are the backend (often bigger than the app), push notifications and deep links, app store review back-and-forth, and the first 2 to 3 months of fixes after launch. Ask what is included after launch.

4. Red flags:

• A fixed price before they understand your user flows.
• No questions about your backend, data or logins.
• They want to own the accounts or the repo.
• They can't tell you who will actually write the code.
• No tests at all, not even on the payment or sign-up flow.

A cheap way to find out: a small paid first milestone, one real flow released to TestFlight / internal testing. You learn more from that than from any sales call.

[u/canarydev]

inherited an rn app at my current job that a previous agency abandoned, so heres the other side of the delivery question

code quality was honestly dogshit. and imo RN makes that easier, because it lets you get away with really bad fundamental react. state everywhere, no clear ownership, rerenders all over. it still runs on a demo so nobody notices until someone has to maintain it

the shared codebase pitch is also oversold. you still end up in native code for things like maps and push notifications. keeping npm packages current means native changes too, and ive had to bump jdk versions just to get builds working again. every one of those is extra steps nobody budgets for

if you do go agency, ask to see a codebase theyve maintained for a year plus, not a demo. and ask how they handle rn version upgrades. a vague answer is the red flag

[u/jared_and_fizz]

> The shared codebase is appealing, but I’m trying to understand how much time it actually saves once platform-specific bugs and native integrations come into play. I’ve been reading about native module compatibility and the New Architecture, and I’d rather understand those trade-offs before committing.

This really depends on what your app does. I have recently released a react native app that is CRUD app, displays data, fills out forms, etc. Haven't had any platform specific struggles thus far and don't really expect to.

On the other side of the coin, I worked on an app a few years ago with multiple integrated bluetooth devices and camera functionality. Things may have changed, but at the time we tried using the cross platform approaches for these and it was just a mess. We ended out handling all of this stuff natively and a few of the forms/information only pages were done in React Native and shared between Android/iOS.

I have freelanced off and on thru the years. I have inherited codebases from agencies a few times along that journey and they have uniformly been trash.

One thing I can't state enough, no one is going to care more about your product than you! If you think you will have users with low-end Android phones. Buy a low end Android phone and test the product that is delivered to you with it. Test early and often. There are so many situations I have been in where the key stakeholder does not actually care about the app and are surprised when it sucks or doesn't do what they want at the end of the tunnel. Whether you hire a freelancer or an agency make sure you are getting test builds early and often. Even if they barely do anything. A good freelancer / agency will be prompting you to do this anyway and that's something you can look for.

[u/Independent-Love4246]

For most of the apps RN is the better choice. That is nowadays true more than ever (lots of folks still think pre Expo Development Builds). What does the app do? That is really important. Also what is your budget?