Of Hamsters And Foxes: How a Failed Startup Can Be a Real Success Anyway

28 min readMay 20, 2016

Subject: Crash Landing :-(

Hey Casandra,
this is the mail I never wanted to write...

These were the first words of a mail I wrote on may 1st, 2014. It was a Thursday, one of my home office days at that time. I clearly remember that it had been a very quiet day. A perfect day for admitting my next entrepreneurial defeat.

When I was about to hit the send button, it was slowly getting dark outside where some huge towering clouds and a loud rumble in the distance seemed to announce a heavy thunderstorm arising. “How appropriate…”, I thought while my message was on its way.

More than two years have passed since then, enough time to reflect thoroughly what had gone wrong. Now it’s time to share some experiences and (hopefully) useful lessons!

Let’s start with a question I often asked myself in the months after I wrote the mail above:

Can a startup be a huge failure but also a big success at the same time?

Quick answer:

Yes, it can!

(Even though this might not be the case very often.)

Our project teamspir.it, which ultimately failed two years ago, is such a kind of “startup”. (I still call it so although it never had a chance to become a spin-off company as initially planned.)

So if it failed, how can this project be a success anyway? I’ll tell you the full story if you are brave enough to read on!

The Problem

It All Started With The Hamster Wheel

We’d come a long way: My co-founder Peter and I had started to develop websites and web based applications for commercial clients back in 1997. Over the years, partners and employees came and went. We had good years, we had bad years, but one thing never changed: We were damn incapable of escaping the day-to-day grind running a web consulting business. We called it our hamster wheel.

Working mainly for small companies — as we did — usually means a lot of work with little profit and a lack of scalability. Constantly working hard just to keep the ship afloat led to a high level of stress and pressure. Not the best climate for real work satisfaction, but perfect for self-doubt and anxiety…

We tried to get more independent from individual client jobs by launching own SaaS projects from time to time: We built a local real estate portal, a driving school portal, a system for helping restaurants to distribute their lunch offers as well as a few other more specific web services.

We made a little bit of cash with all, but never enough to put our full focus on one of them. The funny thing about this is that some of these projects actually had potential, but we were too wet behind our ears to recognize this and mostly gave up far too early. (That’s another story I’ll eventually tell in another post…)

Indeed, not recognizing chances and repeating the same mistakes over and over again revealed our main dilemma: We were not able to learn from our own experiences. In addition, we were not smart enough to realize this for a long time.

This fact leads us to the core idea behind teamspir.it, the startup this post is about. But let me give you some background information on its primary roots first…

The Background

Flashbacks And Cold War Memories

Flashback 1998: I had to do a part of my military service in a little technical equipment museum of the German Air Force. For three long months, I was the only person in the building, at least when none of the rare visitors were present. One day a big stack of slightly yellowed fanfold paper caught my attention. The first page said “Schicht-Erleben” (“Shift Experience”). What the hell..?

It turned out that I’d found a kind of a “private work journal”: A small group of reconnaissance soldiers had recorded their daily work life over several years — 1983 till 1986 if I remember correctly. For me, it was fun to read countless interesting details written with a personal touch! These details usually were not related to the tensed global situation or the great threats of that time (Do you remember the cold war?), they rather described the small nuances that made the teamwork of this particular group strong and enjoyable.

When I was flipping through the pages, I thought that it would be even more fun if I could read this kind of stuff about my own company (which already existed as a part-time business back then) sometime. The same day, I wrote the first entry of our “company journal”. Since then, I frequently recorded the development of the company — and haven’t stopped till today.

For many years, I wrote this journal only for myself. I flicked through my previous entries from time to time, mainly to sentimentally relive some feelings of our various ups and downs. This was amusing indeed, but I never did this in a systematic way, nor did I reassess my notes. It should turn out that this was a mistake…

Flashback 2010: In the middle of that year, we had a veritable crash landing with the lunch offer portal mentioned above. The worst thing then was that we had to lay off two valued employees, which meant that only my co-founder and I were left. This was very painful, but fortunately we managed to get back on our feet again and voilà: 2011 should be the (financially) best year in our company’s history!

Flashback 2012: We had to realize that our “record year” brought a major drawback. We were so exhausted that we couldn’t keep this pace in 2012. Even worse, we were absolutely out of motivation to spin the client project hamster wheel any longer.

As a result, we shifted down two gears and started stumbling around instead of concretely planning how to proceed. Of course, we always thought that we had a plan: Doing no more things we don’t like, doing things we like, maybe developing something like “productivity tools”… Ridiculous, but there were times we called this a “plan” in all seriousness!

Mistake
We’d let ourselves go, burnt money for nothing and did not set a new course for the company when we gave up the old one.

Lessons
One halfway successful year is nothing. Exhaustion and demotivation are not excuses. Although planning is guessing, you always have to be clear about the direction you want your business to go. If you are not, take as much time as you need to think about it before you take any action. Never ever tumble around aimlessly like we did!

The Solution

We Had To Be Smarter. We Had To Become Foxes!

Speaking of productivity tools, while researching for existing solutions I came across a tiny service called iDoneThis around November 2012. I tested it and really liked its uber-simple approach for tracking personal or team progress.

I also liked the idea to take this approach and combine it with a company journal like the one I used to write: Team members could share brief summaries of their daily achievements and experiences for learning, reflecting and strengthening the team spirit together.

Systematically collecting and reflecting shared experiences could help us to solve our main dilemma:

We could build a better company by better learning from lessons of the past. We could be foxes instead of hamsters!

This sounded like a nice idea to me, so I added it to the “Nice Ideas” section in my good old Moleskine notebook. Nice is the keyword here that says it all. To put it plainly, when I scribbled the idea I was convinced that a system like this would be a great tool for our company. I did not think of it as something that could work as a product.

Unfortunately, after several endless brainstorming sessions, we did not come up with a better idea. So we decided to go for the “least bad idea”, which should become teamspir.it. I have to add that we were forced to come to a decision due to financial reasons at that time.

Mistake
We wiped away all of our doubts because we thought that we had no alternative. We called ourselves entrepreneurs, so doing something was better than doing nothing, or so we thought…

Lessons
Nice is not enough! Never start a business if you are not 1000% convinced by its sense and marketability. If it’s obvious that it’s something you only want for yourself, then it’s a hobby, not a business. In this case, be honest to yourself and treat it like that!

The Funding

So here we were, it was the beginning of 2013 and we had to build an awesome web app based on one of my whims. It did not take long before we were facing the first challenge: How to fund the project?

Due to our collective inertia in 2012, we had already burned all of our profit generated in 2011. (A significant amount of our earnings of that year had to be spent only for balancing our line of credit.) Even worse, we’d maneuvered the company deep in the red… again! So at this point, we were in urgent need of external funding.

As already mentioned, planning is nothing more than guessing in many cases. So we guessed that we would need about 12 months to build a “minimum viable product” and to get some traction and the first paying customers. We calculated approximately 10K € in average per month for development, hosting/external services, marketing etc. Ergo, our financial demand was 120K € plus 40K € for rebalancing our line of credit (again…), which equals a total of 160K €.

Unfortunately, the possibilities for funding software projects in Germany are more than limited: Venture capital or anything alike is not an option without having a highly profitable or at least widely used product already. Of course, the right connections or a strong track record can be an alternative in some cases. The same is true for hundreds of public sponsorship programs in Germany: Software? In Germany? Good joke, forget it!

To cut a long story short, there was only one option left for us: Our house bank had to pull us out of the swamp once again. Fortunately, we had (and still have) a good relationship for many years, but three factors were everything else than optimal related to our needs back then:

The revenue of our company had decreased by not less than 50 % in 2012 compared to the “record year” 2011. This negative trend was pure poison for our rating. (The bank didn’t care that the 2011 turnover was a statistical outlier.)
When dealing with small businesses like us, banks usually don’t assume any risks, which — in my opinion — is absolutely ok. This meant in our case: We could only get as much money as we already had. (We had to secure the loan by 100 % from our private reserves.)
A balanced distribution of risks between the partners was not possible.

The result: The maximum loan we could get was 80K €, which was only one half of our calculated… no… guessed financial demand. You might think that the project should have ended before it even started at this point, but then you have underestimated our stubbornness.

Mistake
We simply ignored our own calculation, because we thought that there was no alternative — again! It’s not that we didn’t know that this amount of money was far from being enough, but we said to ourselves: “Hey, no problem! We don’t get more money, so this has to be enough. We just have to get this thing working in half of the time and then we’ll see what’s next!”

Lesson
Don’t be naive! In a startup environment, you will most likely burn your cash much faster than expected. Therefore, expense and revenue calculations prior to the start are too optimistic in most cases. If you can’t raise enough capital for the initial funding, you have to honestly rethink the whole concept and either resize your project or cancel it if there’s no chance to put it into practice with the given financial possibilities.

We were so deluded that we definitely did not rethink our new project, nor did we (want to) think about the possibility of a bailout if it would fail. We were damned to be successful this time! We should have known better, but around March or April 2013, the loan was tied up and we’d finally started to develop the teamspir.it backend and web app almost fulltime. (We’d already developed some basic parts of the prototype earlier.)

The Vision

Every startup needs a vision. We thought that developing a vision should always start by answering the most important “why” question. When we developed teamspir.it, our “why” was:

Teamwork shall be (more) enjoyable and productive…

How should this be achieved?

…by recording and sharing common achievements and experiences.

Here’s how I tried to describe what kind of software solution we’re about to build:

The main and long term goal is to provide an easy-to-use and simple tool that helps building a culture of productivity, recognition and appreciation within small teams: Fellow team members shall be more motivated, satisfied and happy at work by recording and sharing their personal achievements.

The focus lay on the “soft factors”: personal points of view, opinions, emotions etc. These can reveal the real team atmosphere which can’t be read out of “hard” key figures like the numbers of processed records or support cases.

I know this might sound good and I would still sign it today, but wait… Did you notice something? Some paragraphs earlier, I wrote about building a better company by learning from the past in a team context. The “vision” above has not much to do with this goal anymore. Beyond that, its true sense was very nebulous.

Mistake
We didn’t know what a real vision is at all, we just mixed some goals and tried to let the result sound plausible somehow. It was my own fault that in this regard, I didn’t stick to my initial goal (further developing the company through team reflection/learning). The motivation/productivity approach did indeed scratch one of my personal itches, but in hindsight I’m sure I chose it mainly due to marketability reasons. (Other startups are successful with this approach, so why shouldn’t we?)

Lesson
Don’t mix vision and goals and don’t copy other people’s visions. You have to be absolutely clear about why your company or project exists and what makes it outstanding. Be specific and define a vision that gives you and your team a clear focus without room to get off the point!

The Minimum Viable Product

…Without Viability

After we thought that our vision was clear, we started to plan a web app that should match this vision. We knew that it wouldn’t make sense to create a full blown product before even testing the market, so we chose the “Minimum Viable Product” approach. Basically, that was a good idea, but let’s have a quick look at the core feature list of our first “MVP”:

Create “Logs” (logbooks for teams)
Invite Log users
Write Log posts (plain text only + a single image)
Comment Log posts
Like posts of team colleagues
Record current mood when writing Log posts
Receive daily or weekly digests of Log activities

Again, we thought this should be enough features to start with, but we ignored the most important question:

Mistake
We didn’t ask ourselves which real viability we want to offer with our MVP and focused on the pure number of features instead. Why? Because the answer would have put a question mark over the whole project.

The funny thing is that we knew that this kind of feature set could easily be replaced by one of various other solutions that were already available at that time. (Even a kind of an internal blog or a wiki would have done the job our MVP did. We developed a MP only instead of a MVP…)

Lesson
Never define a minimum viable product by the number of its features only, it’s the one quite useful feature that matters! Of course, “useful” is an elastic term. In this context, it means that this one feature must have the potential to attract a critical mass of potential users (another elastic term, sorry!) .

This might be hard, but it comes even harder: Always keep in mind that these users have to be turned into paying customers sooner or later. It’s obvious that this can’t be achieved with stuff like some trivial forms, post lists etc. that we offered with our teamspir.it M(V)P…

The Technology Stack

…And How Not To Choose One

Caution! Now it gets a little bit technical, please skip this section if you aren’t interested in that kind of stuff.

Having a simple MVP has one advantage: Normally, it’s not a big challenge to develop it halfway quickly. This was also true in our case, but that doesn’t mean that we managed to avoid shooting ourselves in the foot… again.

We were experienced “LAMP” developers (Linux, Apache, MySQL and PHP) and had created many projects based on this technology stack. Sure, this was still a stable and proven platform, but times were changing very fast when we were about to build teamspir.it in early 2013.

It was the time when developing web services/apps in pure JavaScript was on top of its hype cycle. Back then, this usually meant Node.js for the backend (server) part in combination with a front end (browser) application on top of a lightweight JS MV* library — we chose Backbone.js for the latter purpose.

We’d already used JavaScript extensively for the front ends of our former projects, so it was a logical step to go for an up-to-date technology stack based on that language this time. Furthermore, it was a good chance to acquire new skills (crucial for every professional developer).

So we jumped right into it, tested a lot and got some very promising results. Unfortunately, testing and developing a real-world product are two very different animals. The same is true for myriads of tutorials on how to build “large-scale web applications” with Backbone & Co.: A single page with a single input field and a list view is anything but a large-scale application…

Mistake
Although we should have known better, we didn’t take into account that getting comfortable with a new kind of technology stack can will extremely increase the development time without necessarily increasing the result’s quality.

Lesson
If you have to hurry to get a (web/app based) product ready for market testing, don’t waste your time playing with the newest kids in town. Use the programming languages, frameworks and tools you are already familiar with to get the crucial MVP job done as fast as possible.

I know this might be tough if you are a passionate developer, but believe me: Speed is far more important in this phase than chasing the currently hyped technologies.

None of your potential customers will care about how you built your solution. Beyond that, if your MVP will be a success, there will also be more than enough opportunities to improve it or to replace parts of your stack by “more modern” technologies.

The Target Group

…That Didn’t Exist

April 2013: Against all odds and many headaches later, we’d actually managed to get our first prototype up and running. It didn’t offer a lot of functionality yet, but at least it was possible to sign up, create logs and to post the first entries. Yeah!

This was also the time I started to prepare the first text contents for the website. Of course, we firstly had to define a clear target group that should be attracted by the descriptional contents. This shouldn’t be too difficult, since “scratch your own itch” was (and still is) the most common advice here. Yes, we were building a product to satisfy or own needs and now we simply had to look for others with the same needs.

But what does “others like us” mean exactly? Other web consulting agencies? Small companies in general? People writing business diaries? History and remembrance junkies (like me)? Defining a clear and understandable vision for our service was hard, but it was even harder to clearly define the main target group.

In the end, we decided to focus on startups, because this seemed to make the most sense: Startup founders should be eager to track their progress and learnings right from the first days on. Beyond that, most of them love to use fancy web based tools. What a perfect match for teamspir.it! But unfortunately, there was a flaw:

Mistake
We never really thought about what kind of users we wanted to reach before we started the project. If any, we only had this very vague idea — “people like us”. We realized this only when were already off the track, so we tried to whitewash this mistake by working out a plausible story… which didn’t work at all. (Basically the same story as for our vision.)

Lesson
The question for whom you develop something is as important as why you are developing it. If you can’t answer it exactly and before you start a project, chances are high that there isn’t a suitable target audience at all. No target audience means no market, never deny this reality — like we did!

The Zombies

June 2014: Keeping the focus is a key success factor for every project or startup. Exceptionally, this was something we were aware of right from the start, but being consistent all of the time simply was not possible for us: We didn’t have any employees or freelance collaborators to support us keeping our almost 100 current web hosting/consulting/service customers happy.

Peter and I had to do everything ourselves. So when we were working on teamspir.it, we had to waste about 50% of our time doing things like updating really old websites, maintaining web and mail servers, troubleshooting client problems by phone or mail and so on.

We had tried to sell our web service business for quite a while, but it soon became apparent that it was impossible to realize a fair price. As a result, we dropped this idea as well as the alternative: simply shutting down this business. Sure, this kind of work wasn’t fun, but the revenues we were able to generate here were still high enough to be a decent financial nest egg.

But then there were also these other projects… For example, the veritable crash landing with our lunch offer portal didn’t mean that this project was completely dead. No, it continued to suck our limited resources. On top of that, we actually distracted ourselves by starting spin-off projects in parallel to the development of the teamspir.it MVP!

Mistake
Beside having to keep our web service business running, we wasted even more time keeping unprofitable activities alive and starting new side projects.

Lesson
Focus on one current venture and cancel all zombie projects that will lead you nowhere. Of course, it’s absolutely ok if you spend time on side activities that are crucial for paying your bills.

In hindsight, feeding zombies and creating new ones while struggling to get our main project market-ready seems pretty insane, but I suppose there was a kind of “subconscious reason” for this: We never really believed that teamspir.it could succeed and therefore wanted to have something up our sleeves. This disbelief may have caused a self-fulfilling prophecy, too. Unfortunately, we have never been honest to ourselves about this fact.

The Waste of Money

If all of the mistakes mentioned so far hadn’t been bad enough, we made another obvious one that in the end broke our neck:

Mistake
We consistently ignored our financial situation and kept throwing money out of the window during almost the whole project lifetime: too high personal withdrawals, senseless expenses for dead side projects, rent for unused office space, paying “business consultants” for telling us things we already knew and so on.

Why? Because we deserved the money for working hard. Because we had to “invest”. Because we’d always managed to repay our credits so far. But — although unspoken — by far the most fatal excuse was: Because it had always been like this, it had always felt familiar and — more or less — comfortable to run a deficit.

Lesson
I know that it sounds like a platitude, but saving money and cutting expenses everywhere you can always have to be the first steps before you even think about external funding or generating any revenues with your project.

Making your startup successful and profitable will be a long ride, every buck (or Euro) you save will give you a little bit more time to achieve this.

The Crash

April 2014: It’s no surprise that it came as it had to come very soon, and this time the crash should be a disastrous one: teamspir.it was still in a very early development phase when we ran completely out of cash. This meant that none of the borrowed money was left and we had also reached our additional line of credit. I had to pump a significant amount of private money into the company to prevent illiquidity.

Although I had mentally prepared myself for this day, it felt like hitting a wall when this worst possible case became reality. Yes, we’d tried various things to avoid this horrible situation, but there must have been a point when we just gave up.

A clean startup shutdown has to begin long before the last penny is spent.

Mistake
We clearly saw the crash coming, but we accepted to be rabbits caught in the headlights. That’s why we were already paralyzed and almost unable to act at all the last weeks before.

Lesson
Accept the inevitable! To recognize what’s inevitable you have to honestly talk about critical tendencies with your business partners and shareholders before they lead you and your team into a complete disaster as it was in our case.

Of course it’s hard to accept that your startup or project will not survive, but despite all that it’s also extremely important to stay in control till the end.

Even if all of your efforts and all the money you invested went down the drain, this is not the end of the world. The sun will continue to rise every day and you will have plenty of possibilities to start new ventures in the future. The best basis for this is a “clean shutdown” that starts long before the last penny is spent.

The Knockdown

…Is Not a Knockout

Yes, these were tough times for us back in 2013/2014, but officially cancelling the further development of teamspir.it was also a kind of release. Beyond that and despite all the blindness mentioned above, there had also been some lit-up moments in the months before the crash which let us take action:

We hired two business consultants specialized in finding appropriate public funding programs and even talked to the muppets at our local chamber of commerce about this topic. I already mentioned that in Germany pure software projects are (publicly) unfundable, so this idea (luckily) went down like a lead balloon…
We met a wannabe VC guy and presented him our concept and further ideas. We couldn’t really convince him, and I must admit that he had a far more realistic view than we had at this time. On the other side, the level of funding he had to offer was so low that it wouldn’t have helped us anyway.
We found subtenants for half of our office space that had been unused for years. We also sold unnecessary equipment and furniture and canceled subscriptions of magazines no one ever read.
We fired a mini-jobber and canceled a contract with an offshoring service provider in India — both processed data for our “zero revenue lunch offer portal”. (Did I already mention that I hate to lay off employees?)
We tried to build a cooperation with two other companies in our neighborhood for offering local customers various media services. Luckily, this relationship never got far.
We regularly thought about, heatedly discussed and determined several ways to get the financial pressure down, thus making some money quickly to keep the wheels turning. When we finally ran out of time and money, we knew we had to re-enter the hamster wheel and go back to our “classic business”.

The last point is the most important one. You already know that we were not successful in terms of keeping teamspir.it alive, but at least it helped the company itself to survive. And not only that! It should take some time, but our decision out of necessity led us to a very interesting market niche with true revenue potential. If you bravely read the rest of this pamphlet, I’ll tell you which one…

Lesson
Not a real lesson this time, but yet a key character trait of successful entrepreneurs: Always keep your eyes open and look for opportunities in all kinds things, no matter how unappealing they may be at first glance.

In this context, you should read Spencer Johnson’s excellent business fable “Who Moved My Cheese” from time to time. Among other things, this story also covers our core failures mentioned so far as well as meaningful thinking approaches to avoid them.

#BackToTheRoots

This was a hashtag I used in my post on January 5, 2014 in our primary company Log at teamspir.it. It was the name of a brief working document I’d created the days before — about four months before the crash. It contained an outline of a concept how the final breakdown could be avoided as well as a kind of company manifest that answered the following questions:

What are our core competencies?
How do we (want to) work?
For whom do we (want to) work?
What is important to us?

Previously, we had often talked about these things, but never recorded or reflected the results. This led to countless repeated discussions and sometimes to real frustration, too.

At that time, our company was almost broke and we neither had the time nor appropriate ideas to develop new business models, so the natural choice was to offer some of our existing clients to relaunch their websites — this time based on WordPress to prevent unnecessary development efforts.

This was also in accordance with our new manifest that said that all of our work shall be based on the principles of efficiency (“never create things that already exist”) and sustainability (“always create things suitable for generating recurring revenues”).

As you’ve already read, the manifest came too late to save us from running out of cash. This means, it took too long for the respective actions to generate enough revenue. Unfortunately, it also came too late to save teamspir.it. Anyway, it was important as a kind of compass which gave us the direction to aim for.

Lesson
Talking about goals and principles is important, but not enough. As an entrepreneur or team leader, you have to regularly reflect them and write them down. The current results must always be accessible by all team members, even better, the team should be involved in the reflection process. Ha! That’s the main focus of teamspir.it again! ;-)

