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.
Top comments (0)