7 Questions to Ask Before Building a Software Application
Let me tell you something I've noticed.
A lot of people come to a developer with an idea and say:
“I want to build an app.”
That's great.
I love hearing that.
It means somebody has seen a problem and is thinking about doing something about it.
But usually, after that first sentence, I have a question.
“Why?”
Not because I'm trying to discourage the idea.
I'm asking because I want to understand what is behind it.
What problem are you trying to solve?
Who has the problem?
How are they solving it now?
And what would change if your application existed?
Because I've learned something over time:
A good software product doesn't start with code.
It starts with a problem.
You Don't Need to Come With a Technical Specification
This is something I want potential clients to understand.
Please don't feel like you need to sit down and write a 30-page document before talking to a developer.
You don't need to know:
React.
Next.js.
Supabase.
APIs.
Databases.
Authentication.
Cloud infrastructure.
That's our job.
What I need from you is much simpler.
Tell me:
“This is what is happening.”
“This is what is frustrating me.”
“This is how we're doing it now.”
That's enough to start a conversation.
From there, we can begin figuring out what the technology should look like.
Question 1: What Problem Are You Actually Trying to Solve?
This is the first question.
And honestly, it is probably the most important one.
Don't tell me:
“I want a school management app.”
Tell me:
“Our school is struggling to manage student records, fees, results and communication with parents.”
Now we're getting somewhere.
Don't tell me:
“I want a cooperative platform.”
Tell me:
“We have hundreds of members and we're struggling to keep accurate records of contributions, loans and repayments.”
That's a problem.
And problems can be solved.
Sometimes We Build the Wrong Thing
This happens more often than people think.
Someone sees an application online and says:
“I want something like this.”
Okay.
But why?
Maybe the application they're looking at has 50 features.
They might only need five.
If we copy everything, we've just increased the cost and complexity without necessarily increasing the value.
This is why I don't like starting with:
“What features do you want?”
I prefer:
“What are you trying to achieve?”
There is a big difference.
Question 2: Who Is Going to Use It?
This sounds simple.
But it can completely change the way we build the system.
Let's say you're building a school platform.
Who is using it?
The administrator?
Teachers?
Students?
Parents?
Account officers?
Management?
They may all be using the same system, but they shouldn't necessarily see the same thing.
A parent doesn't need access to the school's entire administrative dashboard.
A teacher shouldn't necessarily see financial information.
A student shouldn't be able to modify their own result.
So once we know who the users are, we can start thinking about:
Roles.
Permissions.
Dashboards.
Workflows.
And security.
That's already more useful than simply saying:
“I need a school app.”
Question 3: How Are You Doing It Today?
This is one of my favourite questions.
Because sometimes the answer tells me more than the proposed application.
I might ask:
“How do you currently manage this?”
And someone says:
“We use WhatsApp.”
Another says:
“Excel.”
Another says:
“We write everything in a notebook.”
And another says:
“There is one woman in the office who knows everything.”
😂
That last one is especially dangerous.
Because if one person is the only person who knows how everything works, then you don't really have a system.
You have a dependency.
And if that person leaves, gets sick, loses their phone or simply isn't available...
the business has a problem.
Your Current Process Is Full of Clues
Don't be embarrassed about how you're currently doing things.
Maybe it's manual.
That's okay.
In fact, show me.
Show me the Excel sheet.
Show me the notebook.
Show me the WhatsApp conversation.
Show me the paper form.
Show me how customers currently make requests.
Because sometimes the best software ideas are hiding inside those messy processes.
The job isn't to judge the old process.
The job is to understand it well enough to improve it.
Question 4: What Is Taking Too Much Time?
This is where technology can become really useful.
Let's say your accountant spends six hours every week preparing a report.
That's 24 hours a month.
Almost 300 hours a year.
For one process.
Now imagine that a properly designed system can automate most of it.
Suddenly, we're not talking about having a “modern dashboard.”
We're talking about giving somebody their time back.
That's real value.
And this is one of the things I look for when I'm thinking about automation:
Where are people repeatedly doing the same thing?
If a person enters the same information five times...
Something is wrong.
If somebody copies information from one spreadsheet into another every day...
Something is wrong.
If management has to call three people before getting a simple figure...
Something is wrong.
Those are opportunities.
Question 5: What Should the System Do Automatically?
This is where we start getting into the interesting part.
Let's take a simple example.
Someone pays money.
Why should an administrator have to update five different records manually?
A good system could potentially:
Record the payment.
Update the customer's balance.
Generate a receipt.
Update the financial report.
Send a notification.
Create an audit record.
One action.
Several things happen behind the scenes.
That's the beauty of automation.
But there's an important warning here.
Don't automate a bad process.
If the process is confusing, automation can simply make the confusion happen faster.
So first:
Understand the process.
Then:
Simplify the process.
Then:
Automate it.
I keep coming back to this because it matters.
Question 6: What Happens When Your Business Grows?
This is something I wish more people thought about before building software.
Maybe today you have 50 customers.
But what happens when you have 500?
Maybe you have one branch.
What happens when you have five?
Maybe 10 people will use the system.
What happens when 1,000 people start using it?
I'm not saying you need to build a massive enterprise system from day one.
Please don't.
😂
But you should at least avoid building something that will become impossible to maintain when the business grows.
This is where good architecture matters.
Think About SmartFactory
When I think about something like SmartFactory, I don't just think:
“Let's create a dashboard.”
I think about what happens when the factory grows.
More products.
More materials.
More employees.
More production.
More transactions.
More reports.
More users.
More data.
The system has to be designed with that possibility in mind.
Not because we want to make the project unnecessarily complicated.
But because growth changes the problem.
Question 7: What Would Success Look Like?
This might be the question people forget most.
Let's say we build your software.
Six months later, how do you know it worked?
What changed?
Maybe:
Staff spend 50% less time doing manual records.
Maybe:
Customers can now register themselves.
Maybe:
Management can see daily sales without waiting for a report.
Maybe:
Errors in financial records have reduced significantly.
Maybe:
Members can check their contribution history themselves.
Maybe:
Production managers can see stock levels in real time.
Those are outcomes.
And I think outcomes are more important than features.
Don't Tell Me You Need 100 Features
I've said this before, but I'll say it again.
A software product doesn't become good because it has 100 buttons.
Sometimes the best system is the one that does 10 important things extremely well.
I've seen projects where people keep adding features because they believe:
“More features means more value.”
Not necessarily.
More features can also mean:
More confusion.
More maintenance.
More bugs.
More training.
More cost.
Sometimes less is actually better.
This Is Where an MVP Makes Sense
You may have heard me talk about an MVP in my previous article.
This is where it becomes practical.
Suppose you want to build a cooperative management platform.
You have 30 ideas.
Don't build all 30 immediately.
Ask:
What are the three or five things that make this product useful?
Maybe:
Member management.
Contributions.
Loans.
Repayments.
Reports.
Start there.
Let people use it.
Listen to them.
Then improve it.
That's how a product grows naturally.
And Yes, Your Budget Matters
Of course it does.
I'm not going to tell you:
“Don't worry about the money.”
Money matters.
But your budget should help determine how we approach the solution, not determine whether we understand the problem.
If your budget is limited, perhaps we build a smaller first version.
If the business has more resources, perhaps we can build more.
If the project is complex, we break it into phases.
That's much better than squeezing an entire large system into an unrealistic budget.
What About Security?
Please don't leave this until the end.
If your application will hold:
Customer information.
Student records.
Financial records.
Business information.
Employee information.
Or anything sensitive...
Security should be considered from the beginning.
Who can log in?
Who can see what?
Who can edit?
Who can delete?
Can we track important activities?
What happens if someone's password is compromised?
How are backups handled?
Where is the data stored?
These questions aren't “extra features.”
They're part of building a responsible system.
A Beautiful Interface Is Not Enough
I love beautiful interfaces.
I enjoy building them.
A good interface can make people actually enjoy using software.
But let's not confuse beauty with quality.
A beautiful application with poor security is still a bad application.
A beautiful application with a badly designed database can become a nightmare.
A beautiful application that doesn't solve the user's problem is just...
a beautiful problem.
😂
That's why I care about the things people don't immediately see.
The database.
The architecture.
The permissions.
The security.
The performance.
The maintainability.
This Is Why I Ask So Many Questions
Sometimes a client may think:
“This developer is asking too many questions.”
😂
Maybe.
But there is a reason.
I don't want to spend three months building something and then discover that we misunderstood the problem from day one.
I'd rather spend more time understanding the idea at the beginning.
It saves everybody pain later.
And honestly, sometimes those conversations completely change the project.
We discover a simpler way.
We remove unnecessary features.
We find a better workflow.
We discover another group of users.
We realize something doesn't need to be automated.
That's good development.
Your Idea Doesn't Need to Be Perfect
If you're reading this and you have an idea you've been keeping in your head for months...
You don't need to have everything figured out.
You don't need a logo.
You don't need a business plan with 50 pages.
You don't need a technical specification.
You don't even need to know exactly what the application should look like.
Start with the problem.
Tell me:
“This is what I'm experiencing.”
That's enough.
Good ideas become clearer when you talk about them.
And Sometimes the Idea Should Die
I know this sounds strange.
But sometimes, after asking the right questions, you realize:
This isn't worth building.
And that's okay.
Better to discover that before spending millions of naira building it.
Technology shouldn't be about proving that an idea can be built.
Almost anything can be built.
The better question is:
“Should it be built?”
That's the conversation I want to have.
From an Idea to a Real Product
This is how I think about the process.
Problem.
↓
People affected by the problem.
↓
Current process.
↓
Better process.
↓
Simple solution.
↓
First useful version.
↓
Testing.
↓
Real users.
↓
Feedback.
↓
Improvement.
That's the journey.
The code comes in there somewhere.
But it isn't the beginning.
And it certainly isn't the whole story.
Maybe That's What Good Technology Really Means
For me, technology isn't about showing people how much code we can write.
It isn't about using the newest framework because everybody is talking about it.
It isn't about putting “AI” into everything.
It isn't about creating the biggest application possible.
For me, good technology is much simpler.
It takes something difficult and makes it easier.
It takes information that is scattered and organizes it.
It takes repetitive work and automates it.
It takes confusion and creates clarity.
It takes a good idea and gives it a practical form.
That's what I enjoy building.
So Before You Build Your Next App...
Take a little time and answer these seven questions:
1. What problem am I actually solving?
2. Who is going to use the solution?
3. How are they solving the problem today?
4. What part of the process takes too much time?
5. What should the system automate?
6. What happens when the business grows?
7. How will I know the solution actually worked?
If you can answer those questions honestly, you're already much further than someone who simply says:
“I want an app.”
And If You Have an Idea...
Bring it.
It doesn't have to be perfect.
It doesn't have to be technical.
It doesn't even have to be completely clear yet.
Sometimes the best place to start is simply a conversation.
Tell me what you're trying to fix.
Tell me what you're struggling with.
Tell me what you're doing manually.
We'll figure out the technology from there.
Because before I build your software, I want to understand your problem.
