The $0 Subscription Startup Stack — Part 1 of 3

The $0 Subscription Startup Stack — Part 1 of 3: Build something and run it

I’ve been building a SaaS startup for a couple of years now, and one of the things I noticed after a few months of operation is that all those small subscriptions I had for various things needed for the operation of the startup really start to add up. We have enough revenue now that those subscriptions don’t matter so much, but there was a time when they were a burden, particularly since we were bootstrapping.

I got to thinking whether it would be possible to build a startup stack with $0 in monthly subscriptions, and after putting together a list of the various tools we’ve been using, and looking for replacements for some of them where you can avoid the monthly subscription, I figured that this would be quite doable.

In this series of three articles, I’ll cover the different areas most startups need some help with, and list tools and approaches all of which have no fixed cost per month. Most of these are completely free, at least up to some decent level of usage, although some of the alternatives I list are zero subscription in the sense that you pay no fixed monthly fee although you do pay a small fee per usage.

Some of the services you use early on have high switching costs. I’ll try to point out tools that are like this, and give my advice on cases where I feel it may be good to invest some money early on to get you on the appropriate tool from day one, rather than having to spend a lot of time switching later.

I’ve spent almost 11 years doing startups (and almost 10 years leading technical projects at Google), but my recent startup experience is primarily from building a SaaS startup, so I’ll be able to provide the most relevant advice on categories of tools used by such startups. Many of the same tools apply to any type of startup, and I’ll also try to cover a few specialized tools other types of startups need, e.g. e-commerce startups, but I’m not an authority on those.

This first article of three will focus on tools you need to build a product and run it. The second installment will focus on how to get your product in front of your users, and how to make sales. The third and final installment will talk about all the other things you need to run a successful business: Accounting, customer support, billing, legal, financing and more.

Let’s dive in, shall we?

Ideation and Validation

Startups typically start with an idea. In this section, we’ll explore some tools and approaches that can help develop your idea, validate it by getting it in front of potential users, and more.

I recommend pitching your idea to potential customers very early, and very often, to avoid building the wrong product or service. Even if you think you’re all for this idea and will do super early pitches to real decision makers at potential customers, take my advice: Whatever the earliest you would feel comfortable with pitching a customer would be, do it twice as early, and do it twice as often as you planned to before reading this paragraph. Here are some tools to help you.


Showing your potential customers a mockup of your product can be a great way to get early feedback. Having a rough design for your user interfaces ready will make it that much easier to explain your vision and get actionable feedback.

The cliché here is that your first mockup should be hand drawn on the back of a paper napkin is actually pretty close to how rough your early mockups should be before you start talking to customers.

Once you get a bit further, sketch-like mockup tools are all the rage. I use Balsamiq, which is a great tool, but it doesn’t have a free version except for a free trial. NinjaMock, which has been featured right here on for a while, uses a similar style of sketch-like mockups and they have a free plan; the only catch is that your projects on this plan are public.

A similar tool with a different type of free plan is Moqups. Their free plan lets you have just one project, with up to 300 objects.

Another type of mockup is what’s called a design prototype, and looks a lot closer to a finished product although with no functionality behind anything. A very popular tool for this is InVision, and they have a free plan that lets you work with a single design prototype.

I like Reddit, and I recently stumbled upon an interesting thread there on the subject of prototypes and mockups, that mentions a few other tools.

Remember, don’t just build your mockups and prototypes. Get feedback from your team or friends and colleagues in the same industry, iterate on your mockup, then go out there and get it in front of potential customers for more valuable feedback.

User Testing

Your first quite-a-few go-arounds of getting user feedback should be done completely manually and by interacting with real people directly.

The way we did this manually at my startup, CrankWheel, was first to pitch to potential customers, and then as our product started being closer to usable, to do hallway testing. Hallway testing is when you grab people from the hallway and ask them to try to achieve some goals with your product or service while you step out of the room, but maybe record their interactions to see what they get stuck on and why. How to do this could be the subject of a whole separate piece; if you’d be interested in a piece on that, email me to let me know.

Once you’re slightly further advanced, you’ll probably want to use some tools.

A very neat tool is Peek, which lets you get a 5-minute video of a person using your website or app (along with their comments while using it), for free. If I recall correctly there are some limits on how often you can do this, but it’s a very useful service nonetheless, that UserTesting (a very useful but pretty expensive service) uses as a teaser of their full set of paid services. If you can afford them, great, they seem to be a leader in this space, but most startups starting out can get by with hallway testing instead, as briefly described above.

Another great resource is UsabilityHub. They have a $0/month plan and as long as you invite your own testers, using their platform to run tests on that plan is completely free. Using testers from their network is a pretty reasonable $2.50 per test.

I’ll also sneak in Stuart Brent’s There is no free plan, but no subscription either — it’s pay per use. This could be an alternative to UserTesting but at a much lower price point.

Business Model Canvas

This is less of a way to validate your idea, and more a way to ensure that you’re thinking about the various different angles that might need validation. The Business Model Canvas is a very simple framework for putting a startup idea down on paper and understanding how it’s different, how it will make money, how you will get it in front of customers, and more.

