Case Study2 min read503 words

Case study: plant doctor vision app — 14 days to App Store launch

Behind-the-scenes of building a plant-disease detection app from zero to App Store approval in 14 days, including the ML model swap on day 8 and the App Store review surprise.

Founder reached out wanting a mobile app that identified plant diseases from a phone photo. Two weeks before a trade show. Here is what shipped, day by day.

The brief and the cuts

Original wishlist: iOS + Android, on-device model, history feed, share to social, multi-language, freemium subscription, treatment recommendations from an LLM, user accounts.

What we cut for v1:

  • Android (added 5-7 days, founder was happy to launch iOS-only)
  • On-device model (Vision Framework was overkill; hosted API gave better accuracy)
  • User accounts (anonymous device ID + IAP receipt was enough)
  • Multi-language (English-only for trade show audience)
  • Social sharing (a "Save photo" button covered 90% of use cases)

What stayed: snap a photo, get a diagnosis, get a treatment summary, save to a local history.

Days 1-2: design and stack

React Native + Expo (founder's web team could maintain it), hosted vision model from a vendor (PlantNet API was the working choice), RevenueCat for IAP, Sentry for crash reporting.

Picked a template from one of the React Native UI kits and customized colors. Saved 2-3 days.

Days 3-7: build the spine

Camera capture → upload → loading screen → result screen → save to local DB. Hardcoded test images for the first 4 days so we could iterate on UI without burning API credits.

By Friday: full happy path working with real photos. No subscription gate yet.

Day 8: the model didn't work

PlantNet was great for wild plants, mediocre for the houseplants 80% of our users would shoot. Accuracy was 40-something percent on a test set. Unusable.

Spent the day evaluating alternatives. Settled on a different vendor with houseplant-specific training. Accuracy on our test set jumped to 78%. Acceptable.

Lesson: integrate the riskiest dependency on day 3, not day 8.

Days 9-11: subscription, polish, history

RevenueCat for a weekly subscription with a 3-day trial. Three free identifications, then paywall. History screen was an afternoon.

Spent two days on copy, error states, and loading micro-interactions. This is the part that makes a 2-week app feel like a 6-month app.

Day 12: submit to App Store

Submitted. Got rejected the next morning. Reason: subscription terms language was missing from the paywall screen.

This is the boring, almost-always-happens rejection. Fix took 30 minutes; resubmitted Tuesday morning.

Day 13: approved

Approved within 24 hours of resubmission. Shipped to TestFlight, then live.

Day 14: trade show, first 200 downloads

Founder did the trade show with a QR code linking to the App Store page. 200 downloads in two days, 12% trial-to-paid conversion. Better than expected.

What I'd do differently

  • Integrate the vision API on day 1, not day 8.
  • Build the App Store metadata draft on day 5 so review submission is just a click.
  • Cut the history screen entirely. Nobody used it in week 1.

Total: ~70 hours of build time. Founder paid me a fixed-price 2-week sprint. App is still live, still profitable. Sometimes 14 days is enough.

Frequently asked

Common questions

Can a vision app really ship in 14 days?
If the ML model is hosted (no on-device training), the design is template-based, and the founder is decisive about scope cuts — yes. The constraint is usually App Store review (1-7 days), not build time.
Work with me

Need this built rather than read about?

I'm a solo developer who scopes, designs, builds and deploys the whole thing. Send a few sentences about your project and you'll get an honest read on scope, timeline and price — usually the same working day.

Written by
Oxymore

Oxymore is a one-person studio shipping MVPs, landing pages, React apps and Telegram bots for founders who would rather move than meet.

Last updated