How to set Annual Goals (and My Goals for 2016)

Happy holidays, everyone!

The latest episode of Startups for the Rest of Us is about setting annual goals. This inspired me to reflect on my own goals for 2016. Given that my last day at Google will be January 14th and I’ll have to rely only on my Indie business for income afterward, having clear business goals is more important to me than ever.

Actually, I think this is important to every entrepreneur serious about their business. Otherwise, how are you going to make decisions on which measures you should focus your limited attention on?

When making goals, the most important thing is to ask yourself:

Where do I want to be one year from now?

Having a clear vision of where you want to go makes it much, much easier to take actions that bring you there. Don’t just set vague New Year’s resolutions like “I want to make more money” or “I want go get healthier” — have a clear target in mind! Next year, you then can (and should) retrospect on how well you did.

Also, make sure to share your goals with friends (or publicly)! The extra accountability of telling someone else makes it much more painful to slack off on them, which really helps to follow through.

But how do you actually formalize and write down these goals? In this post, we’ll use the Objectives and Key Results (OKRs) framework, which were originally a practice at Intel, but have since spread to companies like Google, Twitter and LinkedIn.

What are OKRs?

The principle is simple: First, you define objectives that represent your high-level goals. For each objective, you then come up with key resultsthat contribute to it. These need to be measurable, as they will be used for scoring: At the end of the planning period (usually a quarter or a year), you review your key results and assign each of them a score between 0 and 1 based on how well you performed on that metric. Weighting all the key result scores of an objective by priority and taking the average then gives you the objective’s score.

A score of 1 isn’t desirable, though — it indicates that the goals were not ambitious enough. Achieving a score of around 0.7 is considered optimal , meaning that the goals are high but not unreasonably so.

By the way, at Google the company-wide OKRs and the company’s subsequent performance on them are shared with all employees. This provides some extra accountability and helps keep the employees

OKRs are not set in stone, though — they can and will change over time as the demands on your business change.

Here are my OKRs for the upcoming year. Hopefully they can help you define your own goals!

Objective 1: Grow the Business

Increase yearly profit (revenue minus expenses) before tax to XXX € for the whole year, YYY € in the last 3 non-promo/non-launch months

Revenue OKRs would be obfuscated at Google and I’d rather not share the numbers here, either. We’re talking about a 60–100% increase over today’s numbers, though.

While very measurable, this metric is not so actionable. To achieve the result, lots of small steps need to be taken over the course of the year that all contribute a tiny bit.

Grow’s average daily visitors to 150 in the last quarter

Currently, this number hovers around 60. The following key results should help with achieving this oral, though.

Get 12 new articles mentioning Timing

This can hopefully be achieved by carefully pitching bloggers and other influencers.

Rank consistently on the first page of Google’s search results for “mac time tracker”

This could be huge for the organic inbound traffic for Timing.

Release Timing 2

Without a clear specification of what that release is to contain, this one is quite spongy. On the other hand, speccing everything out beforehand would be very “waterfall” and not very “agile” 😉 I have already collected a ton of ideas for the update, but which ones will make it into the final version (and in what form) will very much depend on feedback of my beta testers.

Grow the Timing newsletter to 2000 subscribers

Currently, the newsletter has 420 subscribers acquired over the course of almost four years, so it will need to grow much faster than before. To accomplish this, I’m going to distribute much more useful content to the newsletter and give away some content to subscribers. Giving away a 10% discount code to subscribers this month has already improved growth substantially.

Conduct at least four sponsorships or other substantial promotional measures

The first one (sponsoring Six Colors) is already planned for January. Bundles don’t count (unless they’re extremely popular), as they often have virtually no impact outside a little extra revenue.

Objective 2: Provide useful information

This area is fairly new to me, as I’m only getting started with blogging and content marketing, but it is already starting to feel increasingly important to me.

Create 25 pieces of original content

This includes posts like this as well as articles on the Timing blog (which doesn’t exist yet) and possible email courses for newsletter subscribers. Indie Weekly episodes are not included unless they include substantial amounts of original content.

Grow Indie Weekly to 500 subscribers

Indie Weekly is a newsletter for independent app developers, with a focus on marketing and Indie life as opposed to the technical sides of development (for which there already are plenty of other newsletters). The first episode is currently scheduled for the week of January 11th and will be sent to the about 40 people who have already subscribed.

Although Indie weekly is about business, I see it as an effort for the community, so it’s not part of the “Business” objective.

Objective 3: Personal Development

Not all goals need to be about work — never neglect growing yourself! Anyone can build a business, but the only person who can actively make life more awesome for you is yourself.

This objective might actually be the least ambitious of the three (for now), but I might add more points to it over the course of the year. Here are some other personal development goals that might be suitable for you:

  • Read X books
  • Sleep at least X hours per day on average
  • Meditate every day
  • Learn a new language
  • Watch at most X hours of TV per week on average
  • Spend at least X hours focused on deep work (see Cal Newport’s blog for details on what that means)
  • Work at most X hours in total per week

Come up with at least one more side project

I love side projects as a hobby. Building something usable from start to finish and releasing it, all in a few days, feels amazing. And if you’re starting to feel burned out from your main projects, they can also be a welcome distraction.

