Why Getting Laid Off Made Me Stop Chasing Stacks and Start Understanding Businesses

Why I stopped starting with tech stacks and started understanding businesses first

Two years ago, I joined a project that seemed straightforward: build a an invoice reconciliation system for a supply and chain logistics company.

The team was experienced. The timeline was reasonable. The requirements seemed clear.

Six months later, we’d built something technically impressive that the business couldn’t actually use.

The problem wasn’t our code. It was that we never understood what the business actually did.

We’d spent months debating Monolith vs Microservices, arguing about database design, and optimizing for performance. We built exactly what we thought they needed.

We just didn’t understand what they needed it for.

The result? A a year re-write of the main product, followed by a massive lay-off of both the product and 30% of the engineering team is why technical skill without domain understanding is expensive guesswork.

---

The Questions We Should Have Asked First

Here’s what we focused on:

• Which framework should we use?

• How should we structure the database?

• What’s the best way to handle authentication?

• Should we use microservices or a monolith?

Here’s what we should have asked:

• What does this business actually do day-to-day?

• What are the key business events that define their operations?

• How do different departments interact?

• What processes are they trying to improve?

We were solving technical problems while the business had workflow problems.

---

This pattern repeats everywhere in software development.

The typical process:

1. Stakeholder describes what they think they need

2. Developers translate that into technical requirements

3. Team builds exactly what was requested

4. Product doesn’t fit how the business actually works

5. Expensive rework cycle begins

What’s missing: Understanding the business domain before building anything.

Software projects fail because they don’t start with a clear, shared picture of the domain. Without this foundation, you’re building on quicksand.

No amount of technical skill can fix software that’s disconnected from actual business needs.

---

After that expensive failure, I completely changed how I approach projects.

The domain model became my starting point.

A domain model is a formal representation of how your business works—its processes, rules, and workflows. It captures what the business does without getting lost in how technology might implement it.

The key insight: The domain model is the backbone of your application.

Not your framework choice. Not your architecture patterns. Not your database design.

Your understanding of what the business actually does.

---

Here’s the process I now use for every project:

Step 1: Map the Domain First

Before writing code, I map out the business domain.

Key questions:

• What is this business’s core purpose?

• What are the main departments and how do they interact?

• What events happen daily that define operations?

• What rules govern how work gets done?

A visual map of business processes that everyone can understand.