DEV Community: Abdul-Hammed Adeagbo

Building for Businesses Means Building the Workflow, Not Just the Feature

Abdul-Hammed Adeagbo — Mon, 21 Sep 2026 21:29:32 +0000

When you build a consumer app, you can often start with a relatively simple question:

Can the user do what they came here to do?

With business software, that question is only the beginning.

Can they do it?

Who is allowed to do it?

Who needs to approve it?

What happens after they do it?

Can someone else see it?

What happens when the person who created it leaves the company?

Can the business prove what happened three months later?

Those questions change how you build software.

I’ve been thinking about this a lot while building software for businesses, and one thing keeps becoming clearer:

The feature is rarely the whole product. The workflow around the feature is the product.

A business doesn’t experience your features individually

Suppose you’re building a quoting system.

On paper, the feature list might look straightforward:

Create a quote
Add products
Set prices
Send the quote
Approve the quote

You could build every one of those features and still have a poor product.

Because the business doesn’t actually experience “Create Quote” as an isolated feature.

It experiences something more like:

Customer asks for a price → someone creates a quote → another person reviews it → customer receives it → customer accepts or rejects it → the business records what happened → the accepted quote becomes the basis for the next step.

That is the actual product.

The quote itself is only one piece of the workflow.

This is one of the biggest differences I’ve noticed when thinking about business software.

You aren’t just building screens. You’re modelling how work moves through an organization.

The happy path isn’t enough

Consumer applications can sometimes get away with focusing heavily on the happy path.

Business software can’t.

Imagine this:

A sales representative creates a quote.

What if they aren’t allowed to approve their own quote?

What if the customer asks for a change?

What if the quote has already been approved?

What if someone tries to edit it afterward?

What if the employee who created it leaves the company?

What if two people are working on the same customer?

What if the wrong person receives the notification?

None of these are exotic edge cases.

They’re normal business situations.

And they force you to think about things that aren’t immediately visible in the UI:

permissions
ownership
account boundaries
status transitions
audit history
notifications
immutable records
failure states
data consistency

The more important the workflow is to the business, the less acceptable it becomes to simply assume that users will behave correctly.

State becomes part of the product

This is where business software gets particularly interesting for developers.

A business object isn’t just data.

It usually has a lifecycle.

A quote might move through:

Draft → Sent → Approved → Invoiced

But what happens if someone tries to move it backwards?

Can an approved quote become a draft again?

Can an invoice be generated from a rejected quote?

Can a user edit the price after approval?

Can someone approve something they don’t own?

These aren’t merely database questions.

They’re product questions expressed through code.

The database might store:

status = "approved"

But the application needs to understand what approved actually means.

Once you start modelling these transitions explicitly, the architecture changes.

Your API endpoints change.

Your authorization rules change.

Your tests change.

Even your UI changes.

The business workflow starts shaping the software instead of the other way around.

Permissions aren’t an afterthought

One of the easiest mistakes when building business software is treating authentication as the security model.

“Is this person logged in?”

That’s important.

But it’s only the first question.

The more important questions are:

Which business account are they operating within?

What role do they have?

What resources can they access?

What actions can they perform?

What happens when they belong to multiple accounts?

For a business application, something as simple as:

GET /quotes/123

can hide a surprisingly important security decision.

It’s not enough to determine whether the user is authenticated.

The application needs to establish that the user is authorized to access that particular quote within that particular business context.

This is why multi-tenant business applications can become complicated very quickly.

The data isn’t just:

User → Data

It’s often:

User → Membership → Account → Resource → Action

And every link matters.

Business software needs memory

Another difference is that businesses care about what happened yesterday.

Sometimes they care about what happened six months ago.

A consumer application can often focus primarily on the current state.

A business application frequently needs both:

What is the state now?

and

How did we get here?

Who created the document?

Who changed it?

When was it approved?

Who approved it?

Was the amount changed afterward?

Was the customer notified?

Was the invoice generated from the approved version?

These questions become important when money, customers, employees, suppliers, or contractual commitments are involved.

This is why auditability isn’t just an enterprise buzzword.

It can be a practical part of the product.

A good business system should make important events understandable after the fact.

Not necessarily by logging every mouse click, but by preserving the events that matter to the workflow.

Don’t automate a workflow you don’t understand

There’s a temptation when building software to automate everything as quickly as possible.

That’s understandable.

Automation feels like progress.

But automating a bad understanding of a business process can make the problem worse.

If you don’t understand why someone manually checks a document before approving it, removing that step might not be an improvement.

Maybe the manual check exists because:

prices change frequently
a second person needs to verify margins
certain customers have special terms
the business needs two-person approval
mistakes are expensive

Before automating a manual process, I think it’s worth asking:

Why is this step manual?

Sometimes the answer reveals the actual requirement.

The goal isn’t to reproduce every existing manual action in software.

The goal is to understand the reason behind the action and then decide whether software can improve it.

Build around consequences

The biggest mental shift for me is this:

Business software should be designed around consequences, not just actions.

“Create quote” sounds simple.

But creating that quote may affect:

what the customer sees
what the sales team can do
what the accounting team expects
what notifications are sent
what records exist
what can happen next

The same is true for almost every important action.