The “Success = Failure” Paradoxon

You are going to fall, but that doesn’t matter, what matters is how long you stay lying down.

It’s no secret that failure often is a crucial component of success. It’s an opportunity to learn, grow and improve. But let’s get a little bit more concrete with our initial question now: Can a failed startup be a success at the same time?

I’ve already answered this question with regard to teamspir.it: Yes! Of course, it’s the perspective that matters here, and this story is told from my personal perspective.

Sure, teamspir.it has failed in many ways as described above. Here’s why it’s truly valuable for me anyway:

The whole development process was an excellent practice for team play. (Unfortunately, I’m the opposite of a natural born team player.)
I found a very talented consultant, Casandra, with her unique “minimalist marketing” approach. From her, I learned a lot about efficient storytelling and content marketing. I hope that we’ll have the opportunity to work together in the future again!
I could use teamspir.it productive for recording our progress and learnings as soon as the required features had been implemented. This way, I was also able to replace my former document based company logbook.
Without the ability to review all of my teamspir.it log entries, I wouldn’t have been able to write this post at all: My memories of that time would have been a giant black hole of failure and misery. It’s very likely that I would have forgotten all the positive aspects this journey brought to me.
It’s not just an empty phrase: Reflecting my actions, achievements and failures made me learn very much. Believe me, during the last three years I learned more than in the previous 15 years I’ve been in this business. Learning also means growing. I grew as an entrepreneur, as an executive, as a teammate and as a person, too.
Maybe it’s only true for me, but especially long time reviews (e.g. looking back more than one year in my Logs) always give me an incomparable kind of “motivation boost”! I think this is mainly due to the fact that this way, I often realize that I’ve done and achieved much more than I thought I had in the reviewed period. These are the fruits for the sustained effort of writing a business/team Log, which can be really tough sometimes. (Of course, there are always more important things to do and most of the daily work stuff is “not interesting enough” to record… really?)

