What you need before building an app: the decisions to make first

Before building an app, it pays to have five decisions made: who it's for, what it does first, who will run what happens inside it, how it pays for itself and who maintains it after launch. None of them is technical. They're business questions, and they shape whether the app works out more than anything else.

If you don't know yet whether there's demand for the idea, that comes first; I covered it in how to validate an app idea. This one is for when you've decided to build it and want to show up prepared to your first conversation with a developer.

The five questions, and what a good-enough answer looks like

Who it's for: one real person, not “everyone”

“Everyone” is the hardest answer to build for. An app for your field sales reps looks nothing like one for your customers, and one for young customers who buy every week looks nothing like one for an older crowd who open it once a month. Picture an actual person using it: what phone they have, where they are when they open it, how much patience they've got.

That answer even decides whether it should be on Google Play and the App Store or open from a link. I explained the difference in web app vs app store app.

What it does first: the short list wins

Almost everyone shows up with a long feature list. Writing it down is fine, but then you have to circle the one feature without which the app is useless. That one goes first, along with the bare minimum to make it work. Everything else gets lined up in phases.

That's not shrinking your idea. It's getting real people using it sooner and letting what you learn decide what comes next. If you want to put it on paper, how to write a project brief walks you through it.

Who runs it: the question almost nobody asks

An app doesn't run itself. If it has products, someone adds and updates them. If it takes orders or bookings, someone answers them. If it has users, someone helps when one can't log in. Before you start, write a name next to each of those jobs, even if it's yours.

That answer changes what gets built. If the person adding content isn't tech-savvy, the dashboard has to be dead simple. If nobody will have time to answer questions, the app should handle the common ones on its own.

How it pays off, and who keeps it running

Not every app has to charge its users. Plenty pay for themselves through what they save (support hours, order mistakes) or what they help sell. Others run on subscriptions. I compared the options in how to monetize an app. Decide early, because charging inside the app changes what needs to be built.

After launch, the app needs care: phones get updated, stores change their rules and there's always something to improve. Agree from the start on who handles it, and make sure the accounts, the domain and the code are in your name. I went into that in who owns your website code.

What about a no-code tool?

Fair question. To validate quickly, sometimes it's enough. When the app is the core of your business, with its own rules or an experience that has to feel polished, custom-built usually pays off better. On the Estructuras 3D blog I compared both paths for one specific case, AI or no-code quoting tools vs custom. The reasoning applies to any app.

What I bring to the table

With those answers, even half-finished, I can tell you on our first video call how I'd approach the app, what goes in phase one and what's better left for later. I work remotely from Buenos Aires, Argentina (UTC−3), and quote per project. You can see what I do on the services page.

Frequently asked questions