Attend at least 4 conferences

I’ve had a great time with amazing people at all the conferences I’ve been to, so I’d like to repeat that experience. Plus, every time I come back from a conference I’m super pumped and motivated to get back to doing great work.

Here are some conferences I have in mind:

Give at least one talk (e.g. at a meetup or a conference)

I’d love to share the experiences I’ve made with more people and help them grow without making the same mistakes I did. For this, I might give a talk about my first several months as a full-time Indie developer, for example.

Spend at least 28 days in foreign countries

This can be accomplished by going on vacation, but I’m also considering checking into a surf office or nomad house for a few weeks.

Get fitter

There’s finally an affordable gym close to my place, so I took the opportunity and signed up for it. I mostly want to focus on cardio and condition training in the beginning with some core strength for windsurfing.

In order to have a clear target in mind, I came up with a few vanity fitness goals:

  • Do 50 push-ups in a row (currently around 30)
  • Do 15 pull-ups in a row (currently around 6)
  • Get visible abs


Each of these key results by itself should be fairly achievable over the course of a year (except for maybe the revenue one, which is harder to control as it depends on many other factors), but their sheer number will make it hard to accomplish them all. That’s fine, though — I’m aiming for the aforementioned 70% completion rate.

I mostly focused on the first half of the year, during which I plan to double down on Timing and create a big update for the app. In the second half, I hope to dedicate more time to PocketCAS, which so far has no goals on this list.

These are my goals for 2016! What are yours?

A Hypothetical Web Service Startup Stack

Lately I’ve been wondering:

If I were to build a startup whose main product was a web service (i.e. where the website was an integral part of the product, not just an elaborate ad), what setup would I choose?

(That situation might actually not be so unlikely.) This article is my personal semi-educated answer to this question.

This setup assumes a small team (1–4 engineers) with a mostly-monolithic app (except a split between UI and API, see below) and only a few dozens of QPS — larger services have somewhat different demands that I think most people don’t need to plan for from the outset. Incorporating Microservices should not be too problematic, though (up to the point where you need a more sophisticated system for deploying and managing all of these jobs).

Of course having a great product is way more important than a “good” stack and there are many, many ways to build a great product. But there are still a few (a lot?) of foundational picks to make. The ones in this article are one point to start from.

What would be your picks?


  • One main SSD-equipped dedicated root server, hosted either with Hetzner or OVH. This is quite cheap (less than € 100 per month) and provides lots of power.
  • A second (smaller) root server or VPS that only does load balancing via nginx or HAProxy. This way, the main server does not need to be exposed to the public web at all, hopefully reducing the surface area for attacks (especially database hacks).
  • Alternative: Put everything on AWS. This is better for horizontal scaling, but a few beefy servers can actually get you quite far, as StackOverflow demonstrates. It might also let us avoid having to set up and run our own database (e.g. with Amazon RDSor DynamoDB).
    I don’t have enough experience with AWS to tell whether their services make deployment so much easier to warrant the somewhat higher cost already. If there are other important things that you get “for free” with AWS, let me know — I’m probably missing something.


Every day, a script should back up the service’s database(s) and upload it to a remote storage service (e.g. Amazon S3). Other data on the servers should not need to be backed up, as we should have scripts that can set up a server with a production configuration from scratch. This script should also be used daily to set up an additional server and fetch and restore the database. This ensures that we can quickly recover from an outage. Plus, this server provides us with a system that we can failover to quickly in case something goes wrong with the main machine.

(We also need a service that monitors the successful completion of these scripts so that we know if anything is not in order.)


In order to make the setup of new production, staging and development machines easier (and more reproducible), the servers themselves should need as little individual configuration and state as possible. This can be achieved by running them on CoreOS with Docker for containerization.

For our purposes, the Docker-provided services for orchestration (Docker Swarm) and composition (Docker Compose) should be sufficient.

This also lets us create a development environment that mirrors production, which avoid subtle bugs due to inconsistencies between the dev and prod environments.


(Especially for this part, there are a gazillion alternatives.)

  • Frontend: If possible, a static site that uses React to communicate with the backend and display data. I’d probably use either TypeScript or CoffeeScript instead of writing plain Javascript.
  • Backend: A RESTful API hosted with Django served by nginx. I would actually prefer a compiled, statically-typed language, but Python+Django let you get started extremely quickly and there’s tons of Python libraries for any imaginable purpose (although Python’s package managers are a bit weird).
    Now that Swift is open source, it will hopefully be possible to write solid web services with it soon. But the current state of Swift web frameworks (e.g. Perfect) is not very impressive.
    Protocol Buffers for data transfers, but I have no experience using them with Javascript. NodeJS or Ruby on Rails for the actual code. Or a million other options.
  • Database: PostgreSQL for a relational database. I have little experience with non-proprietary key-value stores, so no opinion there. Protocol Buffers are also great for data storage (especially if you need to extend your schema later), but it seems like only Riak supports them out of the box.
    (This article is not concerned with datasets large enough to warrant the use of e.g. Redis and Hadoop yet.)


Again, lots of options here (and you can be happy with any of them):


That’s it for now, but I intend to update and extend this list from time to time. So if you think there’s something missing, let me know.