AI App Store Rejection to a Last-Minute Travel App Rescue
A horse-travel marketplace built with AI had working code, a hard launch date, and two app store rejections. Here is what our code audit found, and how the app went on to be approved and launched on both stores.
A horse-travel marketplace had working code, a hard launch date, and two store rejections. Here is what the audit found, and how it went on to be approved and launched on both stores.
The founders had done everything the new playbook says to do.
They used AI to build their app and their website. And it worked, the screens were there, the buttons did things, the whole product looked finished. By the standards most people judge software on, it was done.
Then Apple rejected it. Then Google rejected it. The launch date did not move.
That is when they came to us.
Here is the part that surprises almost every founder in this position, and it is the single most useful thing in this article: none of the rejections were about features. The app had the features. What it did not have were the things app stores check that have nothing to do with what your product does, and AI does not build those, because nobody thinks to ask for them.
This is the story of what we found, what we fixed, and how the app went from two rejections to approved and live on the App Store and Google Play, inside the deadline.
Stuck in a rejection loop with a deadline coming?
We audit the build, tell you exactly why it is failing, and give you a plan with dates on it. Most of the time the code can be rescued — starting again is almost never necessary.
What the platform actually is
The product is an equestrian travel marketplace: a booking platform for people who travel with their horses. It solves a real and surprisingly underserved problem. If you own a horse and want to go somewhere, you cannot simply book a hotel. You need somewhere that will take the animal too.
The platform connects travellers with hosts offering horse-friendly stays, boarding, camping and RV spots, and guided day experiences. It also layers in horse-friendly parks, so a trip can be planned around where you can actually ride.
It runs as iPhone and Android apps, with a web panel for the admin team. And it serves three completely different groups of people.
A marketplace is one of the harder things to build well, because you are really building three products that have to agree with each other at all times. If a host changes their availability, the traveller's search has to know. If a booking is cancelled, the refund and the payout both have to move. Get any of that slightly wrong and people lose money.
Why AI-built apps get rejected
AI coding tools are genuinely good at producing features. Ask for a booking screen and you will get a booking screen, often a decent one. We use these tools ourselves, every day.
What they do not produce is everything around the features, and that is exactly what app review checks. We wrote about this gap in more detail in Can AI Build Your Mobile App?, but this project is the clearest real-world example we have seen of it.
Account deletion, inside the app
Both stores now require this, and it catches almost everyone. Apple's rule is that any app which lets people create an account must also let them start deleting that account from inside the app. Offering only a "deactivate" option is explicitly not enough, and you cannot make people email support to do it. If the process finishes on your website, you must link straight to that page.
Google requires the same thing, and adds a second route: a working web link where someone can request deletion without having to open the app at all. That link has to be entered in Play Console, and the answers have to match your Data safety form.
No AI writes this unless you ask for it. Nobody thinks to ask for it, because it is not a feature anybody wants it is a requirement.
Safety tools wherever people can post
The platform has messaging between travellers and hosts, listings written by hosts, and reviews in both directions. That makes it a user-generated content app, and Apple expects such apps to ship with the means to keep people safe: a way to filter objectionable content, a way to report it, a way to block another user, and published terms that say what is not allowed.
Again, not features. Nobody writes "add a block button" on a product roadmap. The store simply will not approve the app without one.
Privacy answers that match the app
Google's Data safety form has to describe what your app really collects and what happens to it, including the data-deletion questions. An AI-generated privacy policy that says something different from what the code does is a rejection waiting to happen.
A test login that reaches everything
Reviewers need credentials that open every screen. On a marketplace with role switching, that means traveller and host, including the host dashboard, the payout setup and anything behind verification. A login that only opens the traveller side gets the app sent back.
Nothing broken, nothing left as a placeholder
Crashes, dead buttons, placeholder text and links that go nowhere each fail review on their own. This is where AI builds tend to be weakest, because the code is usually only ever run against a handful of test records on a simulator. Real handsets with real data behave differently.
Payments set up the right way
Here is the good news for marketplaces: a stay with a real horse at a real property is a real-world service, so it is paid for through your own payment provider rather than in-app purchase. But that only holds when it is set up and declared correctly, and the flow has to be complete, including refunds and cancellations, not just the happy path.
Step one: audit everything before changing anything
When a deadline is close, the instinct is to start fixing immediately. That is almost always the wrong move. You end up fixing the visible problems while the real ones stay hidden, and you find them in the next rejection.
So we read the whole thing first. This is the same approach we took on a legacy ERP rescue earlier this year, and the reasoning is identical: you cannot plan a rescue until you know what you are rescuing.
Two of those questions deserve a closer look, because they are where AI-built marketplaces most often come apart.
Can people only see what is theirs? On a marketplace this is not a nice-to-have. A traveller must never be able to reach another traveller's booking, a host's payout details, or anyone's contact information. AI-written code frequently checks permissions on the screen rather than on the request underneath it, which looks fine when you click around, and fails the moment somebody changes a number in a web address. Every single screen has to be checked against who is signed in.
Does it hold up with real data? A listing page that works with three test properties can fall over with three hundred, with photos attached, across a map view. If your product is starting to strain in ways like this, the warning signs are usually visible well before anything breaks publicly.
What we fixed, and in what order
With a deadline this tight, the order matters as much as the work.
- Anything that stops the app opening. Crashes and dead ends first, on real iPhones and real Android handsets. Nothing else counts until the app runs.
- Anything involving money. Payments, refunds, cancellation rules and host payouts, tested from start to finish including the awkward cases.
- Anything involving who sees what. Every screen and every request locked to the person signed in.
- Every store requirement, one by one. Account deletion, reporting, blocking, terms, privacy answers, test credentials, each checked off against Apple's and Google's own lists before resubmitting rather than after.
- Then the code itself. Structure, naming and documentation, so the next change is safe to make, by us, or by whoever they hire next.
That last point matters more than it sounds. A rescue that leaves you dependent on the people who did the rescue is not much of a rescue.
Getting the booking and payment flow right
This is the heart of any marketplace and the part we spent the most time on, because it is where a mistake costs someone real money.
The marketplace supports two booking styles. Instant Book confirms straight away, for hosts who have already decided they will accept bookings like this one. Request to Book lets a host review the horse profile first and then accept or decline — which matters more here than on an ordinary travel site, because a property with two stalls and no trailer access genuinely cannot host every horse.
Payments run through Stripe, with Stripe Connect handling host payouts. That means card details never touch the client's own servers, which removes an entire category of risk and a great deal of compliance work along with it.
The cancellation path is the part that gets skipped, and it is the part that generates angry emails. When a booking is cancelled, the refund has to follow the policy attached to that specific listing, the host's payout has to be adjusted to match, and both sides have to see the same numbers. We tested that path as carefully as the booking path itself.
What the platform is built with
We kept the technology choices the client already had wherever they were sound. Replacing a reasonable choice just to put our own stamp on it wastes time that a deadline does not have.
A few notes on why these choices hold up:
- React Native for both apps. One codebase producing an iPhone app and an Android app. For a marketplace where both sides need to be on the same features at the same time, that is the right trade — and it meaningfully changes the economics, which we cover in what an iOS app really costs and what an Android app costs to build.
- Node.js with TypeScript behind it. TypeScript catches a whole family of mistakes before the code ever runs, which matters a great deal on a codebase that was written quickly.
- One clean connection between apps and data. Both apps and the admin panel talk to the same place, under the same rules. That is what keeps three experiences in agreement, and it is the single most valuable thing to get right early in any product that will have more than one front end.
- Specialist jobs handed to specialists. Stripe for money, Google for maps and places, Firebase for push notifications and analytics, the National Park Service's own data for parks. Building any of those yourself would be slower and worse.
Where it started, where it shipped
The headline outcome is the one the client cared about most: the enhanced build was delivered inside the window they had. They did not have to move their launch, and they did not have to throw away what they had already paid for.
Since then, the resubmitted app has been approved by both Apple and Google, and the marketplace has launched. It is now live on the App Store and Google Play.
Have an AI-built product that will not quite launch?
This is a specific and fixable problem, and it is one of the things we do most. We will read the code, tell you plainly what is wrong, and give you a route to a submission that passes — with a date you can plan around.
What a marketplace like this should add next
Getting approved is the starting line, not the finish. Once a marketplace has real travellers and real hosts on it, the work shifts to the operational load — and that is where the next round of value sits.
Automating the repetitive work
Every marketplace generates the same jobs over and over: chasing incomplete listings, nudging hosts who have not replied, flagging bookings that need attention, reconciling payouts, preparing the weekly numbers. Each takes minutes. Together they eat a working week. We listed the most common culprits in 7 manual tasks quietly costing businesses 20+ hours a week, and nearly all of them show up in a marketplace at some point.
An assistant that answers from the real records
Travellers and hosts ask the same questions constantly, where is my booking, when do I get paid, what happens if I cancel, does this property take two horses. An assistant connected to the actual records can answer those at any hour, in the app, and hand anything sensitive to a person. The important part is that it reads live data and refuses to guess; we have written about what AI agents in mobile apps actually do well, and about what one costs to build and run.
Both of these are things we build, and both are far easier to add once the foundation is sound — which is exactly why the foundation comes first.
If you are in the same position
The lesson here is not that AI coding tools are bad. They are not, and they saved this client a great deal of early work.
The lesson is that there is a long distance between code that runs and a product that can be released. That distance is made up of unglamorous things: permission checks on every request, payment flows that survive a cancellation, a block button, a delete-account screen, a privacy form that matches reality, and the patience to test on real devices with real data. AI will not produce any of it unless you already know to ask — and if you already knew to ask, you probably would not have needed the AI.
The good news is that this is a fixable problem, and it almost never requires starting again. In most AI-built products we see, the structure is reasonable and the gaps are specific. Finding them takes days, not months.
If you are sitting on a build that will not quite launch, the first step is not a rewrite and it is not another submission. It is an honest read of what you have.
Frequently asked questions
Why do app stores reject AI-built apps so often?
Because review checks things that are not features. Account deletion, safety and reporting tools, accurate privacy answers, working test credentials and a build with no broken screens are all required, and none of them appear in a feature list. AI writes what you ask for, and almost nobody thinks to ask for these.
Do we have to rebuild from scratch after a rejection?
Almost never. In most AI-built products the structure is reasonable and the gaps are specific and findable. A rescue keeps what works, fixes what does not, and is usually far faster and cheaper than starting again — which matters enormously when a launch date is fixed.
How long does a code rescue take?
It depends on the size of the codebase and how much of it survives the audit, which is what the audit is for. The audit itself is measured in days. We give a timeline after reading the code rather than before, because any date offered earlier is a guess.
What is the account deletion requirement exactly?
Apple requires that apps supporting account creation let people start deleting their account from inside the app, with the full record and associated personal data removed — “deactivate only” does not satisfy it, and you cannot require a support call or email. Google requires both an in-app route and a working web link where deletion can be requested without opening the app, plus matching answers in the Data safety form.
Can a marketplace take card payments without using in-app purchase?
Yes. Bookings for real-world services such as a stay at a property are paid through your own payment provider rather than Apple’s in-app purchase. It has to be set up and declared correctly, and the whole flow — including refunds and cancellations — needs to work, not just the straightforward path.
Will you take over an app another team or an AI tool built?
Yes, that is a large part of what we do. We start with an audit so that both sides know what is actually there before anyone commits to a timeline or a cost.
Do we own the code afterwards?
Yes. You own the codebase, the data and the documentation. We write the handover notes for whoever maintains it next, including the possibility that it is not us.
Comments