Before you build an app. Before youbuild an app

The short answer

You do not need a 50-page specification. Before you build an app, prepare a clear problem, a clear first user, a short ranked list of features, a few examples you like, and the accounts the app will need, in your own name.

With those ready, a good team can give you an accurate quote and start work quickly. The full checklist is below. Copy it and fill it in.

Why preparation matters

Most delays in app projects do not come from code. They come from decisions nobody has made, content that is not ready, and accounts that take days to approve. A little preparation removes most of that.

It also makes quotes more accurate. The clearer your brief, the less guesswork goes into the price and the timeline.

1. What problem does your app solve?

Write it in one or two sentences. Avoid features here. Describe the pain.

• Who has this problem?
• How do they deal with it today?
• Why is that not good enough?

If you can, talk to five to ten people who have the problem before you build. Their words will sharpen your brief more than anything else.

2. Who is the first user?

"Everyone" is not a user. Pick the specific person you are building for first: a small clinic owner, a freelance designer, a parent booking classes. You can widen later.

If your app has more than one type of user, such as buyers and sellers, list each one and say which matters most at launch.

3. What must the first version do?

Write the core job

Finish this sentence: "This app helps [user] do [job]." That is the heart of your first version.

Rank your features

List every feature you can think of, then sort them into three groups:

Be strict. Most first versions are better with fewer "must haves". Our article on how long it takes to build an MVP explains why scope drives the timeline.

4. Web, mobile or both?

Start where your users already are.

• Web app if users work at a desk, or you need to reach people without an install.
• Mobile app if the product depends on the camera, location, notifications or daily use on the go.
• Both often means a mobile app for users and a web admin panel for you.

For mobile, Flutter covers iOS and Android from one codebase. Native suits heavy graphics and deep platform features. See Flutter vs Swift (native iOS) for a full comparison.

5. Examples and references

Collect three to five apps or websites you like, and write one line on why. "The checkout in this app is quick" is more useful than a long description. Include ones you dislike too.

Rough sketches on paper are welcome. They do not need to be pretty. They show the flow in your head.

6. Brand and content

• Do you have a name, logo and colours? If not, plan for branding before or alongside the build.
• Who writes the text inside the app, the store listing and the website?
• Do you need photos, illustrations or product data loaded in?
• Do you need a privacy policy and terms of use? Almost every app does.

7. Accounts you should own

Create these yourself, in your company's name, and add your developers as team members. That way you keep control if you ever change teams.

• Apple Developer Program account (for iOS apps). Approval for organisations can take several days.
• Google Play Console account (for Android apps).
• Your domain name and business email.
• A code repository your team can access, owned by you.
• Payment provider, if you will take payments.
• Cloud hosting and any third-party services, billed to you.

8. Budget, timing and decisions

• Budget range. Sharing a rough range helps a team suggest the right scope.
• Deadline. Is there a real date, such as an event or a funding round? Say so early.
• Decision maker. One person who can review demos and decide quickly.
• Success measure. How will you know the first version worked? Sign-ups, bookings, paying users?

The founder's checklist (copy this)

Copy the list below into a document and fill in each line. Send it to any team you are talking to.

APP BRIEF

[ ] Problem: the pain, in one or two sentences
[ ] First user: who, specifically
[ ] Other user types, if any
[ ] Core job: "This app helps ___ do ___."
[ ] Must-have features (ranked)
[ ] Should-have features
[ ] Later features (version two)
[ ] Platform: web / iOS / Android / admin panel
[ ] 3-5 reference apps, with one line on why
[ ] Rough sketches of the main flow
[ ] Name, logo and colours (or "need branding")
[ ] Who writes the content
[ ] Privacy policy and terms
[ ] Apple Developer account (in my name)
[ ] Google Play Console account (in my name)
[ ] Domain and business email
[ ] Payment provider, if needed
[ ] Integrations: maps, payments, calendars, other APIs
[ ] Budget range
[ ] Deadline, and why
[ ] Decision maker and availability
[ ] How we will measure success

What you do not need to prepare

• Technical choices. Frameworks, databases and hosting are the team's job to recommend and explain.
• Final designs. Sketches and references are enough to start.
• Every edge case. A good team will ask the right questions.
• A perfect idea. The first version exists to learn.

Where to start with Lveno

If you have filled in even half the checklist, you are ready for a first call. Lveno builds MVPs, mobile apps and web apps, and can design the product with you through our UI/UX design service.

• A free 30-minute call to go through your checklist.
• A fixed quote before any work starts.
• Kick-off within 24 hours, a working first version in about a week, then weekly demos.