From a sketch to your phone in a weekend

Part one found the problem in your week and ended with a sentence and a rough sketch. This part is the weekend that turns it into an app you can hold. It is a real plan, which means it also says what a weekend cannot finish.

1. Saturday morning: screens from a starter, not from nothing

Do not start with a blank screen. Start with the starter app closest to your problem and change it. A club noticeboard, a bookings diary, a menu with ordering, an inspection checklist: each one is already a working app with its tabs, its screens and its navigation in place. Changing a working thing is an hour’s work. Inventing one is a month’s.

Rename it to your own app’s name first. It sounds trivial, and it is the moment the thing stops being a template and starts being yours.

Then go screen by screen. Delete what your problem does not need. Rename the lists and buttons in the words you would actually use (“Fixtures”, not “Events”). Add the one screen the starter lacks, if there is one. Stop at five screens. The sixth is Sunday afternoon’s temptation and Monday’s regret.

2. Saturday afternoon: the arrows are the app

Between the screens, draw the arrows: this button opens that screen, this tab shows this list, this row opens its detail. In a good design tool each arrow says what kind of move it is, a tab switch, a screen that slides in, a sheet that pops up, and the built app does exactly that.

This is the part most people skip and most apps fail at. A set of screens is a slideshow. The arrows are what make it an app, and they are also the part a coding agent gets wrong most often when left to guess. Drawn, they are not a guess.

3. Saturday night: on your own phone

Before anyone writes code, open the design on your phone and tap through it. Not a video, not a picture: the screens, with the tab bar, with every arrow working. You will find three things wrong in the first minute. That is the point of doing it tonight and not after the build.

Then send the link to two of the people from part one’s Tuesday problem, the ones who kept texting you. Watch what they tap first.

4. Sunday: let the agent build the real thing

Your coding agent (the AI tool that writes software: Claude Code, Cursor and the others) takes the design and builds the actual app: a normal project in a normal framework, with your screens, your navigation and the phone’s own controls. You run one command and it is on your phone as a real app, not a preview.

What you need for this step:

• a coding agent account, which most people reading this already have;
• for the iPhone version, a Mac with Xcode, because Apple’s build tools run nowhere else;
• for the Android version, any computer.

If you have no Mac, build the Android version on Sunday and show it on an Android phone. The iPhone version can wait for a borrowed Mac. That order is normal, not a compromise.

5. What a weekend cannot do

The build is the fast part. Getting into the stores is the slow part, and it is better to know the shape of it now:

• Apple: a $99 a year developer account, and a review that takes a day when it goes well and several rounds when it does not. Most first rejections are for unfinished things: placeholder text, a link that goes nowhere, a missing privacy page.
• Google: $25 once. A new personal account must run a closed test with at least 12 testers for 14 days before the app can go public. Your two Tuesday people are the first two testers; the club is the other eighteen.

So the honest timeline is: an app on your phone this weekend, your first testers on it next week, and a store listing about a month out. Part three is about what happens when they start asking for it: keep it for yourself, give it away, or charge for it.

Start Saturday the right way: open the App Builder, pick the starter closest to your problem, and rename it before you change anything else.