Instead of asking only:

What should this button do?

Ask:

What does this action mean to the business?

Then work backward.

What state should change?

Who should be allowed to trigger it?

Who should know about it?

What should become impossible afterward?

What should be recorded?

What happens if the operation fails halfway through?

Those questions produce much better software.

A practical way to approach it

If you’re building a product for businesses, before writing another feature, try mapping one real workflow on paper.

For example:

Customer request
↓
Create quote
↓
Internal review
↓
Send to customer
↓
Customer decision
↙ ↘
Rejected Approved
↓
Invoice
↓
Payment

Then ask five questions at every step:

Who can perform this action?
What state changes?
Who needs to know?
What should be recorded?
What can go wrong?

You don’t need an enormous architecture document.

You just need to understand the workflow before you turn it into endpoints, database tables, and buttons.

Because when you’re building for businesses, the difficult part usually isn’t making the feature work.

It’s making the feature work inside the reality of the business.

And that’s where the real product starts.

[Boost]

Abdul-Hammed Adeagbo — Sun, 20 Sep 2026 08:40:58 +0000

James Anderson

Sep 20

Gemini Hacked Three Companies Using the Dumbest Trick in the Book

#ai #agents #security #webdev

6 min read

The Hardest Part of Building Software Isn’t Writing Code

Abdul-Hammed Adeagbo — Sat, 19 Sep 2026 19:25:40 +0000

I used to think becoming a better developer meant learning more technologies.

React.

Node.js.

PostgreSQL.

Docker.

Cloud.

TypeScript.

Another framework.

Another library.

Another tool.

Then I started building actual software.

And I realized something:

The hardest part isn’t writing the code.

It’s figuring out what the code should actually do.

⸻

Tutorials don’t prepare you for the messy part

A tutorial can show you how to build authentication.

Create a user.

Hash the password.

Create a session.

Set a cookie.

Return the user.

Done.

But a real application immediately asks you a completely different set of questions.

What account does this user belong to?

What if they belong to multiple accounts?

Can they access another company’s data?

What happens when their session expires?

What happens when the database is unavailable?

What happens when the same request is sent twice?

What should the API return when something goes wrong?

Suddenly, you’re no longer just writing code.

You’re designing a system.

⸻

Software development is mostly decisions

The more I build, the more I realize that development is basically a long chain of decisions.

Should this logic live in the frontend or backend?

Should this be a separate service?

Do I actually need another dependency?

Should I refactor this now or keep moving?

Should this data be stored permanently?

What happens if this component fails?

Will this decision still make sense six months from now?

There isn’t always a perfect answer.

Sometimes you’re simply choosing the trade-off you understand best.

And that’s a very different skill from knowing syntax.

⸻

A great stack doesn’t automatically create great software

You can have:

Next.js
React
Node.js
PostgreSQL
Prisma
Supabase
Docker
GitHub
Vercel

…and still build a badly designed application.

The technology isn’t the architecture.

The technology isn’t the business logic.

The technology isn’t the security model.

The technology is a set of tools.

What matters is whether you understand how the pieces fit together.

⸻

Sometimes the bug isn’t in the code

This has probably been one of the most important lessons for me.

Something can be “broken” even when the individual pieces of code look perfectly reasonable.

Maybe the frontend expects one response while the API returns another.

Maybe authentication works locally but behaves differently in production.

Maybe the database schema technically works but doesn’t represent the actual business relationship.

Maybe the feature itself was poorly defined.

So debugging isn’t always:

“Find the broken line.”

Sometimes it’s:

“Find the broken assumption.”

And that requires understanding the system.

⸻

This is changing how I learn

I’m still learning technologies.

But I’m trying to learn them through problems, not just tutorials.

Instead of:

“How do I learn Prisma?”

I’m more interested in:

“How should my application model this relationship, and how can Prisma help me implement it?”

Instead of:

“How do I use authentication?”

I’d rather ask:

“How should identity and access work across this application?”

Instead of:

“How do I deploy Next.js?”

I’d ask:

“What does this application need in production that it doesn’t need locally?”

The technology becomes the tool.

The problem becomes the thing I’m actually trying to understand.

⸻

I don’t want to know 47 tools

I don’t want my definition of being a good developer to be:

“I know more frameworks than you.”

I’d rather become the person who can look at a complicated system and ask the right questions.

Where does this data come from?

Who is allowed to access it?

What happens when this service fails?

Where should this logic live?

What happens when the user does something unexpected?

How does this feature affect the rest of the system?

What will become painful six months from now?

Those questions interest me much more now.

⸻

The real milestone isn’t “I learned the framework”

For me, the bigger milestone is being able to take an idea and gradually turn it into a working system.

Idea → workflow → data → API → frontend → authentication → deployment → bugs → debugging → improvement.

Then do it again.

And again.

That’s where the learning starts becoming real.

Because eventually, you’re not just learning how to write code.

You’re learning how to think in systems.

And honestly, that’s the kind of engineer I’m trying to become.

Not someone who knows every tool.

Someone who understands enough to build, debug, and improve complicated things.

⸻

What has been the biggest difference between learning to code and actually building software for you?

webdev #programming #softwaredevelopment #javascript #nextjs #backend