Why Company Stage Matters

“That’s a startup.”

A two-person team that just raised Pre-seed is a startup; a hundred-person company that raised Series B but is still burning cash also calls itself a startup. Same label, completely different worlds.

Even among startups, the shape of the company can look completely different depending on the stage. And since the definition of “startup” itself is so vague, instead of using “Should I work at a big company or a startup?” as your decision criterion, it’s better to evaluate the company by stage.

That way, you at least have more concrete indicators to help you decide whether to join. Compared with company size, the stage it’s in right now—what it survives on, how it grows, and what its biggest bottleneck is—directly affects team culture and the working atmosphere.

Why you should care

An engineer in different stages of a company does completely different work. An engineer in the exploration stage might write backend code today, adjust the landing page tomorrow, and attend a customer meeting the day after. An engineer in a mature company might spend three months focused only on optimizing a single subsystem’s performance.

A PM in the validation stage is judged by whether people are willing to pay. A PM in the growth stage is judged by whether it can scale.

Every stage has a completely different definition of “good.” If you don’t understand the company stage correctly, it’s easy to develop unrealistic expectations about the job.

• I’m a developer, so why do I have to do so many unrelated chores?
• Why do I keep getting blocked whenever I want to refactor?
• I just want to change a button and fix some styles—why do I need to go through four or five processes?
• Technical debt keeps piling up, and maintaining the codebase is exhausting

You clearly want to make the product better, but everything you do seems wrong. Over time, the result is burnout and resignation. “Building things together” sounds beautiful, but under capitalism, you’re just a chess piece that can be replaced at any time.

You may think the company is chaotic and lacks process, but maybe it’s simply still in that stage. On the other hand, lots of process and lots of rules don’t necessarily mean maturity either—it may just mean the company has started to ossify.

Four stages

The following is my own summary based on observation. Companies in each stage have their own characteristics, and you can use them to judge whether the work environment is a fit for you.

The x-axis is time, and the y-axis is money. For a SaaS startup, there is only one goal: Growth.

More specifically, you need to find the turning point before the runway runs out and achieve exponential revenue growth. Everything you do, and everything you produce, should align with that goal.

The descriptions below all revolve around this core theme.

Exploration stage

Still looking for the market, the problem, and the direction. The founder drives everything; what is A today may become B tomorrow. There is no stable process, and many things are still in the trial-and-error phase. What matters in this stage is finding direction, so the key is to iterate quickly, fail quickly, and gather critical data.

Key question: What problem are we actually solving? Does anyone want this?

What you need in this stage is speed and iteration. You can imagine that a lot of the code written here is already prepared to die the moment it’s born. You also shouldn’t expect very complete benefits or leave policies at this stage.

As an aside, if you’re still in the exploration stage, I strongly recommend not using AWS yet. There are many PaaS options that can help you increase product iteration speed.

This stage is suitable for people who like chaos and like building from zero to one. If you expect clear role divisions and SOPs, this stage will be painful.

The founder’s values and way of working will heavily influence the company and team culture.

Joining at the exploration stage is highly risky. Unless you want to accumulate experience, or you strongly identify with the company’s direction and want to fight alongside the team, I would recommend not joining during this period. There are several reasons:

• The company is just getting started, and the amount raised may not be high. With a runway that isn’t very long, anything you produce will be scrutinized more intensely.
• If you join as a full-time employee, your compensation will very likely be below market rate, while the amount of work expected from you is higher.
• The product direction will keep changing, and requirements may keep changing too, which can easily leave you at a loss.
• You need to have very high ownership; many things and systems will have to be pushed forward by you alone.

Under that much pressure, you should first ask yourself: “What am I really working for?” That helps ensure you don’t burn out in a high-intensity work environment. All of these conditions can be swapped with higher-level equivalents—for example, joining a Series B startup or a Tier 1 foreign company can also give you an environment with very high pressure and very high ownership demands, but at least they can afford to pay you properly.

Conversely, if you already have a strong motivation driving you forward, then be brave and join. That experience will become your support when facing other difficult challenges later on.

That which does not kill me makes me stronger

Validation stage

There are customers now (there are users), there is revenue, and people are paying—but it’s still not clear whether this model can be repeated. Many results are still being held together by the founder or a few core people, and product, sales, and delivery are often all mixed together.

This period is more stable than the exploration stage. The most important thing is finding Product Market Fit. Is this a viable business? Can this success case be replicated?

Many companies mistakenly think that having customers means things are stable. But in reality, it may just mean the founder is very good at selling. The founder handles sales alone, talks to customers alone, and closes a few deals. It looks like the market has been validated, but in fact it is still far from a “repeatable business model.”

The most important task in this stage is actually finding Product Market Fit. It’s not just about “do we have customers?” but about answering a deeper question: Is this a business that can work? Can this success case be repeated? After the founder steps away, can this method still keep running?

Although early-stage startups should focus on Do Things That Don’t Scale, once you reach the growth stage, you need to start looking for repeatable and scalable ways to grow.

I think there are a few key points:

