It’s been 7 years since the end of my first startup - a startup which failed. Looking back I wonder about the learnings - what would I tell myself, and what would I tell new founders?

When analysing a company you can come at it from different angles. There is the technical angle about how things are implemented; there is a product - what is it and what are the ideas behind it. And finally the startup learnings - all the rest - which is what I’m going to write about here. (Note, ‘the startup learnings’ is there a better term for the cultural, organisational, surounding stuff?)

Of course to any startup there is a personal side as well which I won’t cover, but this likely deserves a post of its own. After all you rarely do anything in a vacuum; I had a family at the time - and thankfully still do. I might write some follow-up post on any or all of the other subjects in the future, but since it’s been 7 years since closing Ráiteas, and this is the first post on the subject, you shouldn’t get your hopes up too high. I’m always open for a cup of coffee or speaking about it if you find it interesting.

To add a little context I’ll briefly touch on the what and the how, before actually digging into the learnings.

The Product

Ráiteas as a product could do physical data lineage as well as data model analysis on data warehouse type installations - think very large databases, 100s of schemas with 100s of tables and too many rows to count. This in very short form meant taking SQL in all forms and from that piecing together a massive graph used for data analysis. Of course this would be useless without some kind of interface which we built as well, enabling scrubbing through time and filtering on all parameters from user accesses to individual columns. To refresh my own mind I just had it back up running once more, and I’m still quite proud of the interface we built. Thanks to the Vagrant setup it was not as bad as you would think getting a nodejs 0.10 with Angular 1 up and running even after 7 years.

A typical workflow was loading a transaction log directly from a data warehouse containing a bunch of SQL statements and some other metadata. Hereafter an analyst would sit down and visually filter and inspect the emerging data model. Did the model look as expected? Were there unexpected data flows? Where did this column orinate from? To make this viable and useful you needed to import several 100 thousand individual SQL scripts or statements - which made efficiency an extremely critical part.

Ráiteas was meant to be a software-as-a-service type installation either on-premise or cloud based.

gif

The Technical

Ráiteas was fairly complicated with multiple moving parts. Below is a high level overview with some numbers from the code base.

Main Components:

  • A Java SQL parser/analyser taking raw SQL text while producing graph information objects serialized as protobuffer objects. Apache Storm, Guava and several other libraries and projects.
  • A C++11 service taking protobuffer objects and loading directly into a Postgresql database. Making heavy use of several Boost libraries.
  • A Queue for splitting the work between services.
  • A Database with 3 schemas, 30+ tables, 20+ views, 10+ functions.
  • A single page app using Angular 1 and Javascript. Included several enterprise features a.o. supporting multiple users, sharing datasets and analysis.
  • A nodejs rest’ish backend providing an interface for the app to the database. This was all low level filters, access control, paypal etc.
  • Virtual machines using Vagrant.
  • Remote object storage on AWS with S3.
  • A Python service for directly importing the Teradata DBC log files.

In total more than 4000+ lines of SQL, 4000+ lines of C++11 not counting header files, 8000+ lines of Java, 8000+ lines of Javascript/Angular app. Approximate line counts was done using cloc and without counting comments and blank lines. Add to this the countless pitch-decks, Google Docs, user guides, presentations and all the rest which is needed - my Google drive is bursting with documents and notes.

The Learnings

The following paragraphs are meant both as a reminder to myself (should I ever decide to start once again), but also as more generic advice which could be useful for future founders. This is part of what I would tell you if you came to me for advice. Funny thing with advice; some you can accept, some you can’t regardless of the truthfulness, and some you shouldn’t accept - even if the advice is sound. The real world is complicated.

The Name

I guess Ráiteas requires some explanation, turns out naming your startup is hard. We went with Ráiteas which is Irish for statement - we meant that as in SQL statement. We probably should have consulted with an Irish speaking person. One advice here is to keep it simple. Don’t try to be too clever - the amount of questions I’ve gotten on the name alone! On the plus side, it can be a conversation starter - but maybe having to explain the name alone for 30 seconds is an indication that something is not quite right. And maybe you want to spend the first 30 seconds talking about your actual product.

Advice - Don’t be too clever when naming things.

png

A Startup is Just Another Company

In case you are wondering, a startup really is just another company, nothing is really special about it! And I mean it, there is and has been a sort of filter with which people have been looking at startups. A filter which made startups look special, but it is just yet another company. As a company you need capital to start-up, some employees to work on whatever your product is … and eventually you need to sell that product to earn money.

