I left the company I am writing about approx. 1 1/2 years ago and now, after gaining some distance, I thought about what went wrong.

Disclaimer :

Technically, it was not my startup because I wasn't the CEO but I started as employee #1 and left the company just two months prior to bankruptcy.

Near the end of my employment I was the team and technical lead. However, despite this position I was not involved with internal accounting and controlling. As such, my personal opinion is based on the fact that I was a long term employee where I worked for the company through its entire life span.

My humble advises

Get a customer before you even start

Although we had investors, there was a plan to start with one customer to continue a project from our common previous company. However, the latter suddenly decided to keep the customer so we had to begin product development from scratch.

Now there is a big challenge if you are not targeting end customers but industrial ones. You might approach large companies that have a global procurement manager who asks what your references are (none), how many employees do you have (1) and what your annual revenue is (0€). Even if you get the tech department or project manager of a potential customer to totally love your solution, after answering those above questions you're most likely out.

Now, there is a problem: Without getting an order, you won't get references and revenue. Without having those, you will most likely fail when trying to do cold calling.

The other option is to partner-up with companies that adds value to your solution. e.g. hardware manufacturer, security solution provides etc. We did that, but probably too late.

Get at least one senior software developer

Here comes the second problem: At that time, I was - at best - a motivated, experienced software developer but far from a senior (and not hired as such btw). Obviously, I was in the second phase of a developer, I though I could rule the world, wanted to make up bad (or missing) decisions from the past by doing everything in a most abstract, modular and configurable way. Moreover, the CEO also played the role as project lead (in which he was very good and experienced) and technical lead.

For the latter, he considered himself as a good Perl developer (which he was not and and even if, it might not be a good option to run Java based company) and that would qualify him as senior developer (which did not). Plus, he was not coding or even able to understand the code we've written.

Do agile development

Then, we decided (it was mostly my proposal) to do a SPICE-based waterfall project management approach (I didn't know about agile at this time). That led to a two-year product development where we did requirements engineering, software architecture, software design, test cases and even code generation.

The architecture was OKish because I put a lot of effort in it but it did't work out in many cases. It would have been better to step-by step at features and extend the architecture as necessary.

Code generation was obviously not a good idea because it didn't created compilable code and didn't consider dependencies well. That led to a spiderweb off dependencies and cyclic dependencies which obviously made testing very hard.

But the worst part was that we developed a feature rich but vastly over-engineered, configurable and platform-independent monster (see second stage of every software developer above). System testing was pain in the ass. After seven years working for that company, I can tell that we only used very very few of the configurable options in real customer scenarios but all had to be tested.

We should've really started with an MVP using agile software development and try getting out the software to a customer as soon as possible and then adding features requested by customers bit by bit.

The good parts

I really learned a lot. This was an opportunity for me to find out what I like and what I am good at and work in various fields from defining development processes, doing requirements engineering, software architecture, test management, working with multiple languages and frameworks as necessary as well as multiple customers. It was something I wouldn't want to miss and what still helps me to make decisions today. After working for a large company before, this was very refreshing to have flat hierarchies, avoiding unnecessary tasks and a lot of freedom.

Conclusion

Honestly, even if advices 2) and 3) would have been followed from the beginning, I think not having a customer with a sustainable contract (we had customers but mostly some PoCs) broke our neck because you need to make money eventually. And I saw a couple a start-ups with shitty solutions but they sold them well and made a hell out of it.