• Take the experience accumulated through experimentation and intuition in the previous stage, and gradually organize it into systems, processes, and methods to find the truly repeatable pattern
• Validation should no longer rely on gut feeling alone; it should start relying on data
• Begin distinguishing between one-off success and scalable success
• Find ways to reduce dependence on a few key people. As long as growth is still tied to the founder or core members, the company has not truly moved beyond the early stage.

You can expect several characteristics in this stage:

Role boundaries are blurry. On paper you may be an engineer, PM, or designer, but in practice you often do much more than your official role. Writing features while joining sales meetings; handling customer requests while helping organize process documentation. Many things still can’t be cleanly separated.

Requirements still change frequently. The direction is becoming more focused, but it still changes often. A feature might be built for Customer A today, only for you to realize two weeks later that the actual paying segment is Customer B, forcing the priority order to be completely reshuffled—or even requiring custom work for a major customer. You’ll feel that the company is more stable than in the early stage, but it is still far from stable.

Build it first, talk later. This doesn’t mean nobody cares about quality; it means the company is more concerned with whether something is worth continuing to invest in. This is also a major source of conflict for many developers.

Technical debt accumulates. What was left behind during the exploration stage usually starts to bite back at this point. Things that were written for speed will quickly become costly to maintain as customers increase, requirements become more complex, and data volume grows. This is also where conflicts often arise between the engineering team and management.

Growth stage

The company has started to find a repeatable customer segment and a repeatable sales motion, but the organization hasn’t fully caught up yet. Headcount is increasing, middle management is becoming necessary, and the costs of hiring, collaboration, and communication are rising fast. The problem becomes how to turn a few isolated successes into stable success while supporting expansion.

Many companies people work at are in this stage. They are expanding internally while patching holes at the same time.

The product is growing, the organization is growing, and revenue may also be growing—but technical, process, management, and communication costs are all expanding too.

Many problems that were tolerable when the company was small get amplified at this stage. Technical debt starts affecting development speed, and management problems start affecting how the organization runs. The company increasingly realizes that relying on a few exceptional people is no longer enough; it must gradually shift from people to systems.

The company has more people now. Office politics must be dealt with, and meetings, processes, and documents start increasing.

Cross-department collaboration increases. More stakeholders are involved, and communication costs rise significantly.

The requirement is no longer just to build it. It’s not only about making something happen, but about delivering it reliably.

Mature stage

A company in the mature stage has usually already passed through that intense uncertainty from earlier phases.

Its business model is relatively stable, its market position is clearer, and its organizational structure, processes, and management framework are mostly in place. The company no longer needs to prove every day that it can survive, nor is it in the state of trying to find direction while growing at the same time.

As a company gets bigger and more stable, processes and systems bring order—but they also bring inertia. Decision chains get longer, risk aversion increases, and things that used to move quickly now require more coordination, more evaluation, and are more likely to get consumed internally.

I call this the unavoidable problem of the mature stage.

If you’ve worked at a big company, you know that the internal chaos, absurdity, and sheer magical weirdness of most seemingly glamorous companies is far beyond what you can imagine

Clear division of labor. Role boundaries are much clearer, processes are complete, and work has to go through more internal procedures.

Long decision chains. Many things need to be approved layer by layer before they can proceed. For example, opening a new server may require a two-week request process, and logging into the production database requires strict monitoring.

Internal politics. There is competition for resources, and pushing forward the things you want to do becomes harder. Often it’s not that something can’t be built—it’s that it’s very hard to get it moving.

Different stages suit different people

This matters more than ability.

The exploration stage suits people who like chaos and are willing to take responsibility. The validation stage suits people who can fill gaps and fail fast. The growth stage suits people who can build systems and collaborate across departments. The mature stage suits people who are good at optimization, governance, and improving efficiency.

Each stage has different characteristics, and being in a company stage that doesn’t fit you is often the source of burnout.

I’ve experienced this mismatch myself.

I felt very comfortable at a company in the growth stage and thought I was valuable, but after moving to an exploration-stage environment, much of my previous experience became useless, because the nature of the problems was completely different and the company cared about completely different things. The reverse is also true—some people thrive in chaos, but the moment they enter a more institutionalized environment, they feel suffocated and unable to perform.

At the end of the day, it all comes down to differences in cognition. The company stage should obviously focus on A, but you keep thinking about optimizing B.

The company is clearly still in the exploration stage and most needs quick validation and rapid iteration, but your mind is stuck on whether the architecture should be cleaned up first or whether the processes should be fully defined first. Or the company has clearly entered the growth stage, where what it needs most is collaboration, systems, and predictability, but you’re still used to solving everything like a lone wolf.

So I don’t think this is really about a lack of ability.

You’re clearly working hard, but the results keep falling short of expectations. Over time, it’s easy to blame everything on yourself and end up concluding: maybe I’m not actually that capable.

But as mentioned earlier, if you don’t first understand the characteristics of the company stage, the things you’re good at may not match what the company wants. Thriving means being in the right environment. But you also have to ask whether it’s really the environment’s problem, or whether you’re avoiding the hard things.

Once you understand this, choosing your own career path becomes much easier.