Launching an On-Demand App: Your First 90 Days

The app is live. Now the real work starts

When the apps are approved and the admin panel is live, most founders feel the job is nearly done. It is not. In the AI era, getting an app built is the easy part; plenty of people can do it. The first 90 days decide whether you have a business: whether you can sell, bringing money from customers' pockets into yours, and whether you can operate, with supply online, support answering and cash under control.

Here is the uncomfortable truth. If you spent nearly all your money on the build and have little left for these 90 days, you are already in trouble. Launch promos, driver guarantees, support staff, maps and OTP bills all start on day one, and revenue starts slowly. When the money runs out in month two, the app you paid for, from us or anyone, creates no value. The company closes, and you are left demotivated by a failure that was decided before launch.

So before the plan, one question: how many months can you fund operations and marketing from today, with no revenue at all? If the answer is under three, fix that before you press "publish".

What history teaches about launching

Andrew Chen calls this the cold start problem. In an excerpt from his book The Cold Start Problem published in Lenny's Newsletter, he describes the "atomic network": the smallest network that can sustain itself. For early Uber that was not a whole city, but specific moments such as demand at a particular train station at a particular time. Only once rides happened reliably there did the network expand to the wider San Francisco area.

DoorDash started similarly small. The Stanford Daily reported in September 2013 that the company, then called PaloAltoDelivery.com, served only Palo Alto and Mountain View, had grown from four to 30 drivers, and that the founders had made a couple of hundred deliveries themselves before joining Y Combinator.

The lesson: go narrow, go dense, and do things by hand.

Reality check before you spend a dollar on launch

Answer these before you spend on promos or ads. Vague answers are the most common reason launches fail.

1. How many months of runway do you have after launch? Good answer: at least six months of supply incentives, support salaries, servers and marketing, in the bank, not promised.
2. Who will run operations when you are not there? Good answer: a named operations lead who onboards supply, handles complaints, watches the dashboard and reconciles cash every day.
3. How will you get your first 100 paying customers? Good answer: a specific zone, specific places (offices, campuses, housing complexes) and the person doing the selling, with a capped promo budget per customer.
4. How will you get your first 30 to 50 drivers, couriers or restaurants, and keep them? Good answer: where you will recruit, what they will earn per hour, and when they get paid.
5. What is your contribution per order after promos, payment fees, maps and OTP? Good answer: you know the number, and you know when it turns positive.
6. Who answers a customer at 10pm when an order goes wrong? Good answer: a staffed support channel with a target response time in minutes.
7. What will make you stop, shrink or change course? Good answer: written thresholds, such as fill rate or cash left, decided before emotions get involved.

The 90-day plan at a glance

Pre-launch: supply first

In most on-demand markets the supply side is harder to get and harder to keep. Riders download an app in seconds; drivers have to be persuaded, verified, trained and kept busy enough to stay.

• Ride-hailing: drivers (car, motorbike, auto-rickshaw) with valid documents.
• Food delivery: restaurants and couriers. Restaurants bring choice; couriers bring speed.
• Home services: verified providers with clear skills, prices and availability.
• Super apps: do not launch every service at once. Pick the most frequent use case and build its supply first.

How to recruit:

• Go where they already gather. Taxi and motorbike stands, restaurant clusters, hardware markets, trade associations.
• Make onboarding easy but real. Collect documents in the app, verify them properly, and train people on how the app works and how they get paid.
• Offer a clear, honest deal. Commission, payment schedule, dispute handling. A launch guarantee (for example a minimum hourly earning during launch hours) is common, but only promise what you can fund.
• Set up restaurants properly. Menus with photos and correct prices, preparation times, opening hours and a person who answers the tablet.

Technical pre-launch tasks:

• Test on the cheapest phones and weakest networks your users have.
• Confirm push notifications, OTP and payment gateways work in production, not only in test mode.
• If you publish from a new personal Google Play developer account, Google requires a closed test with at least 12 testers opted in for 14 continuous days before you can apply for production access. Build that into your calendar.
• Prepare support scripts and a refund policy before the first order.

Days 1–30: soft launch in one zone

Pick the zone. Small enough that supply can reach any customer quickly: a university area, a business district, a cluster of dense neighbourhoods. Limit the service area in your admin panel so customers outside see a polite "coming soon" and can leave a contact.

Pick the hours. Do not cover 24 hours on day one. Launch during peak demand (lunch and dinner for food, commute times for rides) and make sure supply is online then. A small zone that works beats a big zone that disappoints.

Price simply. Customers should understand the price at a glance. Avoid launching with complicated surge rules. If you use rider-proposed fares, show a recommended price so offers are realistic.

Promos that build habits. Cap first-order discounts so cost per new customer is predictable; use second- and third-order offers, because the second order is where habits begin; time offers to your launch hours; and avoid unlimited free delivery, which trains customers to wait for discounts.

Do things that don't scale. Call your first customers after their order. Ride along with drivers. Sit in a restaurant kitchen during a dinner rush. Every failure you see in person in month one is one you fix before it costs you a thousand customers.