A startup is special in that usually it will start out from scratch, no product, no customers, no brand, no nothing. This is what makes it special and exciting - you are part of or the founder of something new.

There are, as I see it, broadly two classes of startups. The ones making a profit, and the ones not making a profit. Where a startup diverts is that some startups don’t actually aim to be profitable, which is totally crazy if you think about it - the goal is more the perceived market value. Regardless, if your company has no income then what you are selling is an idea, and your bills need to be paid from the invested capital - which is why burn rate and runway are key terms. Thus, you end up spending a lot of time looking for investors and pitching your idea - this was a true burden for me in the second half of the journey. Once capital gets tight, you spend more and more energy fundraising. Time which could have been spent thinking about the product and improving it.

Bottom line, you either have income or burn rate - no magic involved, it all goes out of your balance sheet, venture capital or not.

Advice - a startup is just a another company.

About Investing Your Own Money

I was investing my own money in this project which made some decisions harder and some simpler. But even so you need a clear policy for getting out - akin to stop-loss when trading stocks. Please do take this seriously - even if it’s someone else’s money. At least while you are not making money, I would advice you to place several decision points or firewalls into your calendar. Each of these should be a condition or criteria to meet with a written argument of some substance. The argument should talk about why to stop if some criteria is not met, and possibly what alternatives you should or shouldn’t take. Put this into your calendar well in advance because your judgement will be clouded by the moment once it arrives.

Having external investors funding your company might force you to stop once in a while with board meetings etc. but my guess is this is still a big risk factor. Some board members have conflicts of interest, and some might have a unrealistic view. And ‘pivoting’ or something similar is just a bad excuse for continuing down the wrong path.

Oh yes, it did probably cost a couple of million DKK - I try not to think too hard about that part. I did land, with my family, on my feet, I’m still happily married and my two kids are wonderful. In the end it’s very hard to account for money spent, time spent and experiences gained.

Advice - have an exit strategy and put a stop-loss into your calendar with written arguments.

Personal

I learned quite a lot, personally as well as professionally; you are forced to deal with many things. Especially things which are out of your comfort zone, but that is also what I really like about startups - you can’t avoid getting involved. I did all these tasks and most likely more:

  • Hiring and firing real people. This is hard for a small company, and I’m not a robot.
  • Team leading and project management. Even if the team was small, it is a part of the job.
  • Presenting and selling your product. I’ve done countless product presentations, and we also went to the Summit to present our product.
  • Dealing with the ‘fog of war’ which is part of a startup, emotional ups and downs, hard decisions on strategy.
  • Defining a product and making a plan to develop it, specifying requirements.
  • Releasing a product to be used by someone else, once you have your POC you only just started.
  • Writing product briefs, selling, marketing. I always tell people ‘I’m not a salesman’, but really you are.
  • I wrote C++, Java, Python, javascript, bash. You name it, and I likely wrote it. And I quite enjoyed it.
  • I wrote SQL parsers, AST analysers; I even tapped into the code base of the Postgresql parser forking postgres-9.3rc1 (src/backend/tcop/postgres.c) in the process. Advice - don’t do it.
  • I implemented a graph data model with PostgreSQL. I really liked the database stuff and still do, great tool if you are not afraid to use it. And I’m not.

png

There was a lot more going on, privately being part of a startup adds its own pressure. Funding it personally takes this to another level, I was married with two children at the time - and luckily still am. But let me be honest here and say I will try hard not to repeat this, ever!

Still I had lots of fun, there were hard times, sad times, frustrating times. But I did learn a lot and got to try it. I certainly won’t have to think back and wonder if I should have followed that road…

Advice - be prepared to do all the things.

About Taking Advice

This is not really a dig at advisors, or that I believe all advisors to be bad or have dishonest intentions. This is about the reality being complicated, and as a founder you should do a thorough objective analysis of your situation and the relationships you have with your advisors. Preferably for each advisor, for each situation - this obviously is a bit much to ask. Look closely at whom you are talking to and getting advice from, ask yourself; are we still talking because it’s comfortable and nice and if so, is this still the best advice your can get?

Advisors come in all shapes and sizes, some are paid, some are friends, some are network, some are co-workers and some are paid professional advisors.