You don’t really need a tool for this, there are lots of free templates you can download and fill in, but if you want a free and simple tool, you could try Canvanizer.

Validation from Investors

One good way to get often quite insightful feedback on your idea is to create a pitch deck and/or demo for it, and show it to some angel investors or VCs, and maybe apply for some accelerators. Even if you don’t get funded or accepted to an accelerator, you should most often get valuable feedback.

I would only recommend doing this if you are actually open to taking in outside funding, or joining an accelerator. You don’t want to burn any bridges you might want to cross in the future by making people feel like you wasted their time.

Product Development

This section focuses on tools you need to develop digital products. I realize not all startups are built around a digital product, but most have at least a website, which sort of qualifies.

It used to be you would need to pay lots of money for software libraries that you were going to use to build your product on. Those days are gone, with open source providing a free implementation for an incredibly wide range of things. Hooray! So what is left? Well, it turns out, quite a lot.

You may need to find and hire folks to work on developing your product. Maybe you’ve got this covered yourself, or through your co-founder(s) or close contacts that you can recruit, but maybe not.

You need a safe place to keep everything you’re developing, track versions, keep track of bugs, and so on.

You also need to manage your development project, get your product tested, and more.

Let’s start with a couple of tools to help you recruit talent, if you need it.


If you have local talent available and vetted by yourself or somebody you trust, that is often the very best way to start. Perhaps they are willing to work for some sweat equity, or even join up to become a co-founder.

If you’re not in a position to find the very best local talent, you may want to look online.

If you don’t have much time to spend and are willing to pay for the value you get, I would recommend Toptal. They have programmers, designers, and even finance professionals who can help you, and they hire only the top 3% of everybody who interviews with them, and they expect and enforce a high level of quality. There’s a no risk trial period so if you’re not happy with the person they find for you, you don’t have to pay.

If you have more time and are able to take a chance on trying a few people before you find the right fit, then check out Upwork. I’ve been able to find some good talent there at a good rate, but be advised that you may need to work with a few people before finding a strong talent and a good match in terms of ease of working with that person.

Obviously, neither Upwork nor Toptal are free, but both of them qualify for this article as there is no fixed subscription fee — rather, they are collecting a part of what you pay to the talent you hire through the platform.

Project Management

Developing your product is a project that can sometimes get really complicated, with lots of moving parts and many people involved.

My favorite tool for the cat-herding involved in project management is Asana. It’s like a perfect to-do list that you can categorize, tag, prioritize, and the best part is that it does collaboration really well. Asana has a very generous free plan for up to 15 users in a team.

Taking a slightly different approach to project management, a lot of people really love Trello. Instead of being based on the concept of a to-do list, the base concept feels more like boards on your wall with sticky notes where you can move sticky notes between boards. If you’re doing something like Kanban (we actually do this in my team but we use a real wall and sticky notes…), then it’s a pretty perfect match. Like Asana, they have a very generous free plan with an unlimited number of users and boards, but lacking some features you may end up deciding to pay for.

Code Hosting

You need your code in a safe place, off-premises, and you need to be able to go back to any older version of your code. Choosing a cloud service built around a revision control system is the best way to achieve this, and these days the only revision control system I’d recommend you use is Git.

Bitbucket by Atlassian fits the bill. It’s built around Git and it is free for teams of up to 5 developers. I haven’t used it personally but Atlassian is a solid company that’s not going anywhere, and I’ve heard people speak well of Bitbucket. That said…

Your source code repository is one case of a system that has very high switching costs, so I would choose carefully here. My company uses GitHuband we’re very happy with it; if you’re doing open source it’s kind of the industry standard (and it’s free if you only work with open source projects, no proprietary code). If you’re incorporating open source projects hosted on GitHub into your product, it makes it pretty easy to work with those.

Any feedback on Bitbucket vs. GitHub from folks who have used both? I’d love to get your comments.

Issue Tracking

I mentioned issue tracking in relation to GitHub above, so let’s tackle that next.

You need a place to write down problems that are found in your product, to assign them to people, track whether they’re new, fixed, have been verified as fixed, reopened, etc.

One way to do this for free is to track your issues in your project management tool, e.g. Asana or Trello, both of which I mentioned above. They’re not specialized for this, but can do the job.

Both Bitbucket and GitHub have simple issue trackers integrated. This is probably the way to go to begin with, for most startups.

Switching cost caveat: If you have a fairly large and complex product, you may be better served by going with a more feature-rich issue tracker right off the bat. There are full-featured open source issue trackers available such as MantisBTRedmine and the venerable Bugzilla, and if you host them yourself, there is no subscription fee, although I’d recommend using a hosted version for peace of mind and simplicity. There are also products such as FogBugz which some people swear by.

Quality Assurance / Testing