To put it in a nutshell, I know that it takes a special mindset and much discipline, but the concept of teamspir.it just works for me. It works exactly the way I’d predicted.

That’s why for me, it’s definitely a real success!

BTW: Even though the development has been paused, we will not shut down teamspir.it. I still use it almost every day. We even have some new signups now and then, but I suppose I’m the only currently active user… and that’s ok! ;-)

Epilog — A New Chance

May 2016: Two years have passed since “the crash” and — ouch! — one year since I started to write this essay. I’m very pleased (and surprised) that you are still reading, so you might ask yourself if or how we got out of all this trouble.

Well, to be honest, we still are in trouble, but our situation is far less critical than two years ago. Of course, I’m everything else than satisfied with this, but there are clear signs that we are on the right path to finally get out of the red — and beyond.

It’s been a long and hard way to get (at least) into our “normal operation mode” again, but let’s take one at a time…

Directly after our crash landing in the beginning of May 2014, our biggest problem, of course, was not being able to pay all of our current bills. We didn’t have a plan B for this case, which means private money was the only option to keep the company alive. (We are a joint partnership, not a corporation, hence filing for bankruptcy wouldn’t have helped us.) Fortunately, I had saved some money in our “good years”, so I could make a decent deposit and our creditors never had to worry.

Mistake
We never really talked about this unpleasant topic, therefor we neither had a plan how to react on critical liquidity problems, nor was it possible to reinvest money into the company or to adjust the partner withdrawals in a balanced way.

