Life June 09, 2013

Lessons learned from a small tech startup

There are many possible pitfalls when starting a new company and building a product. These are the most important things that I learned from starting, running and selling a company founded by three developers.

Last week I spoke at the conference DevSum in Stockholm. The topic of my talk was the story of the company 200OK AB started by Marcus Granström, Henrik Lindström and myself and a number of lessons that I learned from that adventure.

In the talk I first told the company's story from start to end, or from idea to being acquired. I then covered a number of lessons learned. In this article I'll skip the details of the story but tell you about the lessons. I kindly ask the reader (that'd be you) to keep in mind that this is purely based on my experiences from one specific company, although I personally think that they may be applicable to many other situations as well.


200OK was a company with a product called Truffler. Truffler was a Software-as-a-Service solution for free text search and content retrieval. Somewhat simplified we offered preconfigured ElasticSearch indexes "in the cloud" along with licenses for our custom .NET API.

Beyond making it easy to build traditional free text search functionality the product helped developers leverage the significant power and speed of ElasticSearch for querying.  Using Truffler developers could very easily create functionality such as "the latest articles by a given author" or "number of products in a given category within a given price range" etc.

We started the company in 2011 and worked almost exclusively on our spare time. In 2012 we sold it to the Swedish CMS and e-commerce vendor EPiServer. The product is now marketed as EPiServer Find.

During the brief but intense life of our company I learned a lot of things. A lot of those technical, but the most valuable was non-technical. About running a company. About building and marketing a product. And about how sales work in the corporate domain.

Many of those lessons may seem obvious. However, there are many possible pitfalls when starting a company and building a product and it's hard to think of everything when you're in the thick of it.

This is a summary of the most important lessons that I learned.


It's important to focus on the things that add value to the company. For a startup without a product, or without a product that is yet so complete that it's possible to market it, that means to focus all efforts on developing the product.

I realize this may be stating the obvious but if you think about it there are a lot of things that you may think that you need, and therefor can be spending time on, when starting a new company besides developing your product.

Maybe you need to create a logotype and a web site. Maybe you need to pick and implement a good development process. While such things may be needed once you have a product, spending time on them before you actually need them prolongs your time-to-market.

Slower time-to-market may not seem like a problem for a company with no expenses or with enough capital to handle it. However, every day that you are developing your product without users is a day without feedback. Feedback from those that actually use the product in the wild. Each such day is a day that you spend guessing what the market needs.

In our case we managed to bring our product from idea to an initial marketable state in a couple of months. This was much thanks to the fact that we spent almost all of our time developing the product and either pushed peripheral problems to the side or found quick solutions to them.

Two such peripheral problems were related to design. While I'm an avid advocate of the need for great graphical design we didn't have much design skills between us. Also, while we needed some sort of graphical design for our logotype and website they weren't essential for our very technical product.

Instead of getting hung up on these problems or spending time trying to solve them ourselves we bought a logotype along with an idea for the product name from BrandCrowd. We also bought a simple, ready to use design for a Software-as-a-Service provider website.

In summary - focus on what you must have in order to reach your initial goals rather than what you think that you may need once you get there. 


A company founded by developers has great potential! You can build anything! You may also have many opinions and ideas about how to build your product. Often such ideas involve tools of some sort. In a company founded by developers the opportunity to pick the optimal tools can be a dangerous trap when it comes to focusing on the core product development.

It's not uncommon for developers to start a project by setting up a build server or discussing what Scrum/Kanban/Whatever dashboard to use. I'm not going to argue that investing in tools and processes that speed up development isn't worthwhile. I am however going to say that in the early days of a startup you need to consider all costs, especially when the cost is time that could be spent on developing the product.

I think this is especially important in a company founded by developers. Why? Well, first of all in such a company you have the ability to create whatever tools you need. Second, developers are often not in a position to choose their own tools or processes during their regular work, adding a significant allure to choosing the "perfect" tools in an own company.

In my experience discussing what dashboard you are going to use, setting up a build server before you have anything to build or discussing in length what development stack to use (often ending up choosing something you want to learn rather than something you already know), while fun, is a perfect recipe for not building a product that will reach the market.

I'm not saying that you shouldn't invest in continuous integration and delivery or find a process for managing the development. However, as developers it may be tempting to solve such problems prior to actually having them.

Make sure that you spend your limited time and resources wisely. To do that you should use tools with no or low thresholds.

For us that meant, amongst other things, managing the backlog and work items in a simple spreadsheets in Google Docs, building our website on ASP.NET (which we knew well) and hosting our website on AppHarbor.


Communication is important.

No shit, you wrote a blog post saying that!?

Well, it is. However, what I really learned was that regular communication is key. For us, working part time with the company we quickly found that it was hard to keep everyone on the same page as we often didn't work at the same locations or during the same time of the day.

To tackle this we decided to have weekly meetings on Skype. Every Sunday at 10 PM we all got together on Skype and went through our backlog, discussed important decisions and how to proceed with our product. These meetings were mandatory and there were no excuses for not attending.

We of course also talked to each other at other times using different mediums and in various constellations, but the sunday meetings was our "anchor" in terms of communication. Besides the benefit of having everyone involved in a conversation at least once per week having a fixed time for it meant that it was easy to get an understanding from everyone else in our lives that we needed to spend time talking about what was going on in the company.

So, while it's obvious that communication is important keep in mind that it's easy to take it for granted only to suffer from a lack of communication. A fixed schedule for meetings where everyone can attend is an easy solution to that.


You are a few devs who has gotten together to start a company and fulfill your dreams of building an awesome product. You're likely to have some heated arguments over technical details of course, but having freed yourselves from the regular corporate BS the last things on your minds is that you may have to deal with conflicts in the workplace. Right?

What we found was that in the beginning everything went fairly smooth between the three of us. There where disagreements but they always revolved around different ways of achieving the same goal - making the product awesome.

However, after a number of months the high paced development done, often during late nights or weekends, started to take its toll. Combine that with us, at the time, not having a single paying customer to validate that we were doing something right and some of the same types of conflicts that we'd experienced working as employees started to surface.

For us the conflicts revolved around two related things. One was frustration that the product development had stalled. The second was feelings of imbalance in terms of how much effort each individual put into the company and the product.

Luckily we, after while, faced the issues that we had head on and discussed them. Once we did that it quickly became clear that there was an obvious solution. We needed to manage expectations.

While we had all agreed to putting in a lot of time and effort during the early days we hadn't defined what that meant. Later, when we all started to tire and were faced with other things that needed attention in our lives, we found ourselves in a situation were we spent drastically different amount of our time on building the company.

So, having recognized the issue we found a simple solution. We decided that each of us should spend ten hours per week on things that added value to the company. Had we been working full time this number would probably have been forty instead.

Having defined how much effort we could expect from each other we got rid of many of the "unfairness" conflicts. This also brought another benefit as we could now more easily estimate the development pace, making it easier to plan and prioritize new features.

What I took away from this was that no matter what you're doing, if you are more than one people starting something, there is bound to be tough times and at those times conflicts will surface. It's hard to predict what those will be exactly, but some may be more or less obvious that they will happen unless they are prevented. In a company founded by a number of friends or associates I believe that the key to preventing many conflicts is to manage expectations regarding how much effort each person should put in to the company. It's also important to discuss what happens if someone doesn't come through on what you have agreed on, or does the opposite and works much harder.

Starting a company means doing business. Doing business means there are legal aspects to consider. That's especially true for a company that builds a product who's value lies in the intellectual property rights, such as software.

There are many legal aspects to consider, such as:

  • Regulating ownership of the company, or of the product if you have yet to start a company.
  • Intellectual property rights. For instance, if you work on the product(s) while still under employment you should verify that all your employers are OK with what you are doing. Also, bringing in a friend to write some code or do some other work may seem like a good idea but you should beware of what that means in terms of ownership of the code. Likewise, maybe you start out developing the product during a hackathon in a larger group and then only a few of you continue working on it. If so, you need to regulate the IP rights somehow.
  • Intellectual property rights and licenses for any third party software that you use.
  • General conditions/terms of use/end user license agreements for your product.

It's of course possible, and tempting, to start a company, build and sell a product without considering any of these things. However, once you start getting customers there will be questions regarding some of these things. Not to mention if your company tries to raise funding of is acquired. In other words, deal with the boring legal stuff early on.

While it's of course best to have the legal aspects taken care of by a kick ass legal team that costs money that you may not have. For many things however that's not *really* needed from the start. Agreeing to things and documenting things in plain English in e-mails gets you a long way. It gives you something to fall back on in case of conflicts and serves as a good starting point once you later on bring in lawyers that write things in legal-speak.

Sales and marketing

Having a great idea and a great team of developers is a great start when building a company. However, while it's tempting to believe that "A great product sells itself" that's not really true. First of all prospective buyers or partners need to know that the product exists. Second they need to recognize that they need it.

We introduced our product at a local user group in Stockholm. It took almost four months after that before we had our first paying customer. While we did a lot of other marketing activities after that, we later found out that this, the first customer, had found us thanks to that first presentation at the user group.

That is, if we hadn't spent time on showing off our product early on we never would have gotten that first, and for us very important, customer. Marketing is important.

That doesn't mean that you have to spend a lot of money on it. Talking at user groups, writing on Twitter, sending out press releases, being interviewed on podcasts, putting up vides on YouTube and drinking beers with people in the business doesn't have to cost you a dime.

However, if you don't do any of that, or spend a pile of cash on ads, no one will know that your product exists. If no one knows that your product exists no one will buy it.

Now, given that you do have a plan for how to market it, that doesn't necessarily mean that anyone will buy it anyway. Especially if you intend on selling it to other companies. You see, for anything but the cheapest off products most companies are used to being sold to.

That is, while you may know that your product is a no-brainer for the customer and you've priced it in such a way that they will obviously make money from buying it that's not enough. You need to convince the customer.

Doing that probably involves meetings, showing and handing over PowerPoint presentations, presenting feature comparisons with any competitors that you may have and discussing sales agreements back and forth.

So, you will likely have to spend quite a lot of time not only marketing your product but also on selling it. If you don't plan on going bankrupt thanks to selling your product you need to take those efforts into account when you set the price for your product.

Joel Spolsky wrote a great blog post about pricing software in 2004 titled Camels and Rubber Duckies. In that post he sums up our experiences pretty well:

"[...] big companies protect themselves so well against the risk of buying something expensive that they actually drive up the cost of the expensive stuff, from $1000 to $75000, which mostly goes towards the cost of jumping all the hurdles that they set up to insure that no purchase can possibly go wrong."

Besides including your costs for marketing and selling your product when setting its price you should also beware of the costs in terms of time and what that means for product development. For us, being a company made up of three developers we found that once our product started to get some traction on the market we weren't really developers anymore. We had become salesmen.

We spent so much time in meetings, creating presentations and other sales material and writing sales agreements that there simply wasn't much time left for any real development. While that may seem like a nice problem to have, we were making money after all; we weren't making enough money to hire someone to take care of the sales for us.

So, the next time I'm starting a product company together with a few developers I'm going to insist on also having a partner that is responsible for sales.


Building and designing your own product without any external agendas or constraints is something many developers dream of. True enough, starting 200OK and building a product together with two other great developers is one of the most fun things I've ever done.  However, we quickly found that the actual product development is only a small part of building a business.

To summarize, the key takeaways from our little startup adventure, and this article is:

  •  Focus on building and bringing your product to the market. Using a startup as a place to try out new things, at least in the early stage, is a great way of not building and not selling a product.
  •  Discuss and put in writing your expectations for the company and for each other. If your doing the development on the side from regular work, decide how much time you should spend on it per week.
  •  Don't take communication for granted. If you're building the company on your spare time or are not located together find a fixed interval for meetings that work for everyone.
  •  Have a plan for marketing and sales. If you're building a product that you plan on selling to companies and its price is above almost free make sure to include sales efforts in the price.

Most importantly of all - if you don't have a way to sell your product you won't have a business. So, if you're into doing startup hackathons or thinking about starting a company with a few devs, consider bringing someone that knows how to sell along as well.


Photo credits

PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.

Joel Abrahamsson

Joel Abrahamsson

I'm a passionate web developer and systems architect living in Stockholm, Sweden. I work as CTO for a large media site and enjoy developing with all technologies, especially .NET, Node.js, and ElasticSearch. Read more


comments powered by Disqus

More about Life