From idea to app: the first two weeks

In the first two weeks of an app project, almost no code gets written. You decide what the app does, who it's for and in what order, you sketch the screens, and you open the app store accounts. It feels slow, but it determines how much gets rebuilt later.

Days 1–3: one problem, one person

The first conversation isn't about buttons. It's about three questions:

1. Who uses the app? Your end customers, your staff, or both?
2. What does that person want to do most often? Book an appointment, place an order, check stock.
3. How do they do it today, without an app? A phone call, WhatsApp, an Excel sheet?

The third answer is the most useful. If booking today takes four messages and a phone call, we know exactly what the app needs to cut out. That conversation produces one sentence we put at the top of the document: "The app lets customers book their own appointments without calling." Anything that doesn't serve that sentence goes on the later list.

Days 4–6: the main flow and the screen list

We map the user's path through the app, step by step, from opening it to getting the job done. For a booking app, for example: pick a service, pick a day, pick a time, leave a name and phone number, get a confirmation.

The screen list comes out of that path. A good first version usually has few: the screens in the main flow, the account, settings, plus the admin panel where you see and edit the data. Every extra screen means design, code, testing and upkeep, so the list gets discussed with a pencil in hand.

This is also when you decide where the app starts: iOS, Android, both, or a web app. We wrote separately about choosing between iOS and Android; in short, what matters is which phones your users have, not which one you have.

Days 7–10: a prototype you can tap through

From the screen list we build a clickable prototype: designed screens linked together that you can tap through on your phone like a real app, with nothing running behind them. It takes days, not weeks, and it's easy to change.

You hand the prototype to two or three people who will actually use the app and ask them to do something specific: "Book an appointment for Thursday afternoon." You don't explain anything. You watch where they hesitate. A fix at this stage takes an hour of design work; the same problem found after the app is built takes a round of development.

Meanwhile: the store accounts

This is the part almost everyone forgets, and it can push a launch back by weeks. Open the developer accounts in your company's name, so the app belongs to you.

• Apple requires a D-U-N-S Number for organizations, which it uses to verify the company's existence and address. It also wants a working public website on the company's domain and an enrolling person with authority to sign for the company.
• Google Play also requires a D-U-N-S Number for organization accounts. Without one, you can't create a company account.
• If you open a new personal account on Google Play, then since November 2023 you have to test the app with at least 20 people for two weeks before you can apply for production access.

On Apple's side, testing with people outside your team goes through TestFlight, with up to 10,000 external testers. The first build you send to external testers still has to pass an Apple review.

If your company doesn't have a D-U-N-S Number yet, start the request in week one. Otherwise the app is ready at the end and sits waiting on paperwork.

Days 11–14: the data, the plan, and what goes into version one

The last few days cover the part you don't see: what data the app stores (customers, bookings, products), who can see it, what gets sent as a notification, and which other systems it talks to (payments, invoicing, calendars). This is also when you lock in what goes into the first version and what waits for the second. We've written before about why the first version should be small.

At the end of the two weeks, you have:

• the sentence that says what the app does;
• a clickable prototype, tested on a few people;
• the list of screens and features for version one;
• developer accounts open or on the way;
• a realistic schedule for development and testing.

Cost only comes up now, based on that list, because only now do we know what's being built. The price comes in the proposal, based on the number of screens, integrations and platforms.

What you bring

You don't need technical specs. It helps a lot to have a few examples of apps you like (and why), your company details for the accounts, someone on your side who can answer questions the same day, and two or three customers willing to try the prototype.

Our App Dev services page shows how we carry on after the prototype.