Lesson
This is another obvious one… Make a plan what to do when the money is gone before the money is gone! If it’s absolutely necessary that new equity has to be raised from the partners or investors, an evenly distribution of the financial burden should be contractually-guaranteed.

After the most urgent bills were paid, we were able to continue in “emergency mode”: According to our new manifest, we had already started to develop some WordPress based websites and shops for our existing customers. We also did various small web update and maintenance jobs (again). No task was too trivial or boring, as long as the money was right. In combination with our web hosting business and a radical cut down of our monthly withdrawals, this thin revenue stream allowed us to keep going month after month.

I promised you to tell you about a market niche we stumbled upon accidentally. For this, I have to go a little bit far afield first: We had developed a regional real estate portal and publishing system in the early 2000s. 14 years later, we still had about 10 real estate agencies in our customer base who used this really old platform. We thought it would be a good idea to offer them a tailor-made full package for replacing this platform as well as their old-school websites. It included a WordPress site with a top-notch real estate theme and a free software for entering and managing their property offers.

The package should also include another crucial component: A WordPress plugin for automatically importing the real estate data entered in the management software into the website based on the German data exchange standard OpenImmo.

I found a plugin that seemed to be an appropriate solution, although it was everything else than low-priced. At that time, I supposed that we would need several licenses of that plugin.

