What building a first release actually looks like

Every first release goes through the same four stages, whichever client it's for: design, build, store review, and then the quiet part after launch that nobody puts in the proposal. Here's what each of those actually looks like, using the shape of a real mobile build — our My Tea point-of-sale app for food and beverage outlets — as the reference.

Design isn't a deliverable, it's a decision list

For My Tea, the brief was a cashier's cart on a phone or tablet that could survive a lunch rush: products and categories, outlet switching for a business running more than one location, customers and suppliers, barcode scanning, promotions, and sales reporting the owner could actually read. The design phase wasn't about producing pretty screens — it was about deciding, screen by screen, what a cashier under pressure needed to see first. A menu that looks great in Figma and takes four taps to ring up a drink is a design that failed on the shop floor.

Build means a real device, every week

This is the stage that's easiest to fake with a status update and hardest to fake with an actual build. Every week of development, whoever's paying for the app gets a build on their own phone — a TestFlight link for iOS, an APK for Android — not a recorded demo. For a POS app specifically, that meant testing barcode scanning against real product labels and real lighting, not a scanner simulator, because that's where the edge cases actually show up.

Store review is a queue, not a formality

This is the part that catches first-time app owners off guard. Submitting to the App Store and Google Play isn't a button you press on launch day — it's a review queue with its own timeline, its own questions about permissions and data use, and its own chance of a screen being sent back for a fix that has nothing to do with whether the app works. Treating it as week one of the schedule instead of an afterthought after "we're done" is the difference between a launch date and a launch guess.

The bits everyone forgets

Analytics and crash reporting wired in before launch, not after the first bug report comes in blind. A plan for who owns the developer account when the person who set it up moves on. Documentation for the person who didn't build the app but now has to run it. None of these show up in a pitch deck, and all of them show up in the first month of actually running the thing.

If you're scoping your own first release, the honest version of this list is worth more than another feature. Shape it on the homepage and we'll show you where your build sits against all four stages before you commit to anything.

KEEP READING