The basics of quality assurance aren’t that complicated, even though the work is challenging, especially to find the most elusive bugs. For much of what you need to start, you don’t need any tools aside from your issue tracker and a documentation tool such as Google Docs:

  1. For as much of your functionality as economically feasible, create automated tests to cover this functionality. This helps a great deal to avoid bugs creeping in later, and is a key component of Continuous Integration, which I highly recommend. I say “as much as economically feasible” because for a startup in the early stages, you may be better off spending more time on manual testing and less time on automation, until your product is a bit more mature. Early stage products tend to change a great deal, which gives you less time over which to amortize the setup costs of the automated tests, whereas manual testing has close to zero setup cost, with the downside that the per-test cost is high.
  2. Have a written description for how to test your product, i.e. steps to take to run through all the basic test cases that will cover most of what your product does. Google Docs or any other documentation system is good enough for this.
  3. Create a test matrix of the different platforms your testing should be performed on. Depending on your product this may be a set of browsers and different versions of their browsers, or it could be a set of operating systems and different versions of those. In your test matrix you can specify which
  4. When your product is tested, it should be done based on the written test description, as well as exploratory testing outside of what’s in the written description to try to find new defects in corner cases. For any new or changed features, you should also ask for hints from your developers on what they think might break or need a particular emphasis in testing.
  5. Any time you find an issue, register it in your issue tracking system and decide how to prioritize it, when to tackle it, etc. Your issue tracking system can help with this, for example you can break your releases down to milestones (for example once every 2–3 weeks) and determine which bugs to fix immediately and which bugs it may be OK to defer a little bit. This depends on their severity and how many users they may impact.
  6. Any time you find an issue that you would not have detected using your written test description, take a step to make sure this or similar issues do not come back in the future. Add an automated test that would have caught the problem, or add a test case to your manual test description that would have made the problem obvious in routine testing.

Your initial testing can be done by you and your core team, but I would recommend having a separate person doing quality assurance pretty soon after the ball gets rolling. For one, it’s a somewhat specialized role and folks with experience in it will find more bugs than those without, and for another, you and your development team will become blind to defects in the product, and will do less creative exploratory testing. As for development, I would recommend Toptal if you want to be sure you get a great team member without having to try several times, and if you’re more budget conscious and have more time, you should be able to find somebody on Upwork, but you do need to be willing to take that time and may end up spending a fair bit of money to try a few freelancers before you settle on somebody for the long term.

One key tool that I always recommend for quality assurance of web-based applications is BrowserStack. It lets you run literally hundreds of different browsers on both desktop and mobile platforms right in the comfort of your browser. They used to have some of their features free, but no more (unless you have an open source project) — so I looked around for some alternatives for the $0 Subscription Startup Stack.

One alternative is Browsershots, which is completely free and supports a range of browsers. It doesn’t provide live testing though, only screenshots of your site across multiple different browsers and versions (this is the same service BrowserStack used to have for free).

Another that is now part of my toolchest is the Blisk browser, available for Windows and macOS, which does emulation of multiple devices so that you can view your site for quality assurance, and in fact for development as well. Their free version includes some of the devices they support, and you can upgrade to get more.


Now that you’ve built a product, what about running it? Most digital products need to be hosted somewhere online. Many require functionality such as email, SMS, telephony, and more, that you’re better off buying from a Platform as a Service rather than building and running those functions yourself. Finally, you will need to understand how your users use your products in order to be able to improve it, and for that you need product analytics. Let’s explore each of these areas in turn.


There are several levels of hosting you could go for. The simplest and least expensive level is when you have a simple static page. The next level after that is when you need your own dynamic back-end but can make do with something like WordPress, in which case you need a shared web host. Finally, if you are running a complicated digital product, you will likely want your own custom backend that you might host in multiple geographic locations. In all cases, you may want to use a CDN in front of your site to speed it up and decrease load on your servers.

Static site hosting

My recommendation: If you can build your site as a static site, you should do so. Especially if you’ve got some coding skills. You can do this even with fairly complicated sites that accept user submissions, might have a blog, and more.

For static hosting, I would recommend Netlify, which is simple to use and has a generous free plan. This is what I use for, which is a static site even though we have various forms you can submit (more on how to do that in the next installment in this series). You can either simply drop a folder on your Netlify deployment in order to upload that folder as a new version of your site, or you can integrate Netlify with GitHub to continuously publish any branch of any repository as soon as you push to that branch.

Another good alternative is GitHub Pages which is built into GitHub, so if you’re already using that it may be a very convenient alternative. I use this for the CrankWheel marketing site and it works really well.

There are many free and easy static site builders that you can use to make a static site feel more like WordPress. For example, when I write a blog article for CrankWheel, I’m basically just writing a Markdown file; no HTML or CSS. The static site builder that I’ve used and can recommend is Jekyll, which takes a set of source and configuration files and builds the static files that get served up for your site.

For non-developers out there, you can still use static sites. Ask your web developer to set up the initial site using e.g. Jekyll, and then use a tool like CloudCannon so that you have a visual, web-based editor for creating and editing blog posts and such.

Shared Hosting

Many companies offer shared hosting of WordPress and such. I need to do my research on this before creating a full comparison review, but Bluehostcomes highly recommended by many folks I’ve spoken to. While it’s not free, you can sign up for as little as $3.95 per month using this link, and you get more than $150 in advertising value with Google AdWords, Bing and other leading advertisers, which is more than you’ll pay for the first 36 months.