The developer offered me a discount, but only if I would purchase a minimum of five licenses at one go. In this case, this would have cost us several thousand Euros. We rejected this option, mainly because we couldn’t take the risk of not being able to resell all these licenses. In hindsight, this was a wise decision!

Some weeks passed and we had to realize that we had produced our next flop: Although we offered a professional solution for a reasonable price, we couldn’t attract our real estate customers with the new full package. (“Why change a 14 year old system if it still works… somehow?”) But then… one single customer ordered it!

I can’t say that we were very pleased about that, because now we had a “missing link scenario”: We couldn’t offer the envisaged import plugin anymore, because this would have busted our initial calculation.

So what now? The solution was apparent: I was a developer too and I already knew the OpenImmo standard quite well, so why not develop an own solution for this project that could also be sold to other realtors or web agencies afterwards?

Nothing is achieved until the first sale is made.

That’s exactly what I did, and this time… it worked! It started as a small side project and a tiny one product shop only, but with this little plugin, we achieved something within a few days and with zero marketing effort that seemed to be impossible to achieve with teamspir.it within a whole year: The first sale!

In the following weeks we registered more sales, not many, but enough to see that there is a market demand for this kind of specialized software. Since then, we’ve released several more plugins in the same market segment and sales steadily climbed (overall about 270 licenses in two years). There’s another positive side effect: A part of the plugin buyers is also interested in custom development services we can offer, too.

