We’ve all read the statistics about the survival rate of new ventures. Depending on the identity and agenda of the one quoting figures, you may hear percentages from 20-90%, over a range of periods—if taken from a study—from 1 to 5 years. Entrepreneur magazine provided a readable, clear breakdown of the many ways of viewing and measuring failure in a January 2021 article. Whatever the measurement period, we can possibly agree that there is a significant rate of failure, and with it, lost investment in time, hard work, and stress reaching for goals while running on tight constraints.

Lessons from Failure

The technologist who emerges from this world, in a healthy scenario, would take some time to assess the experience, and might come to some conclusions. Some of them might be:

  • “I’ve learned to work more closely with designers and product managers, and have had a lot of scope I did not have previously in my work. I think I prefer more structure in my next opportunity.”
  • “This was OK, but the chaotic development schedule, constantly chasing the demo for the next sales meeting, meant that we never really got to develop the technology to a state of ‘fit for purpose’. We kept faking it till we [didn’t] make it.”
  • “I’ve learned new Technology X, and got to apply it in a limited production scenario. That will serve me well in proving I have the chops in this space to be credible not only to investors, but to a new team. I’m ready to do my own now. I wish I could only take the code from our failed venture, clean it up, and build upon it.”

Each of these folks have healthy individual take-aways from the experience, and will likely file them away to apply in their future opportunities. With a good dose of luck, a very fortunate few will find the path to the entrepreneurial promised land of the successful exit.

So far, so good, right? What’s wrong with this picture? Nothing, right?

Typical Unhealthy Reactions to Failure

What is certainly not healthy is the immediate write-off that the owners of the outgoing business take on the investment in building the team and the software assets. The team is dispersed to the wind, individual players once again on their own, left to fend for themselves. Once again, in their new places, they will need to learn to work together with a new set of players in a new context. What understandings they formed and efficiencies they gained as a unit are gone, as players in new settings learn to work together. Every startup does this, and ignores the economies and risk reduction to be found in a team that already exists and has a history of delivering together.

In certain cases, not altogether rare, there are segments or even whole systems that might be salvaged and re-purposed in other settings. Business owners with the foresight and both commercial and technical acumen will see the opportunities to gain leverage in the new commercial context by solving problems with already running software assets. While it is possible with some level of knowledge transfer, it is better to have at least some of the original team that assembled the system to carry on its new operational life.

The Dream from Experience

This is the experienced entrpreneur’s aim: to develop innovation under advantageous conditions with high control over risk. The novice entrpreneur will want to do everything anew, green field, to do it “right”. There are arguments for this approach, when trying to solve novel problems around a commercial niche or in order to develop assets that in turn deliver a new value stream.

We have seen, in no particular order, at various points in time, developers building database object relational mapping software, UI toolkits, and billing infrastructure. While all of these types of software have a vital place in the delivery of software and user experience, they are hardly new problems, and all have convincing, mature, well-maintained solutions in the open source community. In other words, there are giants with very large shoulders ready and happy to be stood upon.

Today, new development with a view to global scaling should have a laser focus on customer acquisition, then revenue generation, then customer retention, using as many existing assets as possible to support those activities. New software investment should capitalize on existing experiences, existing platforms, and good practice to deliver as much of that with off-the-shelf tools as possible. This is not, of course, an argument for low-code or no code technologies. Those approaches and tools have their place in concept testing with MVPs and at certain scales where they are indeed “good enough”, but it is rare that a highly constrained SaaS service looking to reduce barriers to entry will provide the level of flexibility required for the customization a growing global business will need. The exact trade-off and inflection points for decision are to be considered based on the individual case and circumstances.

A Different Way: The Cydeas Way

Entrepreneurs and investors oriented to the long game should consider a different model for developing technology driven businesses, to avoid the deplorable waste we have just described:

First, treat a technology team as an asset to be preserved, since it takes months, if not years, for a group of motivated, smart people to become a high performance team. During the lifecycle of a typical startup, one, perhaps two major releases can be managed before the team must disperse. Imagine how much more can be accomplished if, regardless of the problem to be solved, that team can stay together. Are you running around calling yourselves a technology company? Then act like you mean it.

Second, treat the technology itself as a first class asset, not a secondary by-product of the business. Despite all protestations and concern over a non-specific notion of “IP” and other startup culture buzzword babble, we have yet to see many examples of startups truly treating their software as assets, unless there suddenly arises a competitive threat from outside the company, or from their own people leaving for whatever reason. Business owners closing down a business never offer the software to their outgoing team to see what can be done to preserve the investment.

When we started Cydeas, some of us had already worked together in various configurations and places for nearly eight years, and relished the opportunity to continue to work together and to continue to grow together. We saw a chance, finally, to build, preserve, and maintain a mature foundation of code and a set of techniques that will follow us, we hope, from success to success.

We operate as a software studio that builds businesses in which we take an active ownership interest. We are not an outsourced or contract development shop. Our purpose is rather to develop, launch, and grow going concerns that deliver tangible value to our customers. In the process, we build unique technology environments and assemblies that power our operating companies, and belong to us by definition as owners.

We expect to profit handsomely from our dedication to the long term stewardship of the technology we build. We stay together, and preserve and enhance our code for as long as our ventures’ operating companies need us to do so, enormously de-risking and optimizing the process and timing of building their long-term, self-sufficient capabilities. We believe this is the best way for us to protect and enhance the tangible and intangible intellectual capital that resides in our code and in our ourselves.

In this way, we will do better. Watch this space. We’ll see together how it goes.