10 signs your mobile app is badly built

You can spot a badly built mobile app without reading a line of code: it crashes or freezes more often than Google Play's thresholds allow, every small change takes weeks, fixes break something else, and you do not control the code or the store accounts. One sign on its own is not a verdict; three or four together usually point to real technical debt, which an audit can measure before you decide whether to fix, upgrade or rebuild.

This article is for non-technical founders and product managers who suspect that their app, built by an agency, a freelancer or a no-code or AI tool, has problems. The thresholds quoted here were checked against official documentation as of October 2026.

How can you tell if a mobile app is well built without reading the code?

You can judge a mobile app without reading the code by looking at three things: how it behaves for users (crashes, slowness), what it costs to evolve (lead times, regressions) and how much control you have over it (access, versions, tooling, security). Each of the ten signs below can be checked with access to the store consoles or a single question to your developer.

Good code is invisible: you notice it mostly through the absence of bad surprises. A badly built app always gives itself away, either with your users or on your invoices.

What are the 10 signs of a badly built mobile app?

The ten signs of a badly built mobile app are crashes, slowness, expensive small changes, regressions, no tests, no access to the code and accounts, a framework far behind, store warnings, missing tooling and security flaws. For each one: what it means, how to check it, and how serious it is.

1. The app keeps crashing or freezing

What it means. A crash closes the app abruptly. An ANR (Application Not Responding) is a freeze: the app stops responding and Android offers to close it. Frequent crashes point to unhandled errors or memory problems.

How to check. In Play Console, open Android vitals. According to Play Console Help, the bad behavior threshold is reached when at least 1.09% of daily users experience a user-perceived crash, or 0.47% an ANR, across all devices (8% on any single phone model). On iPhone, according to the Xcode documentation, crashes from TestFlight users and from App Store users who share their data show up in Xcode's Crashes organizer.

Severity: high. According to the Android vitals page, above these thresholds, assessed over 28 days, Google Play may reduce the app's visibility and show a warning on its store listing.

2. The app is slow to start or to load screens

What it means. A slow app loads too much at startup, makes too many server calls or renders poorly optimized lists. It is often the first symptom of a fragile architecture.

How to check. Time the app's launch on an entry-level phone. The App startup time page of Android vitals considers a cold start (app fully closed) of 5 seconds or more, a warm start of 2 seconds or more and a hot start (app still in memory) of 1.5 seconds or more to be excessive.

Severity: medium to high, depending on whether the slowness affects a secondary screen or the main flow (sign-up, checkout).

3. Every small change takes weeks and costs a lot

What it means. Changing a label or adding a field should take hours, not weeks. When every detail comes with a heavy quote, the code is often duplicated, tangled, or nobody dares to touch it.

How to check. Over three months, log simple requests and their actual lead time until release. Ask why a minor change takes so long: a precise answer ("this field exists in four screens, each written differently") is already a diagnosis.

Severity: medium, but growing: this is the cost of technical debt, paid on every change.

4. Every fix breaks something else

What it means. A regression is a feature that used to work and stops working after an update. Frequent regressions mean the parts of the app depend too much on each other and nobody checks the whole before releasing.

How to check. Go through user feedback on recent releases: do the same bugs keep coming back?

Severity: high. Every release becomes risky, which pushes the team to release less often.

5. There are no automated tests

What it means. Automated tests are programs that check the app still works after each change. The React Native documentation distinguishes static analysis, unit, integration, component and end-to-end tests, and recommends keeping end-to-end tests for vital flows such as authentication and payments. Without tests, everything relies on manual clicking, which is rarely complete.

How to check. Ask: "How many automated tests do we have, and do they run on every change?" A vague answer counts as a no.

Severity: medium. It is not a bug in itself, but it often explains signs 3 and 4.

6. You have no access to the source code or the store accounts

What it means. If the code lives only with your developer and the app is published on their account, you do not really own your app: you cannot switch providers or ship an urgent fix.

How to check. Make sure you have access to the full Git repository, that the app is published on your own Apple and Play Console accounts, and that you know who holds the Android signing key. According to the Android documentation on app signing, without Play App Signing, losing that key prevents you from publishing any update, and Google cannot recover it. An app published on someone else's account can be transferred (App Store Connect, Play Console), with the agreement of both accounts.

Severity: critical. It is the one sign that can make an app impossible to maintain, regardless of code quality.

7. The framework is several versions behind

