How to design an app from scratch: what building one for a mosque taught me

Most guides to designing an app start with tools. Pick Figma, make a mood board, choose your fonts. That's the easy part. The hard part is working out what the app should do, for whom, so that they keep using it after the first day.

This is the process I follow, told through one real project: Meel, an app I designed to replace the paper register that our mosque keeps its accounts in. It works for any app, though: one for a corner deli, a sports club, or your own side project.

1. Start with one person and one problem

Meel started with my own monthly fee. Every house in our community pays the mosque a small amount each month. I wanted to check what we owed and pay from my phone. I couldn't: every payment lived in one thick paper register.

But I wasn't the person I was designing for. The people who'd use the app every week were the volunteers who look after that register. Many of them avoid computers completely. That changed everything. If the app took more effort than pen and paper, they would go back to pen and paper, and the app would be dead.

So before any screen, write one sentence: who will use this, and what are they doing today instead. If you can't write it, you're not ready to design.

2. Go and watch where it actually happens

Most people pay their dues on Friday, right after prayers. They walk up to the committee table and say their name. A volunteer flips to their page, takes the money, writes it in, and hands over a receipt. There's a queue.

That scene gave me most of my design rules: one hand free, a queue waiting, people who don't want to type. Watching for an hour tells you more than a week of guessing. You don't need a formal user research plan. You need to be there.

3. Respect what people already use

Every mosque register I've seen is a grid: months down the side, fees across the top, a tick for paid. I could have invented something cleverer. Instead, Meel's register view looks like that grid.

When switching doesn't feel like switching, people switch. A volunteer can hold the old page next to the phone and find everything in the same place. The same goes for any app that replaces a notebook, a spreadsheet or a group text: borrow its shape.

4. Write the main journey as a story

Before drawing screens, I wrote the most common visit as a list of steps:

1. The volunteer searches by name or house number.
2. They pick the right person from the results.
3. The house opens, with what's owed.
4. They choose what's being paid today: the fee, a donation, a special fund.
5. They choose the months it covers, and see the total.
6. They mark it paid, and the receipt goes out on WhatsApp or gets printed.

Each step became roughly one screen. Then I counted taps, and cut every one that wasn't needed. For example, the month range already ends at the current month, because that's what most payments are. Most of the time, nobody touches it.

5. Design for messy, real data

Fake data in a mockup is always tidy. Real data isn't. In one community there can be three people with the same name. So search results show each person's father's name underneath, the way people tell them apart in real life. House numbers are unique, so the house number is the big, bold thing on screen.

Real life kept surprising me. At a fundraiser, people promise first and pay later, so promised and paid had to stay separate. Some people give a sack of cement or a gram of gold instead of money, so Meel records gifts with their value.

Ask for real examples early: the oddest receipt, the longest name, the family that pays three years at once. Your layout should survive all of them.

6. Sketch, then wireframe, then design

I sketch on paper first, because it's fast and I'm not attached to it. Then grey wireframes, to get the layout and the order of things right without colour distracting anyone. Only then the real design, in Figma.

Skipping straight to polished screens is tempting. But once something looks finished, people only comment on the colours. A rough sketch gets you honest answers about whether the thing makes sense at all.

7. Put a real version in someone's hands

A clickable prototype is good. A real app on someone's phone, with their own data, is far better. People do things in a real app they'd never do in a prototype: they get interrupted, they make mistakes, they hand the phone to someone else.

This is why I build what I design, using Next.js and Claude Code. I can put a working version in front of a volunteer, watch what they do, and fix it the same week. I wrote up how in my Figma to Next.js workflow.

The short version

• One person, one problem, written in a sentence.
• Watch it happen in real life.
• Borrow the shape of what they already use.
• Write the main journey as steps, then cut steps.
• Test your design with the messiest real data you can find.
• Sketch, wireframe, design, in that order.
• Get a real version into real hands, early.

Meel lives at meelapp.in. If you're about to build your first product for a startup, you might also like who to hire first for your MVP.