The questions I ask before I build your app

Most conversations about a new app start with the screen. Someone has an idea, brings sketches, already knows which buttons go where, and wants to know what that costs. I understand the order, because it is the only part of software you can actually see. It is not the part that decides whether you end up with something your business is better off for.

I build and run Altrady myself, a crypto trading platform that has been running since 2018 and is now used by more than 130,000 traders. Underneath it sits Coinray, the market data API that feeds Altrady. Alongside that there is Kinfolder, a family folder for wills, accounts and instructions. I led development teams for years and reviewed the code of juniors and seniors. What I kept from that is not really a list of technical requirements, but a handful of questions I always ask before a single line of code gets written.

Why are you building this?

This is the question I wish clients asked themselves. Why are you building this app? What business value does it create? What problem are you solving?

It sounds almost too simple to say out loud, which is exactly why it gets skipped. But the answer separates two kinds of projects. There is building because you want to build something, and there is building to make a difference in a business. Both cost the same money. Only one of them pays you back.

If the answer is “our competitor has an app too” or “we want to do something with AI”, that is not a problem you are solving, that is a feeling you have. I can build software around it, but I cannot promise that anything changes afterwards. If the answer is “my people retype the same data from three systems every day and we make mistakes doing it”, then we have something to work on. I know what to steer towards, and you will know afterwards whether it worked.

What makes someone a good developer for business software?

There is a lot of talk about languages, frameworks and certificates. For business software I do not think that is the main measure. The good developer for this work is the one who keeps track of business value.

That is a practical trait, not an attitude. It comes down to one judgement call that returns all day long: can I ship something today that adds enough value, or am I about to spend weeks on something nobody uses? A developer who never asks that will build exactly what is on the list. It feels pleasant during the project and you only notice months later, when you look at which features actually get clicked.

You can spot it in a conversation by how someone reacts to your wish list. Someone who enthusiastically takes all of it and puts a price under it has added no judgement. Someone who asks what you would leave out if you had to launch in six weeks is thinking about your side of the bill.

What do you actually need on day one?

This is where a lot of business owners hold themselves back. They wait until everything is right: the name, the logo, the domain, the complete feature list. That waiting costs more than it returns.

What you really need on day one is a problem to solve and a rough idea of the solution. That is all. A domain and a product name are nice to have, but not required to start, as long as you stay flexible about that name. Names can still change later. The idea and the solution are what you have to defend; that is the part someone else cannot simply walk around.

The idea and the solution are your moat. The name is a label you stick on later.

That does not mean you should show up unprepared. It means preparation is something other than what you probably think. Come with the situation you want to change, what it looks like now, who suffers from it and what it costs you to leave it alone. I can work with that. A folder full of screen designs without that story is harder, because then I know what you want built, but not why it has to be that way.

And the money?

I will keep this short here, because the quote itself deserves its own explanation. My starting point: a fixed price, with clear expectations of what will be delivered.

That is not a trick to look cheaper. It is a way of putting the risk in the right place. If I give a fixed price, it is my problem when I misjudge how much work something is. With an open hourly bill that is your problem, while you are the one least able to judge whether those hours were needed. What has to sit opposite that fixed price is a sharp scope: what is in, what is out, and what happens when you want to change direction along the way.

What to do with this

You do not have to use any of this to assess me. Use it on everyone you talk to, including the agency you have known for years.

Ask the why question out loud and watch what happens. Some people go straight to technology, some go straight to your customers. Ask what they would leave out. Ask what they need from you before they can start. And see whether you get a fixed price with a sharp scope, or an estimate that can still go anywhere.

If you have not worked out yet what problem you are solving, by the way, that is no reason to postpone the conversation. That is often exactly the conversation you need. If you want to have it, I am happy to hear what you are running into right now.