Cloud Hosting

For the most complex needs, you’ll want a cloud hosting provider. There are times when you might want to set up a virtual private server (VPS) rather than do cloud hosting, but in my opinion for almost any reasonably complex product, the ability to grow without switching providers is going to be very important, so I’d recommend going with cloud hosting.

I’ve primarily used Amazon Web Services (AWS), and I’ve had a very good experience with it. I’ve also heard good things about Microsoft Azure (it’s not just Windows — you can run Linux on it too). The most important criteria for a provider to me would be that I have to trust that they will stay in business and won’t cancel any of the platform services that I’m relying on, and both of these companies qualify.

Neither of those are free for serious usage, although both offer a free tier to get you started. However, as a startup you can apply for significant credits with both of them. With Amazon’s startup program, you can get up to $15,000 in credits that are valid for 2 years (even more in some cases), and with Microsoft’s BizSpark program you get up to $150 of cloud services per month for free (along with many other benefits), and up to $12,000 if you qualify for BizSpark Plus.

Content Delivery Networks (CDNs)

A CDN is a great way to reduce the load on your servers, and in some cases can also provide redundancy and protection in case of a distributed denial of service attack (DDoS). If you haven’t already heard of CloudFlare, then you should check them out. Just head over to their site and click Signup, and you’ll be able to add a site for free. Their free plan is quite generous and includes a basic SSL certificate for your site, caching, and various other goodies that can speed up your site. They take over as the nameserver for your DNS. Setup is really easy. I use this for multiple sites.

Platforms as a Service (PaaS)

Transactional Email

Transactional emails are those emails your system may send on account creation, password reset, confirmation of orders, shipping updates — the emails your customers definitely want to receive independent of their preference in terms of marketing email.

Don’t set up your own mail servers to send transactional email (and definitely not marketing email — but that’s for our next installment).

Use a service like Amazon SES (Simple Email Service) for sending email. They have a free tier for up to 62,000 messages per month, and pricing after that is not expensive — $0.10 per 1000 messages. I use this for CrankWheel and it’s rock solid, although it doesn’t have all the bells and whistles of Mandrill (now part of MailChimp), Mailjet (free for up to 6,000 messages a month) or Mailgun (free for up to 10,000 messages a month).

A key issue with transactional email is deliverability, a.k.a. not getting your email marked as spam. Once you’ve got your basic setup for transactional email, use the free tool MailTester to get hints on how to optimize for deliverability.

Non-Internet Communications

Do you remember life before the Internet? There used to be these things called telephones, which people would use to talk to each other, and a bit later there was this thing we now call a feature phone where you could send short text messages (SMS), it was like Facebook Messenger only without the GIFs.

It turns out, for many products, the ability to integrate with the telephone network or to send text messages can be extremely useful and effective. We use this at my startup to enable sending text message links to screen sharing sessions, and it’s great because it works on all phones.

The platform I recommend for both telephony and text messaging is Twilio. It’s been around for a while, and I’ve personally witnessed text message deliverability improve quarter over quarter for the last couple of years.

Logs Analysis

If you’ve ever run a webserver or a custom server, you’ll know how useful it can be to view server log files to diagnose problems.

There is a really useful class of services out there that allows you store logs from all of your different servers and machines in one centralized place, visualize them, query them, and create alarms based on them. I very much recommend setting this up if you have a complex product.

The solution I’ve used is Loggly. It’s a solid product, and it has a free tier that will be suitable for many startups.

There are significant switching costs for a product like this. I sometimes wish I’d gone for a metered product like LogDNA, which is priced per usage, rather than going with a plan-based product like Loggly, where I’ve had many months where we were on a plan that was significantly too large for us. I haven’t tried them, but they promise lower rates than Loggly, and much faster queries, which is an area where Loggly doesn’t exactly shine.

Usage Analytics

If you have a complex product, read this section. If you just have a static site or a WordPress site, wait until the next installment in this series, where I’ll talk about marketing analytics — that’s all you typically need for a website.

Usage analytics are important so that you can see where your users are having trouble, compare retention rates between versions, and more.

Many of you have probably heard of Mixpanel, which was the pioneer in the space of usage analytics, finally making it easy for small startups to track user churn, behavior funnels and more. They have a solid free offering.

The alternative that I recommend is Amplitude. They were first to offer a generous free plan, and although their free plan today allows fewer events than Mixpanel’s free plan, I can vouch that the free version of Amplitude is very powerful and lets you visualize and analyze a ton of stuff regarding how your users are behaving.


We’ve covered ideation and validation, product development, and operations in this installment of The $0 Subscription Startup Stack.

The next installment will cover sales and marketing — how to get your product in front of your prospective users, and how to make revenues from them.

The third and final installment will cover other stuff you need to build and run a startup — customer support, billing, legal, funding and more.

I hope you’ve enjoyed this installment. I’d love to hear your feedback, just email me.

Want to receive content like this, along with weekly useful tools for startups, straight to your inbox? Sign up at