Days 31–60: tune the machine

Build the referral loop. Customer to customer: a credit for both sides when the friend completes a first order. Supply to supply: drivers, couriers and providers recruit others like them, with the bonus paid after the recruit completes a set number of jobs to block fake sign-ups. Track which codes produce customers who come back, not only sign-ups.

Local marketing. Partner with offices, universities, shopping areas and residential complexes. Use restaurant partners' own customers through table cards, bag inserts and social posts. Target ads at your zone only, in local languages.

Operations and support.

• Response time is a product feature. A missing order needs an answer in minutes, not days.
• Write down every incident and its fix. This becomes your operations manual.
• Watch for fraud early: fake accounts claiming promos, collusion between drivers and riders, cash not handed over.
• Pay supply on time, every time. Late payouts are the fastest way to lose drivers and restaurants.

Days 61–90: expand carefully

Expand only when the first zone works: customers can usually get served during launch hours, repeat orders are rising, and supply earns enough to stay without heavy subsidies. Then add an adjacent zone so supply can move between them, or extend hours in the existing zone, and reuse the playbook. Expanding to a new city before the first zone works multiplies the problems, not the revenue.

Insider tips for the first 90 days

Support where your customers already are. In many markets that is WhatsApp. A shared WhatsApp Business number or a helpdesk connected to it, staffed during launch hours, often beats an in-app ticket form nobody checks.

Have an OTP fallback. If login depends on one SMS route and it fails, nobody can sign up during your launch. Keep a second channel ready, such as WhatsApp OTP or a backup SMS provider, and test both in production.

Check Google Sign-In after your first Play Store release. With Play App Signing, Google signs the app delivered to users with its own app signing key, and Google's help page says you must register that Google-held key's fingerprint with your API providers. If your login or maps keys only know your upload key, features can work in testing and fail for real users. Copy the SHA-1 from Play Console and register it before you market.

Monitoring and backups before day one. Uptime alerts on the API and admin panel, crash reporting on the apps, and daily database backups copied off the server. A two-hour outage during your launch dinner rush costs more than a year of monitoring.

Reconcile cash daily. In cash-heavy markets, drivers and couriers collect money on your behalf. Settle balances every day while volumes are small; a week of unreconciled cash becomes a dispute you cannot resolve.

Freeze features for 30 days. Fix bugs and operations first. A new feature during soft launch adds risk exactly when you need stability.

Metrics to watch every week

In a well-known 2020 essay, Andreessen Horowitz listed 13 metrics for marketplace companies, starting with match rate, market depth and time to match, and including take rate, unit economics and retention cohorts. Lenny Rachitsky calls fill rate the ultimate measure of marketplace health. Put these on one weekly dashboard:

Measure retention by cohort (customers who joined in the same week), not one blended number, or growth will hide churn. Early lifetime value is a guess; use it to compare channels, not to justify heavy spending.

Common failure modes

• Spending the launch budget on the build. The app is ready; the money for drivers, promos and support is not.
• Marketing before supply. Customers see no drivers or a long wait, and do not come back.
• Launching city-wide. Supply is spread so thin that every area is a bit bad.
• Subsidies with no exit plan. Discount-driven orders disappear the day discounts stop.
• Ignoring supply economics. If drivers cannot earn enough per hour, they leave and fill rate collapses.
• No one in charge of operations. The founder is in meetings; complaints go unanswered.
• Changing everything at once. Change prices, zones and promos in the same week and you will not know what worked.

Your first-90-days checklist

• At least six months of operations and marketing funded before launch
• A named operations lead accountable for daily supply, support and cash
• Supply recruited, verified and trained in the launch zone before customer marketing
• Service area limited to one zone and launch hours staffed
• Payments, OTP (with a fallback) and push notifications tested in production
• Store accounts set up, Google Play testing completed and the Play signing SHA-1 registered
• Monitoring, crash reporting and off-server backups live
• Support channel, scripts and refund policy ready
• Simple pricing and capped launch promos configured
• Referral programmes live by week five or six
• Weekly dashboard: fill rate, time to match, cancellations, cohort retention, CAC, contribution per order, runway
• Written criteria for expanding, shrinking or stopping

When Joldisoft is, and is not, the right partner

We build the apps, and we have learned that the launch plan matters as much as the code. The admin panels we deliver let you limit service zones, set hours, configure promos and referral bonuses, and see orders and cancellations without a developer.

But we do not build for everyone. We work with founders who come with validated demand, a sales and marketing plan for their first zone, an operations budget and runway for these 90 days and beyond, and someone accountable for running the business when the founder is not in the room. We ask these questions before we take a project because we want long-term partners whose businesses grow, not apps that go quiet in month three.

If you have those in place and want a second opinion on your first 90 days, or an MVP built around this kind of plan, talk to us. If you do not have them yet, the best advice we can give is to fix that before you spend on any developer. The founders who succeed are rarely the ones with the most features. They made one small area work very well, then did it again.