How Software Companies Die: Feature Factories

The story tends to always start the same way: Someone is bored of their corporate job and decides to start their own company.

This individual has likely worked a long time in their corporate job(s) and has a good understanding of the business domain. But not only that, over time, they have accrued quite a decent amount of connections that makes the “let’s start our own thing” seem very viable. The first few customers appear to be just around the corner! And they really are, if things go decent enough.

So, the founder starts their own thing, perhaps they’re a developer themselves, or perhaps they “know a guy”, or perhaps they just will spend a few thousands of dollars on an outsourced team or even a few hires. It doesn’t really matter, the founder has enough capital to get a small team going, which is enough to kickstart development.

That way, the newborn startup launches onto their crusade. The initial goal is very clear. The core, minimum functionality is well-defined, after all, they’ve been working in the business for quite a long time, they know the minimum requirements by heart. But not only that, they also know how to improve the value proposition. They know how to differentiate themselves from “those big companies that nobody really likes”. They have the killer featureset to make a difference. Triumph looks unavoidable.

Except for one thing.

Well, a couple of things actually.

The money $STARTUP raised, or the savings they have is limited, so for this to succeed they need to start generating some revenue quick. And by quick I mean right now.

But revenue isn’t the only issue, $STARTUP just heard that there’s a company doing something similar in Canada, or Europe, or Thailand, or wherever. They have a more limited offering, but they already have some customers.

The landscape quickly became much more complicated.

So, optimistically, they work hard to make up for the time-to-market difference. They institute, like most startups, a fast paced rhythm, with the team pouring heart and soul into the product to try and have something to show. Emotions run rapidly and decisions are made hastily, but there’s movement and that’s what matters. It’s going to be worth it.

Some time later they start having some demos, talking to prospective customers. Some corners are cut because these prospective customers don’t need all those features planned for the initial version. So the MVP is streamlined a little bit more.

Eventually, a particular prospect seems very interested, and the entire team starts to fine-tune the MVP to cater to this prospect needs. The two companies even start working together on the integration and some testing until one day a contract is finally signed. The first paying customer! Excitement runs through the team and makes everyone forget (or forgive) the exhaustion for a while.

But, now $STARTUP has a customer, hence, they also have a responsibility. So the primary focus goes on expanding and customizing the product to make the customer happier. In the meantime, the founder works extremely hard trying to find more customers.

A few more customers eventually arrive, the team now has to manage different requests, and the product starts to expand. The needle is starting to move from “MVP” in the direction of “Product”.

By now, the founder probably spends half of their time trying to get leads and the other half attempting to manage the product and the dev team. Obligations and duties start to arise: paperwork, licensing, operations, finances, establishing a decent sales funnel. The founder is spread more and more thin, the team is able to maintain the rhythm by cutting some corners, not thinking too much and just tackling each thing as it appears. The product is far from complete yet.

Then, one day, there’s one big prize to compete for: The Whale. Either by sheer luck, good connections and persistence, or a combination of both, the founder has came across their first Whale. A humongous company that is willing to be talked into buying the product. It seems more like a fantasy than a real thing, but it’s still worth doing, after all, such a customer would take the company to a whole different level.

What’s even crazier: After some talks, it seems like The Whale is interested in moving forward and partnering with $STARTUP! But, there are a few conditions to be met. A company as big as The Whale does not just make decisions in a couple of meetings, no.

For The Whale to close this deal, approval is needed from various important stakeholders, not always with the same opinion on things. Also, $STARTUP’s product is not quite there yet, so there will be the need for some adjustments. “Of course” the founder says.

All the managers and execs from The Whale eventually agree on a batch of things that need to be done in order for the deal to move forward. So both companies agree on the steps to take, and may even sign a contract saying so.

So the Dev Team focus changes rapidly. The priority is now to make The Whale happy. And that happiness must be attained in a very specific timeline, as per the contract signed. So all gears shift to fulfill those requirements ASAP.

Even more corners are cut, giving them something is all that matters. And don’t even get me started on the other customers. Everything they ask is solved with the bare minimum of resources (sometimes not even that). Unless they really get angry, in that case the dev team needs to put two fires at the same time or there’s going to be big trouble.

Now that The Whale is a customer, $STARTUP has a revenue bump, and a reputation bump, so they can go and try to get some funding to grow the team to evolve the product faster. After all, it is evident that doubling or tripling the team will instantly bring 2-3x productivity gains.

Right?

So, $STARTUP gets the funding. At first it looks like quite a bit of money but when factoring the cost of the new expanded team, it becomes apparent that runway is limited. Doesn’t matter, the founder thinks, we need the capacity increase or we’re not going to make it.

So the team is resized, now there are 3, 5 or even 8 developers working on the same product, where 2-6 of them are new. The founder is still in charge of the product and most of the tech decisions, perhaps they promote one of the older devs to a lead position to help with this.

So now there’s a lot of people that need to work on a lot of things. There aren’t really any established process in the technological sense, since so far it was only a couple of people just trying to have something to show.

Suddenly there are a number of git conflicts, every deployment is a gamble, nobody knows what’s going on with the database, let alone knowing what is happening in the production server. A few ideas come up from whithin the team: we need to rewrite this from this tool to that tool, we need to have a separate service for this, we need a new server.