(In reality, its always going to be a ‘sliding scale’ where at some point some people are great, but later you likely should listen to other people. Just as your employees will be different, some are startup/greenfield types, others are all about production and operations. Each type will have their time and purpose.)

Adding a Recurring Review to Your Calendar

I stumbled across a podcast mentioning ‘road to gold’ which is focussed on sailors, but I believe we in the startup world can learn a lot from this programme. The main difference is that competitive sailors typically have a very clear overall goal - ‘gold at the next olympics’ - which makes creating a plan somewhat easier. Regardless the road to gold breaks the plan into periods more or less following the calendar, yearly, quarterly, monthly and weekly. All very straightforward, but keeping a clear goal and having a clear execution plan for the next time periods etc. is very valuable. More importantly though, alongside this plan, which is very ambitious in its goal, is a review process for every period enabling you to make adjustments or finetune the plan as you move along. This retrospective view on each period I believe is very important. Remember that the plan for each period should hold measurable goals which if not met of course affects the following periods. Thus you need to make adjustments as you go.

The past years I have had a recurring appointment in my calendar; to review my current situation looking back at just the past week. I try and keep it simple. For one I just do this for the past week - even if the program advises you to have a monthly, quarterly and yearly review. I look back and see if what I did actually helped me towards this week’s goals, what decisions were bad and need revising, or if I need to shift my focus. For me this is everything related to work and physical training.

One note here is that the review is not intended to be the usual status type meeting. You should be looking back and evaluating the past period in relation to the goals set for the period - looking for improvements and asking hard questions rather than moan about what did or didn’t get done and to what standard.

Advice - add recurring reviews to your calendar.

Marketing

Turns out marketing is quite hard, even harder than I would have thought. Everyone will talk about ‘the conversion funnel’, click-through rates and churn. But the reality is again more complicated. It’s not enough - usually - to just spam ads or have an agency doing cold calls. Both these methods ‘work’ to an extend, but this means you get a large quantity of leads where the quality often is quite low - and quality here is critical during the starting phase of a company. My best advice here is to be really careful and don’t just fall for the fairytale of ‘the funnel’. Equally you have to be careful as some of the metrics you get leads to optimisation efforts - which take away development time from actual product development. Here is definitely a balance to find which is not easy, and I’m not sure I have the solution.

Ráiteas was a B2B type product, and it should be fairly obvious that there is a big difference between B2C and B2B products and requirements. But both obey the same general principles, though. Your first leads or customers need to be great ambassadors of your product. As a B2B company I should probably have leaned towards doing more consulting in the beginning and then productizing a little further down the line. If it’s a B2C product, please consider if you really need to integrate all the ‘funnel’ stuff. You will save a lot of time and money not doing lead attribution. And there are likely better and simpler ways to track your success, especially once you consider if the numbers produced by your marketing attribution tools are actionable? Will it actually make you change your product or approach?

Advice - you can’t track your way to success.

The Learning Company

Maybe you’ll hire consultants to help you out, maybe you’ll outsource a feature or even a complete product feature to an external company. Maybe some of your advisors know something or have their own ideas - some of which likely will be great. But you have a company, you and your employees need to learn. This means some tasks are actually not best outsourced, even if it - in the short term - could be faster or more efficient. Long term, if you have a ‘core product’ or a ‘core service’ you need to learn how to do that. And this is not exclusive to software development or hardware development. Equally important is it when you talk about ideas, new products and new features - all has to be learned, and there probably isn’t an easy way.

Being a startup you should cherish how to build prototypes and test them without spending all available resources and too much time. This is after all almost the definition of a startup - new business, new ideas. I guess this also talks about the type of company you are or would like to be.

Advice - keep learning.

Balancing Short-term Gains Versus Long-term Solutions

Now, my startup was tech focused - only software - I was and am very comfortable with new tech. But you should be aware of the difference between ‘leading edge’ and ‘bleeding edge’. There is a point when you accept too much risk compared to the potential gains you think you’ll make.

The one installation I did which mattered got cut due to a novice mistake - something I couldn’t change unless I was on-site. And it was too easy for the customer to say no to further involvement. I was using virtual machines as an easy way to install Ráiteas at a customer site, but didn’t have a plan for maintaining this remote setup once deployed. The virtual machine worked fine, but got filled up with all the data it imported. It really was a quick-n-dirty way of doing a full installation. Too quick, it turned out.

Advice - balance risks vs potential gains