Originally published at on November 19, 2015.

Speech for Startup Reykjavik 2015 Mentors

From left: Salóme Guðmundsdóttir, CEO of Klak Innovit, myself, and Svava Björk Ólafsdóttir
From left: Salóme Guðmundsdóttir, CEO of Klak Innovit, myself, and Svava Björk Ólafsdóttir

For the last three summers, I’ve participated as a mentor in the Startup Reykjavik accelerator programme. Today, I was honoured to be voted by the 2014 alumni as “mentor of the year” for last summer’s programme.

I was asked to give a short speech for the occasion, for the mentors who are participating in the Startup Iceland accelerator this summer. I gave the speech in Icelandic, and it is available in its original form here. What follows is an English translation:

Hi everyone,

I’d like to say a few words about what it is like to be a mentor, and in particular about being a mentor in the Startup Reykjavik accelerator, which I’ve participated in from the start.

I know many of you are experienced mentors, from Startup Reykjavik or elsewhere. For those of you who are getting started, it might make sense to talk a bit about what it is like in practice to be a mentor for Startup Reykjavik.

Usually, the way it has worked, is that at the beginning of summer, you let the organizers, Klak Innovit, know what dates you are available, and they will book mentor meetings with most or all of the ten teams participating in Startup Reykjavik.

You then meet each team individually, get a short presentation, and try your best to give them some useful feedback based on this first encounter. You follow this up by deciding which teams you think you could and would like to help, and this often ends up not being more than one or two teams per mentor. Of course, it can take several meetings before the mentor-mentee relationship clicks with one or more teams.

After this initial process, your communication is more directly with the teams you are taking under your wing, to organize meetings or use other communication tools. But at the start, it’s great if you can meet as many teams as possible, to be able to make the best selection.

Often, you can help a team in a quick way, for example by making connections for them within your network, even if you don’t intend to take the team on as a mentor. This is another reason to try to meet all the teams, or as many as possible, at the start, even if you don’t expect to be able to be an effective mentor for particular teams.

In addition to the organized meetings, Startup Reykjavik has several open events such as barbecues where you can meet and chat in an informal setting. These events are tremendously useful as a venue for helping a few teams outside the ones you are mentoring in an informal way, and to get to know the teams well enough to pick one or two to mentor. I strongly recommend that mentors show up for these events. Apart from being very useful, they are a lot of fun.

In fact, I think more opportunities for informal meet-ups between the teams and the mentors would be great.[1] Some of these could be more low-key than the barbecues, for instance just an afternoon to grab coffee at the Startup Iceland offices. The informal events are one of the best ways to create personal relationships that can last much, much longer than the 10 weeks the accelerator is ongoing.

Once you have established a mentor-mentee relationship, I’m pretty sure that it’s largely a question of personal style which modes of communication are suitable. All of the classical modes are available, such as meeting in person, using the phone, email etc. I’m willing to bet $10 that some team this year will use Slack to communicate with their mentor. Any takers on that bet?

For my part, I’ve found it most useful to engage in real-time communications with my mentees, either in person or over the phone or via Skype. While email and instant messaging can be great for follow-up or for classical management, being a mentor is not being a manager. It is much more about reading between the lines, seeing how your mentee is feeling, and hearing from the tone of their voice what it is that really worries them or that they’re unsure about.

This brings us perhaps to what it is fundamentally to be a mentor to a mentee. Is it like the relationship between a teacher and a student? I don’t think so, because a teacher usually has significant control over the path the student must take.

In my opinion, a fundamental tenet is that as a mentor, you must let your mentee take their own decisions, choose their own path, and shoulder all of the responsibility for their choices. When mentoring an entrepreneur, you must let the entrepreneur be the entrepreneur and remain firmly in the driver’s seat; the mentor should never assume that role.

I think a mentor should also expand the mentee’s horizons both outwards and inwards. Outwards, by pointing out other paths that could be taken, and possibly recommending one path above others, even though your mentee should always make the final call. Inwards, by helping the mentee recognize their own weaknesses or unscrutinized basic assumptions that might be hurting their decision making or prioritization.

First and foremost though, a mentor is someone who shares their experience in a meaningful way. Experience that could have come about from making their own mistakes, or possibly from being challenged by a mentor in their past. Any kind of experience counts, as long as it has bearing on what your mentee is doing or going through.

This is why it’s best to find an individual or a team that is working on something that you truly have insight into, something where you have meaningful experience you can bring to bear. Relevant experience and a strong desire to help the person or team in question is what makes us great mentors.

Let me end with a thought for all the mentors here. It’s a well known fact that investors, unfortunately, have a strong bias to invest in teams composed of entrepreneurs that remind them of themselves. This has meant that for example in the US, teams composed of white males from privileged families who studied at Ivy League schools, have had a much easier time getting funded than other teams.

Can we all join together to not let the same thing happen when we choose teams to mentor? Everybody, or at least most people, has unconscious biases that they’re often not even aware of. To reduce the impact of these unconscious biases, we can be mindful of how and why we are making our decisions, and try to consciously nudge them in a direction that hopefully reduces the impact of our biases.

