Before you spend money building an app, do three things: prove that people actually want it, decide the smallest version that does one job well, and work out how you’ll get users and make money. Founders who skip these often end up with a polished app that nobody downloads, or one so big it takes months longer than planned.
None of this needs a big budget. It needs a few weeks of honest work. Here’s what each step means, why it matters and how to do it simply.
1. Prove that people want it
Why it matters. The most common reason apps fail isn’t bad code. It’s building something that solves a problem people don’t have, or don’t care about enough to change their habits. Your friends saying “Nice idea!” is not proof. Friends are kind.
How to do it simply.
- Talk to real people with the problem. Not to pitch, but to listen. Ask how they handle it today, what annoys them, what they’ve tried, and what they already spend on it. Questions about the past (“When did this last happen? What did you do?”) give far more honest answers than “Would you use an app for this?”
- Look for workarounds. If people are already using spreadsheets, WhatsApp groups and notebooks to solve the problem, that’s a strong sign the need is real.
- Put up a landing page with a waitlist. One page that explains the app in plain words and asks for a name, email or WhatsApp number to get early access. Share it with your target audience, maybe with a small ad. If strangers sign up, you have a signal. If nobody does, you’ve saved a lot of money.
- Try to pre-sell. For some ideas, you can ask for a small advance or a paid pilot. Money is the strongest proof of all.
Quick example. A founder wants to build an app for tiffin services to manage daily orders. Before building, she talks to tiffin owners in her city and finds they track orders in WhatsApp chats and a notebook, and lose money on missed payments. She puts up a simple page offering “order and payment tracking for tiffin services” and shares it in local business groups. Several owners sign up and two ask when they can start. Now she knows the problem is real, and she knows payment tracking matters most.
Tip: Write down what result would convince you to stop, before you start testing. It’s easy to explain away weak results once you’re attached to an idea.
2. Define the smallest version (your MVP)
Why it matters. An MVP (minimum viable product) is the smallest version of your app that does one core job well enough for real people to use. Every extra feature adds design, building, testing and fixing time. That raises the cost, delays launch and makes it harder to learn what users actually value.
The goal of the first version isn’t to impress. It’s to learn from real use as quickly as possible.
How to do it simply.
- Write the one core job in a single sentence. “A patient can book a slot with this clinic in under a minute.” If you need “and” three times, it’s too big.
- List every feature you’ve imagined. Get them all out of your head.
- Sort them into three groups: must have for the core job, nice to have, and later.
- Be ruthless. Chat, referrals, dark mode, loyalty points, multiple languages: unless the core job fails without them, they wait.
- Think about who runs it. Often the business side needs a simple admin panel to manage orders or users. That counts as part of the MVP.
Quick example. A fitness coach imagines an app with workout videos, diet plans, progress photos, a community feed, live classes and a shop. The core job, though, is “members follow their weekly plan and the coach sees who is falling behind.” The MVP is a weekly plan, a way to mark workouts done and a simple coach dashboard. Everything else can come after members are using it.
A smaller first version also changes the cost and timeline. What drives the cost of an app is mostly the number of screens and features, whether you need iOS, Android or both (see Android, iOS or both), connections to things like payments or maps, the admin side, and how much design polish you want. Cutting scope is the most powerful way to spend less and launch sooner.
3. Decide how you’ll get users and how you’ll earn
Why it matters. “Build it and they will come” doesn’t work for apps. App stores are crowded, and people are reluctant to download yet another app. If you don’t know how the first few hundred users will find you, or how the app will pay for itself, a great product can still stall.
How to do it simply.
- Name your first users. Who exactly, and where do they already gather? Local business groups, a college, your existing customers, an Instagram community, LinkedIn?
- Pick one or two ways to reach them. Your existing customer list, partnerships, content, referrals or ads. Our guide on how digital marketing works explains what each channel is good for.
- Choose how you’ll earn. Subscription, one-time payment, commission per order, ads, or the app supporting an existing business (like a restaurant’s ordering app). Make sure the numbers can work: what you earn from a user should be more than what it costs to get them.
- Ask: do I need a native app yet? A native app is one installed from the App Store or Google Play. If people will use your product occasionally, or mainly find you through Google, a fast website or web app (which runs in the browser, no download needed) may be enough to start. It’s often quicker to build and easier to change. A native app earns its place when people use it often, or need phone features like the camera, location, notifications or offline use.
Quick example. A coaching centre wants an app for students. Thinking it through, they realise their first users are their own existing students, so getting users is easy. They’ll earn through course fees they already charge, so the app is about keeping students engaged, not selling. And since students will use it daily for tests and notes, and want notifications, a proper app makes sense. A different business, say a wedding photographer wanting to share galleries a few times a year, would probably be better served by a web app.
What this gives you before you build
After these three steps you’ll have evidence that people want your app, a clear one-sentence core job with a short feature list, and a realistic plan for users and money. That makes the build faster, cheaper and far less risky. It also makes conversations with any developer much more useful, because you can talk about goals rather than a long wish list. If you’re still weighing your options, our post on startup website mistakes is useful if you decide to start with the web.
Wizket builds apps for iOS, Android and cross-platform, from first sketch to App Store and Google Play, and keeps supporting them after launch. A focused first version usually takes 6–12 weeks, and the exact timeline comes with the plan. If all you have is an idea and no brief, that’s fine. A quick WhatsApp chat is how most projects start, and we’re happy to sign an NDA first.