The “lead” dev is not quite convinced of anything, let alone able to convince the founder to spend some time doing who-knows-what tech stuff that not a single customer cares about. So the founder ultimately has the lat word in every technical decision, because they’re the voice of the customers and the customers are the only thing that matters.

So, tech decisions are made just like anything else in $STARTUP, to the best of their ability. Architectural decisions depend on whatever can please Whale 1 the fastest, because our actual goal is to finish the requirements we promised Whale 2 (yes, we have a Whale 2 now).

It’s not easy to be in the founder’s shoes. They have to please so many people! And the dev team is so frustrating, so many people that can’t move forward with their simple, one-line, totally not contradictory nor ambiguous requirements! Devs are always the same, always complaining, always finding issues, they always say: “this can’t be done”, “that’s not so simple”. Always a problem. In the end, they just cost an insane amount of money and accomplish very little.

It’s because of this that consistency, observability, security, reliability, even functionalities, they end up as second (they wish) class concerns when compared to the new number one goal: Keep the engine running.

What engine? Well, the engine of being able to charge customers for a few more months, of course. We even have one or two or three more Whales to be concerned about. Several smaller customers have left because the system was so unreliable, and them being small can’t justify paying for something that doesn’t work half of the time. They heard $COMPETITION is easier to use anyway. Also, one of The Whales is not very satisfied with what they’ve got themselves into. “But we can still turn them around”, the founder thinks.

The founder is not entirely worried. After all $STARTUP has gained one or two new customers, and there are a few interesting leads, so all in all things aren’t that bad.

Going back to what the customers want, the founder thinks that the system should better accommodate the customers workflows. The product needs to make the life of the user easier. Which user? $STARTUP has so many users and so many features, such a diversity in workflows and expectations. Worry not, we’re going to accommodate all of them, the founder says.

The Dev Team can’t make too many changes to make the UX better, because since $STARTUP took a revenue hit, the team has shrunk a bit and capacity is tight. No problem, some adjustments here, some tweaks there, some copypast-… I mean, component reuse, and we should be able to get where we want, the founder says to the team.

Changes keep rolling out, and this excites the founder, who is able to demo a new feature once again. But 3 bugs bring the demo to a halt. 2 new bugs, and didn’t we fix the third one 3 weeks ago? Oh well, the two experienced devs were able to fix them quite quickly. We’re ok now, the founder thinks.

The bugs keep coming and the devs keep fixing them. Every now and then a sneaky bug appears, one that takes a couple of days and makes everyone really frustrated, really emotional, and really tired.

But the devs always end up fixing them. “Gotta give them that”, the founder says to their friends, “they make a mess, but they always end up fixing it”.

One day the most senior dev tells the founder they’re leaving $STARTUP. They’re really sad to go, but the new place pays better and they always wanted to work in $TECH_STACK. Or so they said. The founder is worried, but determined to continue, the Dev Team should be able to do ok with some junior developer. “Energy is what we really need” the founder thinks.

So they get a new guy and eventually he starts to work on a few features. There’s a spike of bugs again, bugs that could’ve easily been prevented. “we don’t touch the Web.config file when we upload the new version through FTP” explains the now-most-experienced dev in the team.

Time passes and features seem to take longer and longer. Bugs seem to be more and more frequent, and more obscure too. A few of the other devs quit too, and cash is tight so one position is not getting filled up again. Features start to take even longer. When they ship, they’re seldom complete.

Customer complains are more and more frequent, the system appears to grow more and more brittle every day.

More resignations arrive. The founder needs to hire an outsourcing company in order to fill the positions. The new team needs to learn everything from scratch. Regressions are common currency. Customers have a harder time accepting the explanations from the founder. One other Whale leaves. A few smaller customers also leave.

Turnover in the outsourcing agency is fast. It’s very hard to maintain the knowledge in the team, but there’s really not enough time to write docs, we need o get back on track with our customers.

The outsourcing agency terminates the contract with $STARTUP. The founder finds a new team. The cycle starts again.

Remaining customers grow more and more tired of the absurd unreliability of the system for even basic things. It’s like the product had contracted a disease. But the disease not only affects the software, it spreads through the team too. Morale is lower than it ever was. The new team is exhausted, and the founder’s mental and physical health has taken a toll.

Every change is accommpanied of fear of breaking something, everything takes a disproportionate amount of time to implement. Some of the Dev Team members eventually flip a switch and stop caring. Both the velocity and the quality take a hit.

Defect rate grows higher day by day, and so does disatisfaction. More customers leave and closing new deals is getting harder.

Revenue dries up and the founder has to downsize the dev team. Keeping up with the bugs it’s hard, let alone writing a new feature. Customer contracts are not renewed, some are outright terminated.

Eventually the financial situation gets bad enough. The founder sends a “we’re closing” notification to the few remaining customers, a few don’t really care, the others ask how to move their data out. The founder starts to iron out contractual termination issues with the customers.

The founder holds a meeting with whatever’s left of the dev team. “We’re going to put the project on hold while we try to raise funding”. The outsourcing agency never hears from the company again and the devs are relocated to new projects. Until one or two of the devs are asked to help with exporting the data of the customers.

The founder thinks on what to do next while trying to figure out if the IP and customer data is worth selling (or if someone would be willing to buy it).