Launch and learn
Shipping the app is where the real test starts. This lesson shows you how to put the reorder app in front of ten partner shops as a small pilot, measure the few things that answer your questions, hear why shops do what they do, and turn each week of evidence into the next iteration.
By the end you can
- Plan a pilot with chosen shops, an end date, success measures, guardrails and a stop button
- Track five events, with the API as the source of truth for orders and an id on every event from the phone
- Collect feedback that explains the numbers: first-week visits, watching a real order, one question in the app
- Read a funnel of ten shops honestly and choose one or two changes for the next iteration
- Write the SQL for a weekly pilot scorecard
The everyday picture
A street food cook wants to add a new dish. She does not paint it on the big menu board for everyone. She cooks it for ten regulars she knows, on two quiet evenings, and she watches. Who finishes the plate? Who leaves half? Who asks for it again next week?
She asks a few of them what they thought, and she watches their faces more than their words, because regulars are polite. One says "lovely" and leaves half the rice. That tells her the portion is wrong, so she fixes the portion before she touches the recipe. After two weeks she decides: put it on the board, change it and try again, or drop it.
Launching software works the same way. The ten regulars are your pilot users. The half-eaten plates are your numbers. The faces and comments are your feedback. The decision at the end is your next iteration.
Plan the pilot before you ship it
In Continuous delivery you built a pipeline that can ship the reorder app safely. Now you choose who gets it. A pilot is the first release to real users, small enough that a mistake hurts a few people you can call. Launching: pilots, waves and the review after covers pilots and waves for big launches. Here is the version a small team can run.
Write five things down before anyone installs the app:
- Who. Ten shops, picked on purpose: four that order by phone today, four that already use the Partner app, and two in areas with patchy mobile data. The mix shows whether the app helps the shops it was built for. If you invite only keen app users, the pilot will look great and teach you little.
- How long. Shops reorder about once a week, so one week shows about one order per shop. Two weeks is the shortest pilot that can show whether a shop comes back. Put the end date in the plan.
- Success measures. Take them from your spec (From idea to one-page spec) and write them as counts: "at least 4 of 10 shops place a repeat order in the app within two weeks". Decide them now. After the results come in, almost any number can be explained as a success.
- Guardrails. A guardrail is a number that must not get worse while you chase the goal. Here: no order is ever doubled, and orders corrected after delivery stay at or below today's phone rate of about 1 in 12.
- Stop rules. What makes you pause: one doubled order, one delivery of the wrong quantity, or most shops unable to submit for half a day. A pause is cheap when it is planned.
Next, decide how the app reaches the phones. A test build goes to pilot shops through a test track: an internal testing track in the Google Play Console for Android, and TestFlight for iPhones. Apple reviews the first TestFlight build before outside testers can install it, so send that build a few days before the pilot starts. After that, a fix to your JavaScript can reach pilot phones through EAS Update without a new store build, as set up in app-06. A change to native code, such as a new permission or a new native library, still needs a new build.
Last, put the reorder endpoints behind a pilot list: a table of invited shops that the API checks on every reorder request. It does two jobs. Shops outside the pilot cannot stumble into a half-finished feature. And it gives you a stop button: mark the pilot paused, and every reorder request gets a friendly "not available yet" until you fix the problem. You build it in the Build it section.
Quick check
Imran suggests inviting the 10 shops that already place the most orders in the Partner app, because they "will give the best feedback". What is the main problem?
The app exists to move phone orders into the app, so the pilot must include shops that order by phone today. Keen app users would likely succeed with any reasonable flow. Ten shops is small, but it is enough to find the big problems in a core flow, especially when you also talk to every shop.