How I Build Software That Solves Real Business Problems

Whenever a new project comes up, people jump straight to the tech questions.

Should we use React or Next.js? Python or Node? Postgres or SQL Server?

Fair questions — but they're rarely the ones I ask first. Before I open my laptop and start comparing frameworks, I want to know one thing:

What problem are we actually trying to solve?

Because you can build something genuinely impressive — clean code, elegant architecture, all of it — and still fail completely, if it doesn't make someone's day-to-day work easier, faster, or less error-prone. Nobody cares how clever your stack is if it doesn't fix anything real.

Start with the problem, not the tech

Picture a company where someone spends two or three hours a day copying numbers out of Excel and pasting them into another system. It's tedious, it's error-prone, and everyone hates it.

A lot of developers would hear that and immediately think: "Okay, React frontend, Python API, let's go."

But that's not the problem. The problem is manual data entry — full stop.

The actual fix might be something much less glamorous: pull the Excel file in automatically, validate it, drop it into a database, and ping someone if anything looks off. No fancy UI required.

Here's the thing — the person doing that job doesn't care whether it runs on React or Laravel or whatever's trendy this year. They care that the two-hour task now takes ten minutes.

Technology is just the tool. The business problem is the destination. It's easy to forget that when you're excited about a new framework.

Watch how the work actually happens

Before I touch any code, I try to understand the real workflow — not the one described in a meeting, the one that actually happens on the ground. I ask things like:

Who's doing this task day to day?
Where does the information come from, and where does it end up?
What happens when something goes wrong?
Which steps are pure repetition, and which need an actual human judgment call?
Where do delays creep in? Where do mistakes usually happen?

A process that looks clean on a slide can turn out to be a mess in practice. Something like:

Customer Order → Sales → Excel File → Email →
Operations → Manual Entry → Production →
Quality Check → Final Report

That one line hides five people, three spreadsheets, a dozen emails, and hours of manual busywork. Until you actually map it out, you don't see any of that.

And once you can see it, you can finally ask the more useful question: which part of this actually needs software?

Turning a messy workflow into a real system

Say orders come in through email. Instead of someone reading each one and typing it into a database by hand, the flow could look more like:

Email → Document Parser → Validation →
Database → Business Rules → Dashboard → Notification

Now the computer is doing what computers are actually good at — chewing through repetitive information, checking it against rules, moving it between systems, spitting out reports, firing off alerts. And the humans on the team get to spend their attention on the stuff that actually needs a brain: judgment calls, exceptions, relationships.

That's the point where software stops being "an app someone uses" and starts being part of how the business actually runs.

Build the smallest thing that's actually useful

Here's a trap I've fallen into myself: designing the entire system on day one. Microservices, Kubernetes, event-driven everything, AI agents bolted on for good measure, five different databases.

All of that can be useful — eventually. But if the real problem is "we need to stop manually copying this spreadsheet every morning," none of that matters yet.

A small, boring application that reliably solves the actual problem beats an elaborate architecture that takes six months and impresses nobody who has to use it.

So I try to build the smallest version that's genuinely useful, put it in front of real people, and watch what happens. Users will surface problems in a week that you'd never catch staring at a design doc for a month.

Data is usually the real center of gravity

Strip away the UI, the dashboards, the automation — almost every business system comes down to data. Orders, customers, inventory, production numbers, transactions, documents.

If the underlying data model is a mess, everything you build on top of it inherits that mess. So I spend real time thinking through questions like: where does this data actually originate? Who owns it? How does it change over time? What needs to be stored versus calculated on the fly? What needs an audit trail?

A dashboard can look gorgeous and still be lying to you if the data underneath is wrong. For business software, getting the data right matters a lot more than making it look impressive.

Connect systems instead of tearing them all down

Almost no business starts with a clean slate. You'll usually find some combination of an ERP system, SQL Server, a pile of Excel files, an old PHP app nobody wants to touch, a few REST APIs, maybe some industrial equipment thrown in, plus email and accounting software holding it all together with duct tape.

The instinct is often to rip it all out and start fresh. Usually that's the wrong call. More often, the real win is connecting what's already there:

ERP ──┐
      ├── API
Excel ┤
      │
Email ─→ Integration Layer → Database → Dashboard / Automation

Good software frequently ends up being the bridge between systems that were never meant to talk to each other in the first place.

Automate carefully — don't just speed up a broken process

Automation feels good to build, but automating a broken process just gives you a broken process that runs faster. So before I automate anything, I ask whether the process even makes sense in its current shape.

Maybe a five-step approval chain should really be three. Maybe three separate spreadsheets should be one table. Maybe that daily report someone builds by hand every morning shouldn't require a human at all.

Simplify first. Automate second.

Judge software by what it actually changes

The difference between a side project and real business software comes down to how you measure success. A side project works if it, well, works. Business software should move a number somewhere.

Something like:

Before: 3 hours of manual work, 5 people touching it, frequent data-entry mistakes, one report a day.

After: 20 minutes of automated processing, one person reviewing the exceptions, validation before anything hits the database, a live dashboard.

That's when you can actually talk about value — maybe it saves 50 hours a month, maybe errors drop 80%, maybe leadership sees numbers in real time instead of waiting until tomorrow morning. That's what matters. Not which framework it's built on.

A developer's job is bigger than writing code

I don't think being a good developer just means writing code fast. It means looking at a messy process and asking why does it work this way? Then digging into what's actually causing the pain. Then figuring out if software can even fix it. And finally — what's the simplest, most reliable thing we could build to do that?

Writing the code is one part of that. Understanding the business, the data, the people, and the constraints around all of it matters just as much.

How I actually approach a project

Roughly, in this order:

Understand the business problem
Understand how the work actually happens today
Find the bottlenecks and the repetitive stuff
Define what "better" actually looks like
Design the data and the system around it
Build the smallest useful version
Get it in front of real users
Measure what changed
Improve, then expand

That order keeps technology where it belongs — as a tool in service of the problem, not the point of the exercise.

Final thought

The best business software isn't always the most complex. Sometimes it's a sprawling platform with a dozen services. More often, it's a small internal tool that finally replaces a spreadsheet everyone secretly hates. Sometimes it's just an API quietly connecting two systems that never used to talk. Sometimes it's an automation running in the background that nobody even thinks about anymore.

What matters is the outcome — less manual work, fewer mistakes, better information, faster decisions, more reliable operations.

That's the software worth building. Not because we can. Because it makes the way people actually work a little bit better.