Please don’t get me wrong, the revenues of our new “real estate software/service business unit” (unfortunately) have not skyrocketed yet — remember that we move on a niche market, not a mass market. Moreover, it has it has cost me countless sleepless nights only to transform the prototype of our current “flagship plugin” into a real product ready for scalable sales. (Unlike the first release version of teamspir.it, the first plugin version was a true MVP.)

Funnily, in the last two years our plugin/service business showed almost exactly the growth dynamics that we had anticipated for teamspir.it — except for the viral effects that can’t appear here. All in all and although it’s not our long-term plan to stay on the WordPress road forever, we are sure that there still lies a great potential in this market. Hence and considering the depicted experiences, we’ll continue to build up this business as another “backbone” of the company. Who knows where this path will lead us?

Oh, by the way, we landed another great side project success: While we built teamspir.it, Peter developed a sophisticated tool we needed for creating documentations of RESTful APIs based on source code annotations. It saved us much time, because it made it easy to track the various changes in the teamspir.it API during development. apiDoc has been released as open source software and is now one of the most widely used solutions of its kind with thousands of downloads every month.

And that’s it, hope you liked the story! I’ve been battling myself for the last 12 months to get this damn essay finished. It’s my first longer post, so please kindly excuse its weird composition and the excessive amount of claptrap, repetitions and multi-clause sentences. Please also take into account that English is not my native language.

A big thank you goes to Casandra for proofreading and fixing my biggest mistakes!

Thanks for reading!

If you want to know more, please drop me a line: carsten@teamspir.it

Photo Credits — Thanks to:

Thunderstorm: Drew Hays/Unsplash
Crashed Plane: Annie Spratt/Unsplash
Open Road: Gian-Reto Tarnutzer/Unsplash