I therefore encourage all mentors to pay special attention to teams composed of individuals who are different from themselves. That way, I think we will all learn more.

Thank you.

[1] The organizers of Startup Reykjavik have since informed me that there will in fact be quite many informal events, almost one per week. Yay!

Why CrankWheel, and why Iceland?

cropped-island_startupiceland111The following blog was first published on the Startup Iceland blog on May 11 2015.

About a year ago, I left a fantastic job at Google to fulfil my long standing desire to start my own company. I took a couple of months off, then started working on the startup idea I had when I left Google, only to discover that I was not passionate enough about building that particular business. I won’t describe it in detail in this blog post; suffice it to say that it was related to software localization, an area I worked on quite a bit at Google.

What followed were a couple of months of gut-wrenching self-doubt. This blog post is about those months, how I found and fell in love with the idea that became CrankWheel, and why my co-founder Þorgils and I chose to start in Iceland.

The metaphorical winter of my discontent was actually late last summer, when the sun in Iceland had started dipping below the horizon for a few hours every night. Þorgils and I had attended elementary school in Akureyri together, back in the days when Iceland had just one television channel which broadcast only 6 days a week, 11 months a year. We had become reacquainted a few months earlier, and were spending quite a lot of time together socially that summer.

On one of these long late summer nights, taking in the view from Þorgils’ house of Reykjavík’s city lights, we got to talking about what was missing in his line of business, which was advising and selling to clients over the phone. He described the typical process of selling financial products such as term life insurance: The sales agent calls the customer, tries to get them interested in buying, and if there is interest, they book a meeting in person the following day. A huge portion of such meetings gets cancelled or rescheduled ad infinitum. In the meeting, you bring presentation materials that will let you close the sale.

Why not finish the sale over the phone, I asked? The product being sold is too complicated to explain just by talking. You need to show charts and figures, to point to things and explain. At first, I thought people could use online conferencing systems to achieve this, but after we talked some more and did some online research, our conclusion was that all of the existing systems are way too complicated to ask your customer to use within a phone call; in most cases you would need to spend several minutes helping them set up such a system, and in all cases there would be a high likelihood that they would have problems joining the meeting because of outdated software, lack of technical skills, or a poor Internet connection.

This is how the idea for CrankWheel was born, as we brainstormed well into the night. I wrote down this one-liner as an early dawn approached: “For telephone sales and call centers, to add a visual element.” The idea really resonated with me, because I had vivid memories from the years I spent living in Canada, of attempting to stay focused while a customer service agent I had called to change my mobile phone subscription spent minutes reciting the details of my current plan, then the details of the plan I was switching to, and then repeated all of the details again after I confirmed that I wanted to switch. How much easier it would have been, I thought, if they could have just shown me?

The other reason I fell in love with CrankWheel is that it lets me leverage technology I care deeply about, namely WebRTC. This technology is built into the Chrome and Firefox browsers, as well as hopefully soon a few more of the major browsers, and can also be used in stand-alone applications. It makes it possible to create web applications that make use of real-time communications, i.e. real-time audio and video streams. Think of it like this: If Skype were starting today, it could be done as a web application, using just JavaScript, no download required. I care about WebRTC not only because it’s super cool technology which has the potential to be as disruptive to what you can create on top of the web as AJAX was back in the day, but also because WebRTC was the last project I worked on at Google, so I feel a bit of ownership in it, and I know a lot of the very cool people working on it.

I believe CrankWheel is 10x better than anything else out there today, because we are laser focused on one particular use-case, and on making it work every time with no hassle: You have a customer on the phone. You need to show them something. CrankWheel makes that happen in 10 seconds or less, regardless of whether the user has a computer, a tablet, or a smartphone, regardless of how outdated their browser is, regardless of whether the customer is a computer wizard or computer illiterate, and regardless of whether they are connecting over fiber optic cable or a 2G mobile connection. They never need to download anything, or do anything more complicated than point and click. The service agent is never in doubt that the customer is seeing exactly what they want them to see. We believe the whole thing has to “just work”, not just 99 times out of a hundred, but better than 999 times out of 1000, and we’re confident that our solution achieves this goal.

That brings us to the other subject of this blog post: Why we started CrankWheel in Iceland. It’s a fair question and the answer is not obvious. I have a significant network in both Montréal (in Québec, Canada) and in California’s Silicon Valley, both of which are great places to start technology companies, and it would have been financially feasible to move to either place and start there.

First off, there is the obvious inertia of moving away from family and friends. Both Þorgils and I have kids, and the kids’ school and friends and lives are here. But even if this had not been the case, I think it’s very likely we would still have started here.

It’s very easy for us to get started in Iceland. We both have strong networks here, and there are several Icelandic companies that have been extremely willing to act as beta customers and to run structured trials of our solution so that they can give us measurable testimonials, e.g., how much sales improved, how much customer service phone calls were shortened, how customer satisfaction improved, and so forth. Although the Icelandic market is not going to be a significant focus going forward, it’s great to have friendly and willing world-class companies almost literally next door that are happy to let us learn from their use of the first versions of our product, before we enter our growth phase and start focusing almost all our efforts on larger markets.

