Your Business Doesn't Need Another App. It Needs a Better Way to Work.
I've had people come to me and say:
“I need an app.”
My first question is usually:
“Why?”
Not because I don't want to build the app.
I actually love building software.
I enjoy taking an idea that exists only in someone's head, turning it into a plan, designing the interface, writing the code, connecting the database, and eventually watching someone use the finished product.
But over time, I've learned something important:
Sometimes an application isn't the real solution.
Sometimes the problem is a process that doesn't work.
Sometimes information is scattered across WhatsApp, Excel spreadsheets, notebooks and people's phones.
Sometimes the same information is being entered three different times by three different people.
Sometimes nobody knows exactly who is responsible for what.
And sometimes the business doesn't need more technology.
It needs a better way to work.
The “We Need an App” Trap
Technology has become so accessible that it's easy to believe every problem needs an application.
Need to manage customers?
Build an app.
Need to manage employees?
Build an app.
Need to collect payments?
Build an app.
Need to manage your business?
Build an app.
But software doesn't automatically fix a broken process.
If you take a complicated, disorganized process and simply put it inside an application, you've probably just created a digital version of the same problem.
The interface might look beautiful.
The dashboard might have impressive charts.
The buttons might have nice animations.
But if the underlying workflow doesn't make sense, the software won't magically make the business better.
That's why I prefer to start somewhere else.
I start with the problem.
What Is Actually Going Wrong?
Before building anything, I want to understand how the business currently works.
Who does what?
What happens when a customer places an order?
Where is the information recorded?
Who approves it?
Who needs to see it?
What happens after that?
Where do mistakes usually happen?
What takes too much time?
What information is difficult to find?
What are people doing manually that could reasonably be automated?
These questions might not sound very technical.
And that's the point.
Good software development begins with understanding people and processes before thinking about technology.
The Hidden Cost of Manual Work
One of the things I've noticed while working on different types of business systems is that manual processes can become expensive without anyone immediately noticing.
Imagine a business where an employee spends 30 minutes every day compiling information from different spreadsheets.
That's about 11 hours every month.
Now imagine five employees doing something similar.
Suddenly, you're losing more than 50 hours of productive time every month to a process that nobody questioned because:
“That's how we've always done it.”
And that's where technology can become useful.
Not because computers are exciting.
Not because having an app makes a company look modern.
But because time is valuable.
If software can turn a process that takes two hours into something that takes ten minutes, that's meaningful.
If it can reduce errors, even better.
If it can give management information they previously couldn't see, even better.
That's the kind of value I'm interested in.
This Is Why I Ask Questions Before I Build
When someone brings me a software idea, I don't want to immediately start designing screens.
I want to understand the story behind the idea.
What problem are we solving?
If we can't answer this clearly, we're probably not ready to build.
Who has the problem?
The owner?
The administrator?
The customer?
The employee?
Everyone?
How is the problem currently being handled?
Maybe it's Excel.
Maybe it's paper.
Maybe it's WhatsApp.
Maybe it's a combination of all three.
What is the problem costing the business?
Time?
Money?
Customers?
Accuracy?
Opportunities?
What should happen instead?
This is where the real product begins to take shape.
A School Doesn't Need “Software”
Take a school, for example.
A school doesn't wake up on Monday morning thinking:
“We really need a SaaS platform today.”
That's not the problem.
The school wants to manage students properly.
It wants teachers to record results without unnecessary stress.
It wants parents to receive important information.
It wants administrators to know who has paid.
It wants student records to be accessible.
It wants management to see what is happening.
So instead of asking:
“What software should we build?”
I think the better question is:
“How can we make running this school easier?”
The software comes after that.
A Factory Doesn't Need Another Dashboard
This is one of the ideas behind SmartFactory, one of the products I'm currently developing.
A factory doesn't really need another dashboard just because dashboards are fashionable.
The people running the factory need answers.
What materials do we have?
What are we producing?
How much have we produced?
What materials are running low?
What products are available?
What orders are waiting?
What happened today?
Those are real questions.
SmartFactory is being designed around those questions.
The technology is simply the tool that helps provide the answers.
That's an important distinction.
The Same Thinking Applies to Cooperatives
Consider a cooperative.
The members aren't interested in the database architecture.
They want to know:
How much have I contributed?
What is my balance?
How much do I owe?
When is my next repayment?
And the administrators want to know:
Who has paid?
Who is owing?
How much money has come in?
How much has gone out?
Can we produce an accurate report?
Again, the software isn't the goal.
Clarity is the goal.
The software simply makes that clarity possible.
Even Communities Have the Same Problem
I've also explored the idea of a digital community management platform.
Think about a typical association or community.
There may be a chairman, secretary, treasurer, financial secretary, committees and hundreds of members.
But information can still be spread across:
WhatsApp groups
Exercise books
Bank statements
Excel files
Receipts
People's phones
Then someone asks:
“Who has paid their dues?”
And everyone starts searching.
A properly designed system can change that.
Members can have profiles.
Dues can be recorded.
Projects can be tracked.
Announcements can be managed.
Financial activities can be documented.
Community IDs can be generated.
The point isn't to make the community “digital.”
The point is to make the community easier to manage.
Complexity Belongs Behind the Scenes
This is something I strongly believe in:
Complexity belongs in the engineering. Simplicity belongs in the experience.
A system might have a sophisticated database, authentication system, permissions, APIs, background processes, audit logs and integrations behind the scenes.
The user doesn't need to know all of that.
If someone needs to register a student, they should simply be able to register the student.
If a storekeeper needs to record stock, the process should be clear.
If a cooperative member wants to check a balance, it shouldn't feel like an accounting examination.
The technology should carry the complexity.
The user should experience the simplicity.
This Is Also Why I Don't Build Everything for Everyone
There is a temptation in software development to create one giant application that does everything.
Schools.
Hospitals.
Factories.
Churches.
Banks.
Restaurants.
Communities.
Everything.
I've become less interested in that approach.
Different industries have different problems.
A school doesn't operate like a factory.
A factory doesn't operate like a cooperative.
A cooperative doesn't operate like a community.
The better approach is often to understand a specific industry deeply and build around its actual workflow.
That's why many of the products I've been exploring are vertical SaaS products.
They are designed around particular problems rather than trying to be everything to everybody.
Technology Should Save You From Your Own Spreadsheet
I'm not against Excel.
Far from it.
Spreadsheets are incredibly useful.
They have helped businesses run for decades.
The problem begins when the spreadsheet becomes the entire business system.
When several people are editing different copies.
When formulas break.
When nobody knows which version is correct.
When information can't easily be shared.
When someone leaves the organization and takes important knowledge with them.
That's when you start asking:
“Is there a better way?”
And sometimes the answer is software.
AI Is Changing How We Build
There is another interesting part of this conversation.
The way software itself is being developed is changing rapidly.
Artificial intelligence can now help developers write code, understand documentation, generate ideas, identify problems and move from concept to prototype much faster.
I've embraced AI-assisted development as part of my workflow.
But I don't believe AI removes the need to understand what you're building.
If anything, I think the opposite is true.
When you can build faster, thinking becomes even more important.
You can create a bad application faster than ever.
You can also create a good one faster.
The difference is understanding the problem.
Good Software Is Not About More Features
This is another trap I see often.
Someone asks:
“Can you add this feature?”
Then another:
“What about this one?”
Then another.
Eventually, the product has 100 features.
But the user still struggles to complete the three things they actually needed to do.
More isn't always better.
Sometimes the best product decision is removing something.
Sometimes it's making one workflow dramatically easier instead of adding ten new ones.
The goal isn't to build the biggest application.
The goal is to build the most useful one.
So, Does Your Business Need an App?
Maybe.
Maybe not.
And that's okay.
You might need a custom application.
You might need a website.
You might need a better internal process.
You might need to automate something you're doing manually.
You might simply need to connect systems you already have.
The answer should come from understanding the problem—not from deciding beforehand that you need an app.
That's how I prefer to approach projects.
What I Really Want to Build
I still love technology.
I love writing code.
I love designing interfaces.
I love databases and system architecture.
I enjoy taking something that doesn't exist and making it real.
But I've learned that the best software isn't necessarily the software with the most impressive technology behind it.
It's the software that makes someone say:
“This just made my work easier.”
That's the kind of technology I want to build.
Not technology for technology's sake.
Not software simply because everyone else has an app.
Technology that solves something.
And if you're sitting with a business problem right now, perhaps you don't need another app.
Perhaps you simply need to find a better way to work.
That's where the conversation should begin.
Let's Build Something That Actually Helps
Have a business process that is taking too much time?
Managing information manually?
Running your organization through spreadsheets and WhatsApp?
Or perhaps you have an idea for a digital product but don't know where to start?
Tell me about the problem.
We can figure out the technology afterward.
Start a Project →