What it means. The framework (React Native, Expo, Capacitor, Flutter) and its libraries move constantly; an app that is never upgraded builds up a gap that has to be paid off all at once. According to the React Native Releases page, the team only supports the latest three minor series; as of October 2026, 0.84 and everything before it are marked unsupported. Since 0.82, the New Architecture is also mandatory (see our article on the React Native New Architecture).

How to check. Ask which version of React Native or Expo the app uses and when dependencies were last updated. An app on React Native 0.6x or 0.7x runs on a version that has been unsupported for a long time.

Severity: high. The app still works, but the gap eventually blocks releases (sign 8).

8. Apple or Google are sending you warnings

What it means. The stores raise their technical requirements regularly; an app that does not keep up stays online but can no longer be updated. According to Android Developers, since August 31, 2026, new apps and updates must target Android 16 (API 36), with a possible extension until November 1, 2026, and an existing app targeting Android 14 or lower is no longer offered to new users on newer devices. According to Apple's Upcoming requirements page, every app uploaded to App Store Connect has had to be built with Xcode 26 since April 28, 2026.

How to check. Look at the Play Console inbox and the emails received by the Apple account holder. Our article on the Google Play API 36 block walks through what to do.

Severity: high to critical: the day an urgent fix is needed, it can no longer be shipped.

9. No staging, no automated builds, no crash reporting

What it means. A staging environment is a copy of the app and server where changes are tested before production. Automated builds and deployment (CI/CD) produce and check every release the same way. A crash reporting tool surfaces errors with their context. Without them, changes are tested directly on your users.

How to check. Ask where the team tests before releasing, how a release is built, and which tool alerts them when the app crashes. If the answer is "users tell us", the sign is confirmed.

Severity: medium. This is quick to set up, but its absence says a lot about how rigorous the project is.

10. Secret keys or data are exposed

What it means. A mobile app is a file anyone can download and take apart. The OWASP Mobile Top 10 ranks improper credential usage first and recommends never hardcoding credentials in the app's code or configuration files. This is common in Lovable or Bolt apps built on Supabase: according to the Supabase documentation, the publishable key can be exposed because Row Level Security (the rules that filter data access row by row) limits what it can reach, but the secret key (service_role) bypasses those rules and must never ship in a published app.

How to check. Ask where API keys are stored and whether Row Level Security is enabled on every table. Also try the simple test: can a signed-in user see another user's data by changing an ID?

Severity: critical. A personal data leak puts your own liability on the line, well beyond technical quality.

What table can you use to assess your app?

This table summarizes the ten signs of a badly built mobile app, how to check each one and how serious it is, for a first diagnosis in about an hour.

A single critical sign justifies acting quickly. Three or more high-severity signs usually point to a structural problem rather than a run of bad luck.

Does a badly built app need to be rebuilt from scratch?

A badly built app does not necessarily need a rebuild: targeted fixes, a framework upgrade and minimal tooling are often enough. A rebuild becomes reasonable when several deep problems add up: unstructured code, no tests, a very old framework and every change priced out of proportion. Rebuilding "on principle" is expensive and introduces new bugs; the decision should rest on a review of the code, not on a hunch.

When should you get your mobile app audited?

You should get a mobile app audited as soon as a critical sign appears, or three or more signs add up, and before any costly decision:

• before signing a quote for a rebuild or a migration;
• when switching developers, to know the real state of what you are taking over;
• after a warning from Apple or Google;
• before a fundraise or an acquisition;
• when an app built with a no-code or AI tool starts getting real users.

An independent audit has one advantage: whoever writes it did not write the code and has no stake in defending it.

If several of these signs apply and the project has already gone off track, our guide Failed app rebuild: what to do now? covers the first steps, and Rebuild your app from scratch or save it? helps you choose what comes next.

Getting support

If several of these signs apply to you, GUIGUI Tech's App Rescue Audit costs €1,500 excl. VAT and is delivered in 5 business days, for a React Native, Expo, Capacitor, Ionic or Cordova app, a React, Next.js or Vue.js web app, or code generated with Lovable or Bolt: access recovery, review of the code and architecture, a quick security check, the state of dependencies and store compliance, a costed verdict (save, partly rebuild or start over), a PDF report and a one-hour debrief call. Its price is deducted from work confirmed within 30 days.

Depending on the findings, the Expo SDK & New Architecture Upgrade (from €6,500 excl. VAT, 2 to 4 weeks) or Google Play and App Store Compliance (from €2,500 excl. VAT, 1 to 3 weeks, even if your developer is gone) may follow. If your React Native app works and only needs a version upgrade, the React Native audit is enough. For a Lovable or Bolt app where security is your only concern, the Lovable security audit costs €1,200 excl. VAT, in 3 business days.