Starting in one of the world’s technology hot-spots can be very expensive compared to Iceland. Just look at the cost of living in Silicon Valley, or London, or New York, and it’s obvious. In the past 5-6 years, the typical size of a Seed investment round in the US has more than doubled and is now in the 1.5 million USD ballpark, and in Silicon Valley, that kind of money typically only lasts a startup 12-18 months, and that’s assuming a very small team. In Iceland, investors’ money will last considerably longer, and the time needed to reach break-even is shorter, since you will need less revenues to cover the expenses of a given size of team.

Finally, the talent pool in Iceland is really good. It’s small, but in my opinion the average quality of the people you need to build a product, e.g., programmers, designers and such, is very high compared to what I’ve experienced abroad. At some point I hope CrankWheel will have grown enough that it will start to become difficult for us to hire people with the right skill set in Iceland, but until then, this is a great place to grow our team.

There can be disadvantages to starting in Iceland, or any place that is small and far away from your future market area, but the magnitude of these disadvantages will depend quite a bit on the business model you choose. CrankWheel is a Software-as-a-Service (SaaS) solution, meaning it is a hosted solution and the kind of deep integrations and long sales cycles that are typical for enterprise software solutions are unnecessary. For a globally focused enterprise software company, starting in Iceland could be a significant disadvantage since most of your customers are far away, and you have a considerable need to visit them in person. For a SaaS company, there is much less need to meet in person, which reduces this disadvantage considerably. For our company in particular, that likes to use its own product to further reduce the need for meeting in person, this disadvantage becomes even smaller.

I hope I’ve given some insight into why I fell in love with CrankWheel, and why I’m excited to build CrankWheel in Iceland. I’m happy to continue the conversation on Twitter at either @joisig or @CrankWheel, or on CrankWheel’s Facebook page.

Shameless plug: CrankWheel is hiring! Check our Facebook page for links to listings.

I’d like to end by giving a shout-out to Bala. Thank you Bala, for the opportunity to guest blog, and thanks for everything you’ve done for the Icelandic startup community! I look forward to attending the Startup Iceland conference in just a couple of weeks, and I encourage everyone connected to the Icelandic startup scene to attend – it’s the premier event for our community.


The above was first published on the Startup Iceland blog on May 11 2015.

Introducing CrankWheel

This part of your bike is called a crankwheel. Without it, your bike would suck.
This part of your bike is called a crankwheel. Without it, your bike would suck.

I’m finally ready to blog about my startup, that I’m now working on full-time after developing it since last fall with my co-founder Þorgils (I’m the technologist, he’s the sales wizard). Our tagline is “CrankWheel: Power your Sales and Service,” we’re on Facebook and Twitter and you can sign up at to get news (and a special offer) when we launch, which should be this summer.

In a nutshell, CrankWheel allows a customer service agent, a sales person, or anybody else who might have a customer or colleague on the phone, to enhance the phone call with the ability to communicate visually, as if you were sitting side by side in front of a computer screen, in ten seconds flat.

Why didn’t I blog about CrankWheel sooner? The truth is, I’ve been through the typical Valley of Doubt with this project.

It’s a trail that starts in the hills of “This is the Best Idea Ever,” meanders down to an outcrop called “Oh look, there’s competition doing something slightly similar but nowhere near as good” and further down to the still-happy foothills of “This will be hard but worth it.”

After an enjoyable start, the trail keeps descending into the Valley of Doubt, and just as it starts to rain, you hit the dense forest of “Ouch, we just found a lot more competition.” As a thunderstorm of the soul sets in, you end up at the bottom of the valley in the marsh of “I’ve just wasted months of my life with nothing to show for it!”

Luckily, in my case, I made it through to the green pasture of “Every customer we speak to wants our solution” just as the weather started to improve, up the knoll of “I’m sure there’s a better way” and after that, step by step up out of the valley until I’m now standing on a plateau called “Time to commit very publicly.” Hence this blog post.

Now that I’m on the other side of the Valley, I’m strongly convinced that we’ve figured out a much better way to solve the problem at hand than anything that’s out there today.

I made it through to the other side thanks to questions such as these:

  • Why would you ever force your customer to install software or an app on their computing device, just so you can show them something?
  • Why should you ever live in doubt about whether your customer is seeing exactly what you think you’re showing them?
  • Why should it take more than a couple of steps, ten seconds at most, to see something being shown to you? Why should you have to remember and type in ten-digit conference room codes?
  • Why should you be forced to care about what kind of network connection you’re using, or what browser version you have, or whether you’re using a tablet or a smartphone or a desktop computer, when what’s happening is something so simple to do in real life? Just to be shown something?

Those questions gave rise to CrankWheel. In ten seconds or less, your customer will see exactly what you want them to see, no need to worry about what kind of device or which browser they have, no need to install software on their end, and it’s extremely easy to join a presentation. It just works, every time.

