The Hardest Part of Building Software Isn't Coding
I used to think that if you wanted to become a good software developer, the most important thing was to know how to code.
Learn the language.
Understand the framework.
Know your database.
Learn APIs.
Understand Git.
Deploy your application.
And, of course, learn how to deal with that one error that somehow appears at 1:00 a.m. when everything was working perfectly two minutes ago. 😂
I still believe all of these things matter.
But after spending more time building websites, business systems and SaaS products, I've come to realize something.
Coding is not always the hardest part.
Sometimes, the hardest part is understanding what you are actually supposed to build.
Someone Says, “I Need an App”
This happens quite often.
Someone comes with an idea and says:
“I need an application.”
My first reaction isn't always:
"Okay, let's start coding."
Sometimes I ask:
“What do you want the application to help you do?”
Because there is a difference.
Maybe they don't really need an application.
Maybe they need to stop doing something manually.
Maybe they are losing customer information.
Maybe they can't keep track of payments.
Maybe their employees are using different spreadsheets.
Maybe they have information everywhere and can't find anything when they need it.
So the real problem isn't necessarily:
“We don't have an app.”
The real problem might be:
“The way we are doing this isn't working anymore.”
And that is a very different conversation.
I've Made This Mistake Too
I won't pretend that I have always gotten this right.
As a developer, there is a temptation to build.
You have an idea.
You get excited.
You start imagining the dashboard.
You are already thinking about the colours, cards, charts, buttons and animations.
Before you know it, you have spent hours building something.
Then you stop and ask yourself:
“Wait... what exactly am I solving?”
😂
It happens.
And honestly, I think it is part of learning how to build products.
I've gradually learned to slow down.
Ask questions.
Listen.
Understand the process.
Then build.
A Factory Doesn't Care About Your Fancy Dashboard
Take SmartFactory, for example.
When I started thinking about the system, it would have been easy to say:
"Let's build a beautiful manufacturing dashboard."
And yes, the dashboard should look good.
I love beautiful interfaces.
But the person running the factory isn't waking up in the morning saying:
“I really need a beautiful dashboard today.”
They have other things on their mind.
Do we have enough raw materials?
What did we produce yesterday?
What are we producing today?
What is running out?
What products do we have in stock?
What orders are waiting?
Those are the real questions.
So the software has to help answer those questions.
The dashboard is just how we present the answers.
That changed the way I look at software.
The Same Thing Happens in Schools
I've worked on school management systems too.
And if you ask a school owner what they want, they might say:
“We need a school management system.”
But what they really want is much simpler.
They want to know which students have paid.
They want teachers to enter results without stress.
They want parents to get information.
They want student records to be safe.
They want to know what is happening in the school without having to ask five different people.
Again, the software isn't really the goal.
Making the school easier to manage is the goal.
That is what the software is supposed to do.
Sometimes WhatsApp Is the Problem 😂
I have a feeling many Nigerian businesses will understand this one.
WhatsApp is fantastic.
Honestly, Nigerians have found a way to use WhatsApp for almost everything.
Business.
Church.
School.
Community meetings.
Buying and selling.
Announcements.
Customer service.
Family meetings.
Everything.
But there comes a point when your entire business cannot continue to depend on WhatsApp messages.
Someone sends:
“Please send me the list of people that have paid.”
And then somebody starts scrolling.
"Wait, I think it was sent last Tuesday."
"Check the other group."
"Ask John, he has the Excel file."
😂
That's when you know there may be a better way.
Not because WhatsApp is bad.
But because the business has outgrown the process.
That Is Where I Think Software Makes Sense
Good software should take away unnecessary stress.
If someone is entering the same information five times, let's see if we can reduce that.
If someone has to search through hundreds of messages to find a record, let's organize the information.
If management needs three people to prepare a report, maybe the system can generate it.
If nobody knows exactly what is happening in the business, maybe we can create a place where the right information is visible.
That's the kind of software I enjoy building.
Not software simply because:
“Everybody has an app.”
But software because:
“This problem can be solved better.”
And Then There Is the Other Side of Development
Of course, building software isn't always smooth.
There are days when everything works.
You feel like a genius.
You make good progress.
You look at what you've built and think:
“This is actually beautiful.”
Then the next day...
One tiny thing breaks.
You fix it.
Another thing breaks.
You check the code.
You check the database.
You check the browser.
You check the server.
You restart everything.
You stare at the screen.
And eventually you ask:
“Who sent me this problem?” 😂
Every developer knows what I'm talking about.
But those moments teach you patience.
Sometimes the answer is obvious.
Sometimes it takes hours.
Sometimes you have to leave it, sleep, come back the next morning and suddenly see what you were missing.
That's development.
AI Has Made Things Even More Interesting
I also can't talk about modern software development without mentioning AI.
AI has changed the way I work.
It can help me think through problems, write code, understand errors, test ideas and move much faster.
And I genuinely enjoy using it.
But there is something I have learned from using AI:
Being able to build something quickly doesn't mean you know what to build.
You can ask AI to create an application in minutes.
But if you don't understand the problem, you may simply end up with a very impressive solution to the wrong problem.
😂
So yes, AI can help us code faster.
But somebody still has to think.
Somebody still has to ask:
“Why are we building this?”
I Like Building Things That Have a Reason
This is probably the best way I can explain my approach today.
I don't want to build something just because it looks impressive.
I want there to be a reason behind it.
A school management system should make school administration easier.
A factory system should make production easier to understand.
A cooperative platform should make members' money and records easier to manage.
A community platform should make the community more organized.
A website should help an organization communicate, build credibility and reach the people it needs to reach.
There should always be a why.
Maybe My Engineering Background Has Something to Do With It
My original background is engineering.
And I think that has influenced the way I approach technology.
Engineers are trained to look at systems.
How does this part affect that part?
What happens if this fails?
Where is the problem coming from?
How do we make the whole thing work better?
I find myself thinking about software in much the same way.
A business is a system.
A school is a system.
A factory is a system.
A cooperative is a system.
People, information, money and processes are all connected.
Sometimes you don't need to change everything.
You just need to fix the part that is causing the problem.
I Also Love Music
There is another thing about me that probably doesn't look connected to software at first.
I love music.
And the older I get, the more I realize that music has actually taught me something about building things.
A good song doesn't need every instrument playing at the same time.
If everything is loud, nothing stands out.
Sometimes the most important part is the space between the sounds.
Software is a little like that.
You don't need 100 features because you can build them.
You need the features that actually matter.
You need things to work together.
You need to know what to leave out.
And sometimes, less really is more.
I Am Still Learning
One thing I don't want my portfolio to suggest is that I've figured everything out.
I haven't.
Technology changes too quickly for that.
There is always something new to learn.
A new tool.
A new framework.
A new way of doing things.
A new problem I've never encountered before.
And that's actually one of the things I enjoy about this field.
I can never honestly say:
“I've seen everything.”
There will always be another mountain to climb.
So, What Is the Hardest Part?
After all the projects, the bugs, the late nights, the designs, the databases, the deployments and everything else that comes with building software...
I don't think coding is the hardest part.
Understanding people is harder.
Understanding their business is harder.
Understanding what they actually need is harder.
Knowing what to build—and what not to build—is harder.
Because once you understand the problem properly, the technology becomes much easier to figure out.
That's How I Want to Build
I want to keep building things that are useful.
Things that solve real problems.
Things that don't require someone to read a 50-page manual before they can use them.
Things that are secure.
Things that can grow.
Things that look good, yes—but more importantly, things that work.
And if someone uses something I built and says:
“This has made my work much easier.”
Honestly?
I'll take that over a fancy award any day.
Because that's the reason I got into this in the first place.
To build things that matter.
One Last Thought
If you have a business and you're thinking:
“I need an app.”
Maybe you do.
But before you start looking for someone to code it, ask yourself one question:
“What problem am I really trying to solve?”
Start there.
The technology can come afterwards.