I think CrankWheel will make the world a better place through happier customers, a more personal touch, and less need to burn gasoline while driving to places to receive the kind of service that can’t be delivered over the phone alone.

To give a hint about CrankWheel’s “secret sauce,” I’ll mention that the last project I worked on at Google was WebRTC. It’s great technology that makes an excellent foundation for a product such as CrankWheel, but it’s also very new technology, supported by only a handful of browsers, which on the face of things conflicts with some of CrankWheel’s main goals. I’ll leave it at that for now – more later.

Right now, Þorgils and I are finalising the lineup of our first several customers, one in each of a few different industries, all of them willing to run scientific trials with us to see how much CrankWheel increases sales, shortens support calls, increases customer satisfaction, etc.

We are also ready to hire employee number one, based in our Reykjavík office. The ideal candidate is a rockstar programmer interested in web technologies and real-time communications. Don’t hesitate to get in touch with me if you are one or you know one. I promise, this will be fun!

I really look forward to being able to show and tell you more about CrankWheel in the coming months, both here and on the yet-to-launch CrankWheel blog, as well as by email if you sign up at

In the meantime, I’ll keep pedalling.

Why I left Google

Make like a tree and leave

When I decided to leave Google a few months ago, I was asked all the questions you might reasonably expect people to ask. “Isn’t it a fantastic place to work? Couldn’t you just switch projects to something really exciting like self-driving cars? Don’t they pay really well? Are you sure you still know how to fend for yourself after all of the free food? I’d cut off a leg if it meant getting a job at Google, what’s wrong with you?” And so on.

Since this blog is supposed to document my post-employment adventures, I guess it makes sense to start at the beginning: Why I left Google, and why I’m not planning to be an employee again for the foreseeable future.

Was it because I no longer liked the project I was working on? No. My last project was Google Chrome. It’s a pretty fantastic project, I’m a fan of the product, I was working with a lot of incredibly great people, and it was, for a long time, an incredible learning experience to be part of such a massive engineering undertaking (last month, over 600 user accounts made code changes), witness the problems you start having at very large scale, and participate in fixing them. To be honest though, I enjoyed myself quite a bit more when I worked on much smaller teams that owned an entire product end to end, such as the Google Desktop team that was never more than about 18 or so engineers and about 30 people in total, yet produced and supported a product used by tens of millions of users every week.

Was it because, for the last three years of my nine and a half years at Google, I was working remotely from Iceland? Not really. The Chrome project is a fantastic project for working remotely, because its culture fosters contribution from teams and individuals all over the world. I traveled a fair amount, enough to see the core team in California quite regularly, but not so much that it became a drag. If I’m being honest though, I think I might have stayed at Google for a bit longer if I’d been working from Google HQ in Mountain View, California. There is just so much Kool-Aid to drink there.

Was it because I felt like I was no longer learning new things and growing in my role at Google as fast as before? Maybe a little bit. For my last couple of years there, I started feeling that maybe Google wasn’t the place where I was going to do the best work of the rest of my life. But that wasn’t the only reason. If it had been, it would have been quite easy to let things slide, stay in the cushy job, maybe switch projects to something where I could learn a bit more.

I think there are two separate reasons I decided to leave. One is that I have unfinished business, and the other is that I want to be the master of my own destiny to the largest extent possible. Let’s start with the latter.

I went through two different project cancellations at Google, of projects that I was leading at the time of cancellation. One of them I led from its inception, the other I had taken over about a year prior. Both of these projects were innovative, risky, and were significantly affected by outside forces – competition and a shifting technology landscape – and were cancelled because Google didn’t want to invest more in the face of those outside forces.

I believe the best work of the rest of my life will also involve risky projects.

When you do a risky project at a big company, there will always be a decision maker somewhere above you with the authority to pull the plug, regardless of how much you are willing to fight for the project, make the case, and pledge your blood, sweat and tears to make things work. To make matters worse, when the plug is pulled, the project might completely disappear from the face of the earth.

When you do a risky project as an entrepreneur and things are not quite going your way, your investors might get spooked, you might have to pivot, pull all-nighters, scale down your company, fire some of your best friends, pull favors, piss people off, and generally do incredibly difficult things. However, your ability to figure out ways to continue the project if you still believe in it is much greater. Worst case, you can probably open-source some work that could prove useful to others.

There are other ways to get to finish risky projects, you might say. Go into academia, or join a research department somewhere. You might not get to build full products but you’ll generally be able to find ways to keep researching whatever you’re interested in. This is where my unfinished business comes in.

Before Google, my career in software was exclusively at startups. I was an early employee at Iceland’s first Internet startup, I co-founded a spin-off from that company, co-founded another company on the side that I ended up not joining full-time, and was an early employee at another couple of startups before joining Google. But I never had full responsibility for any of these companies, and I didn’t see any of them through to successful exit or profitability. That said, a few of them did enjoy significant success, ranging from moderate to Icelandic-entrepreneurship-landscape-changing.

Bottom line: I have the bug. I need to build my own company. I have a lot of useful experience that I can build on.

I might be crazy. The statistical track record of entrepreneurship says that I probably am.

But hell, here goes nothing.