
While adding some client-side data caching in [Outline](https://www.getoutline.com) this week I came across a nice detail that was added into the codebase a while ago and I had forgotten about – syncing sign-in state across tabs.

Because Outline is primarily for writing documents, we see a use case where users keep many Outline tabs open containing different docs. This makes maintaining a synchronized authentication state all the more important, it would not be a great experience to have stale auth that errors when you attempt to interact with a long-open tab.

Thankfully depending on your architecture this could be as simple as just a few lines of code…

![Outline signin state](/images/syncing-state.gif)

Outline is built using [MobX](https://mobx.js.org/) for state management. Local client state is split into multiple stores in the app, for example `users`, `documents`, `auth`. The [auth store](https://github.com/outline/outline/blob/main/app/stores/AuthStore.js) contains data related to authentication such as the current user and team – it also manages the persistence and subscriptions. There are essentially three parts to this feature:


* Syncing auth in MobX state to localStorage
* Listening to localStorage changes
* Updating local MobX state from received events


### Syncing MobX to localStorage

MobX has the concept of reactions; side effects that happen in response to changes in observed data. We use a handy MobX method, [autorun](https://mobx.js.org/reactions.html#autorun) that runs an effect whenever any of it’s dependencies change in order to write state to localStorage. For example, within the store constructor…


```javascript
autorun(() => {
  localStorage.setItem("AUTH_STORE", JSON.stringify(this.data));
});
```

### Listening to localStorage changes

Within the constructor we subscribe to the lesser-known `storage` event on the window. The [StorageEvent](https://developer.mozilla.org/en-US/docs/Web/API/StorageEvent) contains tons of useful information such as the `oldValue`, `newValue`, and the `key` that was changed, using this listener we can listen to localStorage changes **in other tabs** and react to them.

### Updating local MobX state from events

We check that the changed key matches our key for persisting auth data, parse the newValue and then act to either logout the user if the data no longer contains a user object (signed out) or to update the local MobX state from the event if the tab is currently signed out. A slightly simplified version looks like…

```javascript
window.addEventListener("storage", (event) => {
  if (event.key === "AUTH_STORE") {
    const data = JSON.parse(event.newValue);

    // If we're not signed in then hydrate from the received data, otherwise if
    // we are signed in and the received data contains no user then sign out
    if (isAuthenticated) {
      if (data.user === null) {
        this.logout();
      }
    } else {
      this.data = data;
    }
  }
});
```

The end result is another one of those little details so subtle you probably wouldn’t have noticed unless this post was written but it helps make the entire application feel more solid!

Syncing sign-in state


Recently translations for Brazilian Portuguese reached the point where we could enable them inside the [Outline](https://www.getoutline.com?ref=tommoor) interface (as a rule I wait until there is at least 90% translation coverage before enabling the option in language settings).

This seemingly small task ended up being a fantastic example of how working on the web with it’s black hole of dependencies can often spiral in ways that are mostly unpredictable.

To enable a new language, it’s also important to enable the locale in the [date-fns](https://date-fns.org/) library to ensure that dates and times through the UI are formatted correctly. Unfortunately date-fns was out of date enough that `pt_BR` didn’t exist and an updated version was needed. Maybe you can see where this is going?

![Bundle Size](/images/bundle-size.png)

Oh crap – upon upgrading we were struck with a [12% increase in overall application size](https://github.com/outline/outline/pull/2164#issuecomment-853502150) (big thanks to [RelativeCI](https://relative-ci.com/) for so usefully exposing this info directly within pull requests). And so began a week of experiments, changing of import styles, auditing of async chunks, and more.

We were able to finally get this down to a _reduction_ in the original bundle size through a combination of:

- Restore the webpack config for `mainFields` to the default value so that it properly considered dependencies exporting es6 modules
- Ensuring the components imported as an async chunk in one place are also imported async elsewhere
- Changing the import syntax from `import format from "date-fns/format"` to `import { format } from "date-fns"`
- Re-configuring webpack splitChunks to [reuse existing chunks](https://github.com/outline/outline/commit/a6d4d4ea3679c2159302a5bb8b08403b5a4a50ce#diff-1fb26bc12ac780c7ad7325730ed09fc4c2c3d757c276c3dacc44bfe20faf166fR112)

I think this really speaks to the importance of having bundle size exposed in the PR process!

Why you need bundle size monitoring


I’ve decided to return to try a more regular blog cadence and record some of the thinking and process behind building [Outline](https://www.getoutline.com?ref=tommoor) (and hopefully other products!).

Because the [source code](https://www.github.com/outline/outline) of Outline is public and is one of only a few large Node applications with a fully open codebase I’m hoping it can allow for a unique lens into product development and engineering decisions that isn’t often shared!

One of the reasons I haven't posted in the last few years was the difficulty in doing so, the old site
was using Jekyll and the hassle of remembering how to publish was just enough friction to prevent it happening… So, in an effort to remove this hurdle I cloned the [outline-website](https://github.com/outline/website) repository, tore it apart, added in all the old markdown posts and ta-da – new site running on Next.js!

Back to blogging


From the start, we knew we wanted to open source our team knowledge base, [Outline](https://getoutline.com). One of the main reasons it exists is because several startups in the space had shut down and we felt that the need remained. During this past year of open development, many other benefits of open sourcing a product have become increasingly clear – both through my own experiences and talking with founders of other companies.


## Peace of mind

In this age of low cost of entry and abundant startups, products are more likely to disappear after a couple of years than succeed. One of the biggest reasons potential customers will never even try your product is the reluctance to invest time and data into something that might not be around tomorrow.

Open source provides some peace of mind – if for whatever reason the product becomes unmaintained then the community can fork the source code (see [The Storybook Story](https://medium.com/storybookjs/the-storybook-story-dd3c1ab0d2ce) for a great example), run their own version in-house, or more easily build tooling to export data in a worst-case scenario.


## Market positioning

A couple of years ago It felt like [GitLab](http://gitlab.com) became a realistic contender for git hosting seemingly overnight. While it has since come a long way, the first version of the product was almost a direct clone of GitHub. 

One of the core reasons that developers flocked to the platform despite this was the [open core nature of the project](https://about.gitlab.com/2016/07/20/gitlab-is-open-core-github-is-closed-source/). For developer tools and platforms, in particular, simply embodying the philosophies of OSS can be enough to differentiate a new product from the crowd.


## Customer acquisition

Open source could be thought of as a subset of content marketing – every commit, pull request, and issue is public content indexed and often keyword-rich. It provides a number of channels for new customer acquisition – the code repositories themselves of course, but also the ecosystem of publications, websites, listicles, and newsletters that cover OSS development.

[Sentry](http://sentry.io), an open source error tracking service, was a project for several years before it spun out into an actual company – today around ~65% of their inbound referral traffic is still from their source code repositories, hosted on GitHub.


## Best practices & documentation

Building in public is a uniquely satisfying experience. Personally, I often find myself performing to a higher standard when I know that all the work I produce is publicly visible. Defaulting to more judicious comments, ensuring full test coverage, and putting extra effort into being a clear communicator.

If you can't go all-in, consider open sourcing components and individual libraries. Once a high-level concept is abstracted and decoupled from the specifics of a codebase it often becomes both easier to reason about and will inevitably lead to better defined API's and public interfaces.


## Community & contributors

At the time of writing, [Sidekiq](https://sidekiq.org), an open source background processing implementation for Ruby, has more than [380 individual contributors](https://github.com/mperham/sidekiq/graphs/contributors) to its repository on GitHub. These people have fixed bugs, filed issues, written documentation, contributed to feature discussions, and generally done the types of things you’d pay a six-figure salary for in the bay area!

Although Sidekiq does offer commercial licenses (and makes a [nice profit doing so](https://www.indiehackers.com/podcast/016-mike-perham-of-sidekiq)) this doesn’t stop community members from donating their time and skills to help improve the software for everyone.


## Hiring pipeline

Wordpress ([famously?](https://hbr.org/2014/04/the-ceo-of-automattic-on-holding-auditions-to-build-a-strong-team)) replaced white-boarding exercises and code challenges with a “try out” period as part of their hiring process, paying candidates to undertake issues in their actual codebase. This is made possible because the code is public, for a closed source team it would generally be out of the question to provide access to the codebase before a hiring decision is made.

While using open source contributions in a general sense as a hiring decision maker is generally considered problematic – *specific* experience with your product’s codebase is an ideal way to gauge both a potential hires technical and communication skills in a realistic way.


## Free tools & services

At the beginning of a project, every dollar matters and spending hundreds on infrastructure before the product is making any money is a difficult hurdle for many to overcome. Luckily, lots of tools have free or heavily discounted plans for OSS projects as a way of giving back – whether it’s CI, server hosting, error tracking, or mailing lists.

This is a great list that covers many freebies: [opensource candies](https://github.com/velikanov/opensource-candies).


## But it’s not all roses…

So at this point, you’re probably ready to hit the big red button and publish all your code… right?! While you’ll find that many things are improved with an open codebase it’s important to note that there are some downsides to take into consideration…

#### Licenses and agreements
It’s a good idea to make sure that outside contributors sign agreements such as a [CLA](http://oss-watch.ac.uk/resources/cla) before their code is merged into the project. In the event of a future acquisition or change of ownership you’ll thank your past self.

#### Competitors get insight into feature development and roadmap
I believe that for most startup companies today this is a non-issue, founders tend to be overly protective of their ideas and roadmap when in reality they’d be better off getting this information in front of potential users as soon as possible.

But of course, some ideas have a wider moat than others and this insight into your companies plans might be something you need to avoid.

#### No security through obscurity
Open source software is generally considered more secure in the long term – more eyes on an application’s code can help identify and fix security holes. However, opening up your code to scrutiny also provides would-be attackers with direct insight into potential loopholes and security problems. 

It also means that even more care has to be taken than usual for sins like accidentally committing API keys into git or adding customer details into public issues.

#### Increased overhead of documentation
It’s even more important when code is public that documentation is thorough, clear, and makes as few assumptions of the reader as possible. Writing this level of documentation takes a lot of time and effort that in the early stages of a product might be time better spent on core business problems.

#### Community maintenance
Similarly, a vibrant open source community doesn’t come for free. Issues need to be triaged, questions answered, and pull requests reviewed. If the issues and unfinished branches begin to pile up then this is an immediate warning flag to users and those considering contributing.

As well, the more popular your open source project becomes the more work there is to do shepherding and maintaining the community – popularity may be a curse that only larger teams can manage…


**If you've had great success or failure making your companies code public I'd love to hear about it in the comments.**

You should open source your product


In 2017 it’s incredibly hard to use the internet without constantly giving away your personal information… it’s absolutely the norm for a single website you visit to send personally identifying information to your ISP, the website itself, their advertisers, multiple tracking and analytics companies, plus all the social networks you’re logged into.

I don’t think you have to be paranoid, taking part in nefarious activities or a privacy obsessive to not want this to be the case! To me it seems like common sense that you would reduce the amount of personal information you leave lying around on companies servers in the same way it’s common sense not to leave your bank details lying on the street.

Thankfully with just a little effort you can make a huge difference without having to jump through lots of hoops every time you use the internet!


## Install an AdBlocker
You’re probably already using an AdBlocker, according to [ClarityRay](https://www.quora.com/What-is-the-percentage-of-Internet-users-that-employ-AdBlock-Plus-or-similar-ad-blocking-plugins) on average around 10% of visits to websites use an AdBlocker of some description.

By blocking adverts you reduce visual clutter, increase page load times and limit the amount of information about your browsing habits gathered by third parties. I recommend [UBlock Origin](https://chrome.google.com/webstore/detail/cjpalhdlnbpafiamejdnhcphjbkeiagm) for the lightest footprint.

Since installing on my machine it has blocked 7% of outgoing connections - almost 1 million requests.

Whilst you’re at it don’t forget about your mobile browser. For iOS [‘Focus’ by Firefox](https://itunes.apple.com/us/app/firefox-focus-privacy-browser/id1055677337?mt=8) is the way to go, ensure you enable the integration with Safari to get all it's benefits.


## Ensure HTTPS
The [HTTP Everywhere extension](https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp/related) from the EFF makes sure that you always connect to the secure version of web services if available - this prevents your ISP and other middlemen from inspecting and potentially injecting content into webpages you load (Yep, [they](http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/) [do](http://arstechnica.com/uncategorized/2007/12/canadian-isp-tests-injecting-content-into-web-pages/) [this](http://www.infoworld.com/article/2925839/net-neutrality/code-injection-new-low-isps.html)).


## Change Your Default Search Engine
Google is great and the results are obviously top notch - however their data collection policies are really awful. I find for 99% of searches [DuckDuckGo](https://duckduckgo.com) does just as good a job and doesn’t track your activity against an extensive personal profile like Google will.

DuckDuckGo makes a great default search engine that is visually very similar to Google, you can find [quick install instructions here](https://duckduckgo.com/install).


## Chrome Privacy Settings
Using Chrome? Next up lets customize the privacy and content settings to be a little more picky about the data we give away. First off you’ll want to block third party cookies, navigate to: [Chrome Content Settings](chrome://settings/content)

Check “Block third party cookies and site data”. This helps to prevent trackers that may slip through UBlock from tracking you across websites.

Next head to [Chrome Settings](chrome://settings), scroll to the bottom and click the tiny text that says “Show advanced settings…”, scroll again to Privacy (Phew, it’s almost like they don’t want you to find this!). I would recommend unticking the majority of these settings apart from Send a “Do Not Track” request with your browsing traffic which should be ticked and probably isn't.

<p style="text-align: center;"><img src="/images/chrome-privacy.png" alt="Chrome Privacy"></p>
￼

## Google Privacy Settings
The big G provides a [single dashboard for managing activity](https://myaccount.google.com/activitycontrols) that they track and save. Personally I have everything here disabled (paused) apart from ‘Device Information’ which keeps your apps and settings synced across devices. By default Google will be tracking your location, search history and every webpage you visit if you’re using Chrome - eesh.


## Facebook Privacy Settings
Most of us have a Facebook account even if it doesn’t get used too much. At this point we’ve blocked Facebook’s trackers on other websites, told them not to track us and ensured we’re always viewing Facebook over HTTPS but there’s definitely more to do! By default Facebook’s advertising policies are quite… invasive, lets turn them down a bit by visiting the [Facebook Privacy Settings](https://www.facebook.com/settings?tab=ads)

<p style="text-align: center;"><img src="/images/facebook-privacy.png" alt="Chrome Privacy"></p>

Turn everything on that page to “No”. Next hit up the [timeline option](https://www.facebook.com/settings?tab=timeline&view) and consider turning off photo tagging suggestions at the bottom of this page.

This is also a good opportunity to double check which apps you’ve authorized to read your Facebook information and remove any you no longer want to have access, the full list of [apps with access to Facebook](https://www.facebook.com/settings?tab=applications).

<p style="text-align: center;"><img src="/images/facebook-apps.png" alt="Chrome Privacy"></p>

At the bottom there is also an “Apps Others Use” section, click edit and untick everything in there which gives permission for your friends to share your data. It won’t have any effect on your personal Facebook experience as far as I can tell.


## Twitter Privacy Settings
We’re getting somewhere, don’t give up yet! Next up is Twitter - similar to Facebook you’ll want to turn off all the advertisement tailoring and maybe the default location tagging depending on your preference on the [Twitter settings](https://twitter.com/settings/security) (Don’t forget to hit ‘Save Changes’ at the bottom of the page)

You might have accidentally uploaded your entire address book to Twitter (they make this way too easy) - double check if that’s the case here and consider deleting the data on the [Twitter contacts dashboard](https://twitter.com/settings/contacts_dashboard).

This is also a good opportunity to double check which apps you’ve authorized to read your Twitter information and remove any you no longer want to have access, here is the full list of [apps with access to Twitter](https://twitter.com/settings/applications).


## Install a Password Manager
If you’re still using a ‘system’ (hey, we’ve all done it!) or worse yet the same password for everything then now is the time to upgrade to a Password Manager, that way if one website gets compromised you don’t risk your other accounts being hacked too.

[1Password](https://1password.com) is pretty awesome and you can make this change gradually by moving your passwords into the manager as you login to services instead of all in one go. You’ll never have to try and remember which dumb rules a website expected for a password ever again.


## Install a Firewall
It’s easy to forget about the desktop apps you use, they are all constantly phoning home too. [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) will alert you every time an app tries to access the internet and let you set rules for access rather than letting everything out by default.

I’ll be honest, it’s a real pain to use for the first few hours because rules need to be created for all your existing apps but the peace of mind may be worth it - did you know Spotlight makes requests to lots of different services for everything you type in there?


## Use a VPN
A VPN obscures your real IP address, and with it your location. It also creates an encrypted tunnel for all of your internet traffic that prevents your ISP from knowing and logging the websites that you visit.

If you have the technical skills and time I highly recommend setting up your own installation of OpenVPN - [here is a good tutorial](https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-16-04) for doing so on a DigitalOcean server that will run you $5/month. [TunnelBlick](https://tunnelblick.net/downloads.html) is a great well maintained, open source OpenVPN client for Mac.


## Fin
Phew! If you got this far then you are now considerably better off than you were at the start of this post.

Is this foolproof? No, of course not - but with a little effort you’ve vastly reduced the amount of personally identifying information that is being gobbled up by companies about you with minimal affect on your everyday computer usage, nice!

**Got any more suggestions for easy to implement privacy fixes? Let me know in the comments.**

Reclaiming your privacy


At [Speak](https://speak.io) we’ve been building team communication products for years, but when we began down this path I don’t think that any of us knew what was ahead. We all came from different backgrounds in gaming, b2c and ecommerce but we’d never tackled anything built for teams.

We’ve come to discover that creating a successful team product has it’s own set of unique challenges...


## Multi platform

Unlike one player consumer apps like games and photography tools, multi platform support is critical to the success of a team product. Whilst it’s easy to forget when living in the tech bubble, not everyone uses your OS of choice and most teams will have a mixture of operating systems in use. If your tool needs to be used by everyone then multi-platform is a must as soon as possible.

If you’re building for web then this means compatibility with all the major browsers, not just Chrome… and desktop apps need to embrace Windows with gusto!


## Realtime is Hard

If you come from a background of building web experiences that rely on a page reload or short session times, moving to building real-time systems with millisecond race conditions and a client that users keep open for days or even weeks introduces a whole new set of fun challenges.

At [Speak](https://speak.io) we aim to connect audio in under a second. To achieve this, 50+ messages race through websockets and through our evented system which is built to withstand misordering, mistiming and lost messages altogether. Each layer of the system has to be built with fallbacks and proper error handling to ensure that when things go awry the user experience doesn’t end up suffering.


## Activation is harder

Activation is that ‘magic moment’ when you consider that a user has engaged with your product in a meaningful way. This may be sending an email, creating a post, uploading a file or in our case - having a quick audio call.

This is exponentially more difficult when you require multiple people to use your product synchronously to achieve it, so anything that can be done to give your team product a one-player experience will pay dividends as users will be more likely to keep the app open and actually still be online when their coworkers signup too...


## Quality is Paramount

Early adopters playing around in their spare time are the most forgiving of users, they’re often amazingly keen to find and report bugs, put up with inconsistencies, fiddle with settings and love to be involved in helping with the product development process.

Every workplace has it’s early adopters for sure, but an entire team of them is an unlikely find! In order for your platform to be adopted in the workplace, beta quality just won’t do. A high level of polish and reliability is a must for the vast majority of teams to adopt and stick with your app.


## Preferences are great

With our last product we were prone to thinking that if you design something well then options aren’t needed. In hindsight, this was a little naive, and when Slack came around this cemented that fact as the app was lauded for its customizability - not complexity.

You can almost think of a team as one user with multiple personalities, one minute they want a preference for this, and then a setting for the opposite, plus an admin control for everything. If you don’t satisfy all of the personalities at once then slowly the team will stop using the product. Clear and well organised preferences and options are the right solution!


## Business != Boring

The trend of employees bringing consumer apps into business isn’t going away and the line between personal life and work continues to blur for creative professionals. Everyone would prefer to have a little fun whilst they work and one way to inject this into your day is to use tools with personality, animation and excitement!


**The bar for a great business tool is continuously being raised and we’re excited to be tackling these challenges! Building something for teams yourself? I’d love to hear any thoughts you have on this subject in the comments…**

Lessons learnt building team communication products


Last week we launched [Speak](http://speak.io) on ProductHunt, there were a few days packed full of energy - many comments of [positivity](https://www.producthunt.com/posts/speak) and praise on the design, hundreds of teams signed up, lots of issues were reported (and quickly [fixed](https://github.com/speak/issues/issues?q=is%3Aissue+is%3Aclosed)), our servers were even briefly overloaded with traffic!

Almost two weeks later and we’re now experiencing the quiet after the storm. Every day has had a different vibe (at least, in my head) and my mood is vastly affected on an hourly basis by the feedback we receive and metrics we track… it’s hard to keep an even keel. As is often the case, [Paul Graham](http://www.paulgraham.com/really.html) puts it best:

> "In a startup, things seem great one moment and hopeless the next. And by next, I mean a couple hours later.”


Personally I think this is one of the most difficult times in a startups formative stages, and it's easy to lose heart. You have a few users, not enough to get excited, some retention, but not enough to be ecstatic, and requests pulling you in every direction from those that did signup and want you to solve their very specific problems.

Dan Shipper found the [perfect analogy](http://pando.com/2013/06/19/why-youre-on-a-startup-roller-coaster/) in that of a stock trader - if you constantly check how your stocks are performing then there is just as much chance of them being down as up, even if the longterm pattern is one of positivity and growth.

An acute awareness of this is the biggest step to dealing with it. Talk to customers, track and celebrate the small wins and keep plugging away at building something great!

The startup rollercoaster


Do you remember being told as a child that your eyes were bigger than your belly? Perhaps you were piling far too much food on your plate at dinner...

As a kid I always wanted to eat too much, grow up faster, be taller. I’d look up to those in years above at school and think how much older they seemed and that I couldn’t wait to be their age with all the benefits that it would bring… I think most of us thought something along these lines, right?!

Of course now we realise how important those years are - there is no way we could simply skip to final exams without all of the learning and growth that these earlier days provide. I’ve found that in building startups, the very same temptations exist. The desire to be bigger than your boots, to grow too fast and to try and emulate those that are more grown up.

At [Sqwiggle](https://www.sqwiggle.com) we made this classic mistake too, jumping into hiring as soon as we’d raised our [seed round](/2013/09/06/lessons-learnt-raising-a-million-dollar-seed-round/) because that’s what you do. But really we were still in this early period of pre product market fit - we should have still been testing, experimenting and iterating towards great traction and zero churn. In hindsight an early burst of signups coupled with a successful funding round had confused us into thinking that we already had product market fit and our ambitions meant we were only too eager to grow up to the "next stage".

Step back, embrace where you are at, don't grow too fast.


**Update:** Brad Feld just published a post, "[The Illusion of Product Market Fit](http://www.feld.com/archives/2015/01/illusion-product-market-fit-saas-companies.html)" which sums up the above far better than I have.

Don't grow too fast


![IWNA Beijing Tour](/images/baidu.jpg)

Writing is always the first thing that gives, whether we’re having a bumper month or a ton of trouble with our architecture and product - it seems as though there is always an excuse not to write about it...

This was definitely the case last year, where I published a grand total of _zero_ posts. I write as much for ‘future me’ as anyone else and I don’t want to look back on 2014 in a decades time and ask myself - “wait, what the hell happened that year?!”. In fact, a lot went on...


## Sqwiggle
This deserves (and will get) a post or two for itself, needless to say it was a year far from smooth sailing and chock full of events.

I feel as though we experienced the entire startup lifecycle several times over from the post-raising hiring spree, a traction plateau and a trip through the infamous ‘valley of death’... much more to come on this.


## Personal
On a personal level, 2014 was my most travelled year so far, and almost none of it planned more than a month in advance. It's fantastic having our company set up in a way that makes this possible...

- January - Starting the year with a week in **New York**
- February - **Lake Tahoe** for our first [company retreat](http://blog.sqwiggle.com/lessons-learned-first-company-retreat/)
- March - My first SXSW experience in Austin, **Texas**
- April - Two weeks in **Berlin** checking out the scene
- May - Back to **England** for two weeks sorting out visa
- June - Moved back to **San Francisco**
- September - Two weeks in **[Beijing](https://medium.com/@kinwong/introducing-the-china-trek-for-founders-6a5f13ea2d3)** and **Hong Kong**
- November - Exploring **Los Angeles** for a quick break
- December - A long weekend in **Seoul** for a speaking slot and christmas in **England**

At the beginning of summer I finally regained my H1B visa and moved back to San Francisco on a more permanent basis, found a room, bought some furniture and a [bike](http://instagram.com/p/rDO9jDpHUY).

It’s nice to have somewhere to call home for the first time in 3 years.

A Year In Review


![The World](/images/timezones-globe.jpg)

It is often perceived that the challenges in building a distributed team lie in communication over distance, however with todays incredible technology and tools the problem is really one of communication across timezones. At Sqwiggle we are currently spread across 4 timezones and it is this rather than distance that creates problems like confusion over meeting times, not enough crossover time for discussions, odd working hours and more. These are just a few of the tricks and thoughts that I've had on the topic:


## Keep communications in one timezone
In emails and spoken conversations try and pick one timezone and stick to it in all of your communications. This small hack makes a huge difference in stopping confusion, and you'll always know which timezone you arranged your meeting in. Of course which timezone you pick is upto you, it could be where you are based, where most of your clients are or where your company is, just be consistent.

## Use a shared calendar
A shared calendar such as Google Calendar provides a whole bunch of benefits, for a start each participant sees the event in their own timezone and in relation to their own day - a huge confusion buster. A shared calendar also has the advantage of increasing transparency within the company

## Don't spread your team too thin
When we began advertising our [open positions](http://angel.co/sqwiggle/jobs) we received a lot of applications from all over the world thanks to our "you must remote work" policy! This was great but we soon realised that at our size and stage of the company we would have to filter out many applications purely based on location so that we could reduce our timezone-spread.

## Split your day in two
Right now we are beginning to deal with the [maker / manager transition](http://www.paulgraham.com/makersschedule.html) at Sqwiggle. In my experience so far, being based in Europe with over half our team in the US affords a distinctive split in the day where the morning is quiet and great for focus on coding tasks whilst the afternoon becomes planning, discussion and other non-maker duties.

## Something's gotta give
Even taking these thoughts into account I've found that when working closely with a geographically diverse team the best thing you can do is increase the amount of crossover that you have for syncronous communication. This generally means one or both parties shifting working hours to accommodate more time spent working together. [Sqwiggle](https://www.sqwiggle.com) has proven very useful in this respect and I often stay logged in until late into the evening making me available for anyone on the team to ask quick questions that come up during their day.

**Do you have any tips for working more effectively between timezones? Let me know in the comments, I'd love to give them a try**

<p class="caption">Photo by <a href="http://www.flickr.com/photos/9828543@N05/5334352031">Stephen Ritchie</a></p>

The trouble with timezones


![Commuting](/images/commuting.jpg)

This weeks [Startup Edition](bit.ly/1eFpetV) asks the brilliant, open-ended question "why are you working on your startup?". It's easy to get caught up in the day-to-day of building a new company I thought this would be a great chance to pause and reflect, what brought me here and why is this so important?

The startup I'm working on is called [Sqwiggle](https://www.sqwiggle.com), we've taken to calling it your office in the cloud - a place where remote and distributed teams can feel as connected and together as a real world office.

[Connecting the dots](http://news.stanford.edu/news/2005/june15/jobs-061505.html) backwards it is easy for me to see a pattern of factors in my life that have led up to building this company and mission.

I've always been drawn to the idea of working without a fixed location and being tied to a desk was one of the reasons that I left my previous career in architecture. Once we really took the plunge at [Buffer](http://techcrunch.com/2011/12/20/sharing-scheduler-app-buffer-raises-400000-gets-kicked-out-of-us/) by moving to Hong Kong, I knew that this was a way I could enjoy working for a long time (although, fixing bugs from the beach can be both awesome and a burden!).

One of my character traits is a sensitivity to inefficiency - I take shortcuts, jaywalk, multitask, answer emails whilst... well, doing anything and do my upmost to get as much productivity as possible out of every moment! One of the biggest and most frustrating examples of inefficiencies in the world is the life of a typical knowledge worker.

They sleep at home, have breakfast, catch a moment with the kids(?) and then head out the door - commute to work, sometimes taking an hour [or more](http://en.wikipedia.org/wiki/China_National_Highway_110_traffic_jam) and sit for 8 hours in a drab, uninspiring office building in front of a computer that's probably slower and older than the one they have at home. Then they travel home in the same traffic, catch a moment with the kids before they sleep and repeat. This system wastes untold amounts of energy and time in an age when we're desperately short on both.

To me this is one of the biggest opportunities for revolution in business today. The technology is there, but the tools and attitudes to working remotely have not caught up. I have a passion for building things that make peoples lives better and what better way to do that than improving the way they work?

Last week we had the greatest email from one of our customers. They said they were considering moving house to a different town that they would enjoy more now they were using [Sqwiggle](https://www.sqwiggle.com) at their company.

**Notes like this are why I can't wait to wake up and work on Sqwiggle every day.**

<p class="caption">Photo by <a href="http://www.flickr.com/photos/ashleycampbellphotography/">Ashley Campbell</a></p>

Commuting, inefficiency and working from the beach


<p style="text-align: center;"><img src="/images/san-francisco.jpg" alt="San Francisco" style="width: 648px;"></p>

Over the last two months I've had the incredible privilege of being in San Francisco putting together a seed round for [Sqwiggle](https://www.sqwiggle.com) with my co-founders, [Matt](https://twitter.com/mattboyd) and [Eric](https://twitter.com/ericbieller). Incase you haven't come across it, Sqwiggle is a tool for distributed and remote teams to communicate better - we want to make remote working truly great.

Looking back, I can't even really remember the moment that we decided to raise funding. We kicked around the idea since day one and had discussed on many occasions. In the end, we came to a consensus: with a little more money we could grow much faster and it would really help with the larger technical hurdles we were facing. Within a day I had a flight booked to the U.S. and began reaching out to potential investors and contacts.  

It's been crazy and exciting - for all of us this was the first time we had been actively involved in raising funding. We had so much to learn! Here are some of the unexpected lessons learned:

## Find Your Ambassador
If I had one key takeaway it would be to find a single, well-connected person that can be your ambassador and help you get meetings with other investors through solid intros.

In our case this person turned out to be [Naval](https://angel.co/naval). My co-founder, Matt, reached out through a cold email and not only did he reply (amazing in itself!), but in what was definitely a turning point he also invited us down to the office, immediately understood the value of Sqwiggle and decided to invest almost immediately.

## Selling the Product
Over a couple of evenings I read Derek Sivers' book "[Anything You Want](https://sivers.org/a)". One quote stuck out to me - when you have a great product "all doors will open". He found that a lot of previous ideas were like pushing a rock up a hill, but with CDBaby everything just seemed to be so much easier.

I definitely felt this on several occasions, where we stayed fairly quiet and potential investors started considering Sqwiggle, the many uses, expansion, enterprise possibilities and before I knew it they were onboard. Sometimes the right idea at the right time really can sell itself.

## The Founder Story
One piece of feedback we got often is that at the seed stage it's all about the founder story, so make sure it's compelling. At [Sqwiggle](https://www.sqwiggle.com) our experiences of remote working came from many different angles and this helped us build a compelling narrative on how we all came across the problem separately and came together to fix it.

Every company has a story behind how and why it was formed, how you came together and your experience in the vertical. It's important to figure out yours and make sure that you're just as good at selling yourselves as the product.

## Everything Stops
I heard this statement many times before we started fundraising but didn't realize how true it really was. Once you pack your schedule with intros and meetings, there isn't time for anything else. The small amount of downtime is often consumed mentally and physically recovering.

## AngelList
There is no denying, trending on [AngelList](https://angel.co) really is a golden ticket! I won't go into how to achieve this, mainly because I don't have a clue - but also because others have [already done it better](http://blog.justinthiele.com/trending-on-angellist-tactics-results/). We were trending for around two weeks and during that time had 55 intros and many offers to invest online through the platform. I can't even begin to stress how valuable this turned out to be.

## VC's Aren't What I Thought
There are many different types of people that work for Venture Capital firms and they can't all be tarred with the same brush. Some partners come with decades of experience, others are serial entrepreneurs and each takes a different angle and will offer completely different value to your company.

I went into the process with a skewed negative view of VC's (possibly from startup blogs?) but came out with four Venture Capital firms as investors.

## Metrics and Numbers
Be careful and consistent with numbers that you decide to give out. In general, don't be afraid to say that you don't know a particular figure (this isn't Shark Tank). We put together a pack of metrics updated once a week or so that we would send to investors when they asked. Regardless, most investors are more focused on the team and core idea rather than fine-grained metrics at seed stage.

## Beer and Wine
After meeting with a potential investor that we all agreed we didn't get the right vibe from we settled on the rough idea of a "beer rule". Which essentially meant that the person had to feel like someone we could grab a beer with, perhaps to lay down the current company problems and brainstorm ideas. Not everyone falls into this category - and I found it a great way to filter out those that didn't fit with our vision.

## Keep Fuelled
On an average week whilst we were fundraising I walked over 115,000 steps (or 48miles!) according to FitBit. I also ended up skipping meals, but this definitely isn't advisable - if a hearty breakfast was ever appropriate, this is the time. [GetAround](http://getaround.com) also proved to be a saviour for many last minute trips to Palo Alto because you just can't walk everywhere!

**Did you recently raise funding? I'd love to hear your story or how your experience differed in the comments.**

Lessons Learnt Raising Our Million Dollar Seed Round


<p>We recently started charging companies to use <a href="https://www.sqwiggle.com">Sqwiggle</a> after only a month in private beta. We definitely don&#8217;t have all of the functionality that customers asked for, there are still bugs and the price is high enough to put-off some companies from using the service.</p>

<p>At first glance this might seem like a terrible idea, but being clear about our pricing and business model from day one has helped to both differentiate Sqwiggle from other perceived competitors and proved that companies are willing to pay to solve the problem we&#8217;ve identified - a crucial part of validating the business idea.</p>

<h2>SaaS Kicks Ass</h2>

<p>The best pricing strategy balances the needs of your startup and customer perfectly. I believe this is the reason that <a href="https://en.wikipedia.org/wiki/Software_as_a_service">SaaS</a> has become an increasingly popular pricing choice. Our current model is to charge monthly, per user with a two week free trial. Every factor that makes this a great choice for Sqwiggle also works as an advantage for the customer.</p>

<p>For example, we plan on running servers for hosting video calls with many participants through Sqwiggle. For an app that becomes part of a teams workflow being used all day, every day, the cost of this soon becomes significant. By charging per-user, as the amount of video bandwidth increases, so does our income.</p>

<p>On the flipside, charging per-user allows the cost of using Sqwiggle to grow with the size of your business. If you&#8217;re paying an employee thousands of dollars in wages per month then a couple of cents per day to make them more efficient and happy is a no-brainer.</p>

<p>There are also a ton of other advantages that have been covered many times; predictable recurring revenue is the lifeblood of a SaaS business allowing us to plan expansion, costs and hiring. A trial with zero upfront payment means that employees can champion Sqwiggle internally and see the benefits without needing to ask higher management for approval.</p>

<h2>The Price Point</h2>

<p>It&#8217;s very early days and we&#8217;re still experimenting with the optimum price to charge per user. At the moment we have a single price of <strong>$9 per user, per month</strong>. There were a couple of factors that came into our decision to choose this amount:</p>

<h3>Value</h3>

<p>For a distributed team Sqwiggle offers a lot more value than the competition with persistent presence and instant video chat - we wanted to reflect this in the price, charging more than the typical $2-3 per user.</p>

<h3>Psychology</h3>

<p>Three <a href="http://link.springer.com/article/10.1023%2FA%3A1023581927405">studies</a> by MIT and the University of Chicago  in 2003 showed <em>"conclusive evidence that $9 price endings can increase demand"</em>, even amongst cheaper options. Whilst still charging a premium price and taking into account this rule we wanted to keep the figure as a single digit so that psychologically it still feels like it is relatively much lower than $10 or $9.99 than it is.</p>

<h3>Simplicity</h3>

<p>One of the key values we have at <a href="https://www.sqwiggle.com">Sqwiggle</a> is simplicity. We put great pain into ensuring that every part of the product is easy to use and understand. Having a single price keeps things inline with our values and avoids any <a href="https://en.wikipedia.org/wiki/Analysis_paralysis">decision paralysis</a>. &#8220;A decision can be treated as over-complicated, with too many detailed options, so that a choice is never made&#8221;.</p>

<p><strong>What do you think, is this strategy wise? Is there anything you would you do differently? I&#8217;d love to hear your comments.</strong></p>

<p>This post was written as part of <a href="http://startupedition.com">StartupEdition</a>, a weekly collection of curated posts by startup-minded people. Read more thoughts on <a href="http://bit.ly/12LHoau">pricing strategies here</a>.</p>

Pricing That Scales

<p><img src="http://media.tumblr.com/c09a3dfc00b2f131061165f72467df1c/tumblr_inline_mocl6u3Mlb1qz4rgp.jpg" alt="Wordpress P2" title="WordPress P2" /></p>

<p>At <a href="https://www.sqwiggle.com">Sqwiggle</a> we&#8217;ve been using the <a href="http://wordpress.org/extend/themes/p2">P2</a> WordPress theme for over
a month now for a large chunk of our asynchronous internal discussions and I thought it would be interesting to pull apart our time with it a
little.</p>

<h2>What is P2</h2>

<p>For those that might not have heard of P2 before - It is a theme based on <a href="http://en.blog.wordpress.com/2008/01/28/introducing-prologue/">Prologue</a> which changes the flow and interface of WordPress to move composition inline. This makes creating posts as easy as Tumblr or Twitter for example, changing the dynamic to that of an internal social network.</p>

<p>In the last month <a href="https://www.sqwiggle.com/team">three of us</a> have posted 170 times with 50 different tags, and commented on those posts over 260 times, presuming we would have had these conversations over email we might have saved our individual inboxes of around ~430 emails each and that&#8217;s not even counting other interactions such as &#8216;liking&#8217; a post!</p>

<h2>What is it good for</h2>

<h4>Asynchronous discussions</h4>

<p>P2 works like an internal tumblr, you can quickly create different
types of posts such as status, link, quote or a more formal blog-style
post. Others can comment and comments can be nested leading to
good discussions.</p>

<h4>Encouraging transparency</h4>

<p>With email it is easy to accidentally forget to CC team-mates or not
realise that others might have great input on a seemingly unrelated
issue. Stripe fights this by having all <a href="https://stripe.com/blog/email-transparency">internal email open</a>, P2 can
help you to reduce or cutout email altogether.</p>

<h4>Extensibility</h4>

<p>Of course <a href="http://www.wordpress.org">WordPress</a> is open-source so in theory it would be possible
to make any customisations you like to any part of the theme. There
are already some ’<a href="http://wpcandy.com/recommends/plugins-just-for-p2-theme/">must have</a>’ plugins for P2 such as likes, @mentions
and more that need to be installed to get the full benefits.</p>

<h4>Search and archiving</h4>

<p>Of course WordPress comes with tagging, categories and a pretty decent search. Finding that discussion you had on a particular topic is easy with a combination of these (Of course we only have a months worth of content - so only time will tell here!)</p>

<h4>Cost</h4>

<p>As WordPress is free software the only cost in hosting, we have our P2 installation hosted on a cheap VPS and the cost is negligable. You could use a hosting service like <a href="https://wpengine.com/">WPEngine</a> if you preferred not to take care of this yourself.</p>

<h2>What is it bad for</h2>

<h4>Realtime discussions</h4>

<p>Although not &#8216;bad&#8217; per-say, we prefer to keep real time discussions to our <a href="https://www.sqwiggle.com">Sqwiggle workroom</a> - If everyone is online, then it&#8217;s just much quicker and easier to make decisions this way.</p>

<p>Items posted in P2 don&#8217;t necessarily need a reply straight away, or ever in a lot of cases.</p>

<h4>Aesthetics</h4>

<p>The out-of-the-box experience with P2 isn&#8217;t incredible, the styling is rough around the edges, as are many of the plugins. We spent a couple of hours customising the theme to match our internal admin tools a little better, but nothing too fanciful.</p>

<p>If you want a finely polished experience then this probably isn&#8217;t the tool for you unless you like customising your software!</p>

<h2>Where next?</h2>

<p>I&#8217;m really excited to see the development of <a href="https://sendtoinc.com">Inc</a> from the Kippt team as it seems they are tackling this space in a great-looking and easy to use package.</p>

<p>I don&#8217;t think we could go back to not having a tool like this in our arsenal here at Sqwiggle. An internal social network is a must-have for any distributed team, whether it be a tumblr, twitter or a <a href="http://ryancarson.com/post/49494542970/how-to-use-a-reddit-clone-to-boost-company-culture">reddit clone</a>!</p>

<p><strong>If you don&#8217;t have an avenue for casual, rich, asynchronous communication in you company then you might just be missing out.</strong></p>

Build Company Transparency and Reduce Email Using WordPress P2

<p><img src="http://media.tumblr.com/8e4a87497c812b60046f6bde5d6a775f/tumblr_inline_mlxf3nnha11qz4rgp.jpg" alt="Om nom nom nom" title="Dogfooding" /></p>

<p><em>Dogfooding: A slang term used to reference a scenario in which a company uses its own product to demonstrate the quality and capabilities of the product.</em></p>

<p>I guess I&#8217;ve always been a little envious of companies like GitHub and 37Signals, not for the many obvious or usual reasons but because they get the joy everyday of the software they create and the software they use to create it being one and the same thing.</p>

<p>For certain products I feel like this actually goes a lot further than just dogfooding, every company knows they should use their own product. But in this case It&#8217;s recursive positive feedback, an upward spiral of greatness where you improve your product and this in turn makes the team better/happier/more efficient at improving your product. I can&#8217;t think of a situation more perfect for a newly born startup - where really understanding your customer and market is the most important factor.</p>

<p>At <a href="https://www.sqwiggle.com" title="Remote working and collaboration">Sqwiggle</a> we&#8217;re lucky enough to have this possibility, we&#8217;ve been distributed from the day we started working together and have been using the app as our primary form of communication from the moment it became viable. We have morning <a href="http://www.urbandictionary.com/define.php?term=banter">banter</a>, long discussions, quick questions, rolling laughter and even more on Sqwiggle. Of course, we consistently come across small and big bugs, performance issues, user experience problems and interface improvements. Being the ones discovering the majority of these things also lets us more easily prioritise the pain that they cause.</p>

<p>We recently got to the bottom of a memory leak in Sqwiggle that happened only in the rarest of circumstances, but when it did occur the browser crashed spectacularly leaving no debugging info behind! Had we not been using the app as much this issue may have gone unnoticed or deprioritised for a long time (in fact it had come up in support as a random &#8216;white screen&#8217;).</p>

<p>Great beta testers and users will let you know of major issues and when they can&#8217;t understand how to use or find a feature - but there are a myriad of small user interface interactions, improvements and ideas can only be found by exhaustively using your own product all day every day.</p>

<p class="caption">Photo by <a href="http://www.flickr.com/photos/85638163@N00/" target="_blank">Sh4rp_i</a></p>

Why Internal Dogfooding Matters So Much

<p><img src="http://media.tumblr.com/351b12b64f977c6be0c36d8cf5dbd128/tumblr_inline_ml6qg78QML1qz4rgp.jpg" alt="The Future"/></p>

<p>In February I left Buffer after working on every aspect of the app for over a year and a half (and documenting a lot of the interesting bits here along the way!). I&#8217;m immensely proud of everything that we achieved in that time, growing the service to half a million users and the company to 10 awesome team members whilst travelling! Buffer isn&#8217;t going away any time soon and I&#8217;m sure the companies future is very bright with Joel and Leo steering the ship - I can&#8217;t wait to see what they have in store.</p>

<p>So what now? I&#8217;m excited to say that I&#8217;m now building a new company to tackle the problems with remote working and distributed teams with a couple of awesome guys, <a href="https://twitter.com/mattboyd">Matt</a> and <a href="https://twitter.com/ericbieller">Eric</a>.</p>

<p>It&#8217;s a problem I&#8217;ve been thinking about ever since I stopped working in an office environment - how can you bring back the fun, spontaneity, and speed of communication of an office into the online world? It is a huge challenge, both technically and socially - we’re tackling the problem in a unique way and think we have a <a href="https://www.sqwiggle.com">pretty great solution brewing</a>&#8230;</p>

<p>If you have any thoughts on distributed teams then please go ahead and leave them in the comments, <strong>I&#8217;d love to hear any experiences or problems that you might be facing.</strong></p>

<p class="caption">Photo by <a href="http://www.flickr.com/photos/aloha75/4605051691/">Sam Howzit</a></p>

The Future


<p><img src="http://media.tumblr.com/0ab84f6875b76a556b82d89483f0c4be/tumblr_inline_mpnngpVOsL1qz4rgp.jpg" alt="What People Want" title="What Everybody Wants" /></p>

<p>This weeks <a href="http://startupedition.com">Startup Edition</a> prompt is &#8220;How do you discover what people really want?&#8221; - at first glance the answer to this question might seem obvious, you just ask, right?! But the way you ask and how you process the feedback can make the difference between a terrible product and a runaway success.</p>

<p>Here i&#8217;m thinking from the perspective of developing and improving an existing early-stage product after you have validated the idea. For me, it seems natural to split the process of soliciting feedback and deciding upon production direction into several steps.</p>

<h2>Ask</h2>

<p>First, is your company <em>really</em> open to receiving feedback? Including a contact link in the footer of your website is no longer enough - you should allow and encourage users to get in touch using whichever channel <em>they</em> prefer. For example at <a href="https://www.sqwiggle.com">Sqwiggle</a> we include a contact/feedback button in the main menu of all our apps. You can also simply reply to any email sent from the service to reach support (here&#8217;s a <a href="http://www.josscrowcroft.com/2011/random/death-to-the-noreply-mailbox/">great post on this</a> by Joss, Founder of <a href="https://openexchangerates.org/">OpenExchangeRates</a>). We also keep an active presence on <a href="http://twitter.com/sqwiggleinc">Twitter</a> and <a href="http://facebook.com/sqwiggleinc">Facebook</a>, making sure to reply to anyone that reaches out here too.</p>

<p>You&#8217;ll get the best results by combining and including a variety of channels. As well as email and social - how about blog comments, quora answers, discussion boards, phone calls, surveys and even face-to-face visits (a <a href="http://instagram.com/p/bPXADnP5NJ/">personal favorite</a> of the Sqwiggle team!).</p>

<h2>Listen</h2>

<p>In the early days your users will usually be very forthcoming with their thoughts and ideas, even their hopes and dreams for your product. Managing and keeping track of this can be hard, there are a few tricks that I use including:</p>

<ul><li>For smaller items and bug reports we find it easiest to simply add these directly into GitHub issues (or your issue tracker of choice!)</li>
<li>Tagging of emails so that we can find customers later and let them know when their idea has been addressed.</li>
<li>We use our <a href="http://blog.tommoor.com/2013/06/13/how-to-build-company-transparency-and-reduce-email/">internal discussion tool</a>, to talk about ideas and their potential implementation and priority.</li>
<li>One of the key ideas that I&#8217;ve embraced since my time at Buffer is from 37 Signals - <a href="https://37signals.com/svn/archives2/getting_real_forget_feature_requests.php">forget feature requests</a>, If a feature is really wanted by your users you won&#8217;t need to keep track as it it will be mentioned repeatedly! For example in our case, features such as screen sharing and file upload both fall under this category.</li>
</ul><h2>Observe</h2>

<p>Watching customers use your product can be one of the most painful, frustrating, eyeopening and ultimately useful experiences you will ever have as a software developer.</p>

<p>And finding people to observe is easier now than ever before, services such as <a href="http://www.usertesting.com">User Testing</a> let you perform tests at low cost and watch the resulting video back online. Alternatively you can place adverts on craigslist for testers and bring them into your office to record for a more directed/hands-on test.</p>

<h2>Distill</h2>

<p>I believe this is the most important yet also the most often missed step in the process. After all, nothing creates a poor product quicker than simply adding everything your users ask for! The great entrepreneurs of our time excel at the craftsmanship of distilling and filtering ideas down to their fundamental principles.</p>

<p>For example, Elon Musk regularly talks about his philosophy of reasoning from first principles rather than by analogy (check out <a href="http://foundation.bz/20/">this great interview</a> with Kevin Rose). The same principle applies with product feedback. Users will often make many assumptions with their suggested solutions, the key is to figure out the core problem and think from the ground up how to tackle it within the bounds of your product vision.</p>

<p>For example, with <a href="https://www.sqwiggle.com">Sqwiggle</a> we rethought video communication in this way - and realised that for our use-case the traditional &#8216;call and answer&#8217; model that other software uses just didn&#8217;t make sense.</p>

<p>In my mind these steps are a great start. It would be great to know your processes for finding out what your users <em>really</em> want - i&#8217;d love to know in the comments. You can also read <a href="http://bit.ly/15eDJRU">more posts on this topic</a> on Startup Edition!</p>

<p class="caption">Photo by <a href="https://secure.flickr.com/photos/gmacorig/">Giampaolo Macorig</a></p>

Ask, Listen, Observe, Distill


<p>Around a year ago during my time in Hong Kong I started working on a <a href="https://chrome.google.com/webstore/detail/hackernew/lgoghlndihpmbbgmbpjohilcphbfhddd">Chrome extension for Hacker News</a>. The aim of the extension was to make the site easier to use and add some (in my mind) much needed functionality.</p>

<p>Today i&#8217;ve released the <a href="https://chrome.google.com/webstore/detail/hackernew/lgoghlndihpmbbgmbpjohilcphbfhddd">latest version</a> of the extension which addresses many of the concerns from the previous versions both on HN and Github, here&#8217;s a little tour of all it has to offer:</p>

<h3>User Following</h3>

<p><img src="http://media.tumblr.com/5069b5a2d5880a0e6756e379f1044e8e/tumblr_inline_mjgzxqpef91qz4rgp.png" alt="Following on Hacker News" /></p>
<p>Hover over any username provides the option to &#8220;Follow&#8221; or &#8220;Unfollow&#8221; a user, followed users are highlighted wherever the appear, allowing you to pick out articles and comments from friends and thought leaders.</p>

<h3>Instant Inline Replies</h3>

<p>Previously replying to a comment meant opening a new page, inline replies mean you can type within the page and then submit when you&#8217;re finished. It also means that long replies won&#8217;t cause a timeout!</p>
<p><img src="http://media.tumblr.com/0f0b1592e6166c7a88d72016613860bb/tumblr_inline_mjh02pOV6h1qz4rgp.png" alt="Inline Replies on Hacker News"/></p>

<h3>Retina Support</h3>

<p>The extension replaces the existing image assets such as vote arrows and icons with higher resolution versions suitable for Retina displays. Thanks to Christian Genco for <a href="https://github.com/tommoor/HackerNew/issues/9">the idea</a>.</p>

<h3>Improved Readability</h3>

<p>Hacker New increases the size and colour contrast between links and surrounding elements. It also makes it clearer which articles you have already clicked on.</p>

<h3>Quick Profiles</h3>

<p>Hover over a username anywhere on the site to instantly see a users Karma and affiliated websites / social profiles. This is a useful indicator of how much respect they have gathered the HN community.</p>

<h3>Filters</h3>

<p><img src="http://media.tumblr.com/c36382794587eb52bc44d3d204d1936b/tumblr_inline_mjh072lHfi1qz4rgp.png" alt="Filtering on Hacker News" /></p>
<p>Filtering allows you to hide articles, users and domains from HN that you would rather not see. I have my filters setup to filter a variety of negative keywords and trashy domains!</p>

<h3>Endless Scrolling</h3>

<p>The frontpage just got longer, infinitely longer in fact. Endless scrolling kicks in before you reach the bottom so the news keeps flowing. The footer and search bar are always available by hovering near the bottom of the screen.</p>

<h3>Collapsible Threads</h3>

<p>If you just want to immediately skip past a thread, you can now collapse the entire thing on the right hand side and get directly to the next comment.</p>

<h3>Social sharing</h3>

<p>Social sharing buttons are built in for Twitter, Facebook, Google+, Buffer. Of course they don&#8217;t load until you request it so there is no extra bloat on page load times.</p>

<p><strong>I hope the extension improves your HN experience as much as it does mine. If you think something can be done better or would you prefer to tweak the styling go ahead and <a href="https://github.com/tommoor/hackernew">fork the project over on Github</a>!</strong></p>

Hacker New


<p><img src="http://media.tumblr.com/139ca3ea9898bb75609cf4728c0c5d7d/tumblr_inline_mjewl45jUa1qz4rgp.jpg" alt="Crowds"/></p>

<p>Something I hear often when talking to people and also find myself thinking occasionally is that there are only so many users that your startup can acquire… isn&#8217;t there a market limit? won&#8217;t they eventually stop signing up? If I release a feature too soon and some users drop off how will I ever win them back?</p>

<p>But the truth is, unless you have the most incredibly niche product (think time-tracking software for ostrich farmers with a penchant for gymnastics) there really are always so many potential users out there that by the time you get anywhere near saturating the market your product will likely be completely different!</p>

<p>Think of the biggest sites and apps you know like Facebook, Evernote and Twitter, they have millions (perhaps billions!) of users and yet still every single minute someone, somewhere that has never used the service before signs up for the first time.</p>

<p>Don&#8217;t be afraid to ship early, if the first impression isn&#8217;t perfect and users don&#8217;t sign up or quit your app then you can treat it as valuable learning, iterate and try again - <strong>there are always more users</strong>!</p>

<p class="caption">Photo by <a href="http://www.flickr.com/photos/jamescridland">James Cridland</a></p>

There Are Always More Users

<p>Recently I was talking to a friend about decision making, she was stuck in a paralysing situation with the knowledge that whatever option she chose it would likely become a major turning point in her life. Mulling over the possibilities for months, weighing the pros and the cons and trying out both options had only left her wracked with the thought that whichever decision she made would ultimately leave her regretting the lost opportunities of the other.</p>

<p>The thing is, seemingly innocuous and unrelated actions like where you sit on a bus or who you talk to at a party also have the same potential to completely change your life or the path of your business. Of course these dots can only ever be <a href="http://37signals.com/svn/posts/3234-connecting-the-dots-how-my-opinion-made-it-into-the-new-york-times-today">connected in hindsight</a> and we don&#8217;t worry ourselves over the hundreds of decisions we make every day.</p>

<p>It’s a problem that entrepreneurs and business owners face constantly, in fact you have to make so many different decisions that the real defining ones often get lost in the noise… Could that feature choice be costing you thousands of dollars a day or your last hire invent the killer feature that rockets your company to success?! All we can do is make the best decision possible with the information we have available at that moment.</p>

<p>So how do you make the best decision where everything else is even? Perhaps the answer is to minimize the <a href="http://en.wikipedia.org/wiki/Regret_(decision_theory)">possibility of regret</a>. Not by focusing on the negatives but by choosing the option with the greatest potential payoff and bet on your own ability to achieve it.</p>

<p>And the friend? She’s still deciding…</p>

Decisions, Decisions


<p><img src="http://media.tumblr.com/tumblr_mdng2iBWDb1qz7mjl.jpg" alt="Facebook Groups"/></p>

<p>So you&#8217;re building a new product or feature and want to gather feedback from your users&#8230; If you are building a startup this is probably a situation you have been in many times before and there are tons of ways you could go about doing this. An email list, forums or customer support software like <a href="https://getsatisfaction.com/">Get Satisfaction</a> / <a href="http://uservoice.com">UserVoice</a> are popular ways to gather feedback</p>

<p>At <a href="http://bufferapp.com">Buffer</a> we found ourselves wondering if there was a better way, where the whole team could have a proper conversation with users and gather feedback incredibly fast as we rolled out new features and changes every few days.</p>

<p>We decided to do something a little different and use <a href="https://www.facebook.com/about/groups/">Facebook groups</a>. We created a group for each of the three parts of our product that we are most actively working on (<a href="http://www.facebook.com/groups/buffer.web">Web</a>, <a href="http://www.facebook.com/groups/buffer.iphone">iOS</a>, <a href="http://www.facebook.com/groups/buffer.android">Android</a>) and invited anyone that wanted to join and help test the next versions of the apps in return for early access weeks or months before anyone else. Hundreds of people joined after just a few tweets on the company account - It&#8217;s hard to resist the lure of a beta test!</p>

<h2>The Benefits</h2>

<h3>Easy and personal</h3>

<p>At this point most people that are likely to want to test your product have a Facebook account and feel very comfortable with the interface and idea of groups. This means to get involved they only have to click one button with no extra sign in or learning curve.</p>

<h3>Notifications</h3>

<p>When you post an update to a group this usually shows up in members notifications and stream, it doesn&#8217;t clutter up their inbox but makes sure that members are always up to date with what&#8217;s going on. If the group isn&#8217;t secret (I would recommend a public group) then when people join their friends may also see this in the stream which spreads the word even further, maybe even introducing new people to your product.</p>
<p><img src="http://media.tumblr.com/tumblr_mdnhdg8Ex11qz7mjl.png" class="shadowed" alt="Group post in the stream"/></p>

<h3>Speed</h3>

<p>Facebook is quick, very quick - we&#8217;ve seen comments come in just minutes after a new release has been pushed to testers. Members often see the notification on the web or their mobile phone and check out changes immediately!</p>
<p><img src="http://media.tumblr.com/tumblr_mdniq4HJij1qz7mjl.png" class="shadowed" alt="Quick feedback"/></p>

<h3>Community</h3>

<p>But the best aspect has to be the sense of <em>community</em> that is created, group members chat, help each other out and like posts that they agree with. We&#8217;ve run polls, asked questions and given advice - the whole team jumps in to help people out and comment on bug reports and feature requests.</p>

<p>It&#8217;s great having everyone&#8217;s face and real name, there is an amazing feeling that we are getting to know our users better and i&#8217;m sure they feel the same way about talking directly to the team and seeing that they are directly influencing the product. I&#8217;m confident that those in the groups will become some of our most loyal and outspoken users.</p>
<p><img src="http://media.tumblr.com/tumblr_mdnhdzffTS1qz7mjl.png" class="shadowed" alt="Creating a community"/></p>

<h2>The Drawbacks</h2>

<p>Of course, after using groups for several months we have found some drawbacks. There will always be a couple of people that don&#8217;t have or want a Facebook account, even for a social startup like ours!</p>

<h3>Deploying features</h3>

<p>There is also some work in making sure that everyone in the group gets the new features, whether this is enabling them in our admin area, sending out builds or manually adding people to TestFlight. Perhaps in the future this is something we could automate using the Facebook API but at the moment when bug reports come in it can be difficult to know which build someone is using or what version of the website they are seeing.</p>

<h3>Over communicate</h3>

<p>Ordering of posts in the group is automated, meaning that old posts often get pulled up above newer posts.  Posts can be pinned so they stay at the top of the group but you definitely have to over-communicate and assume that previous posts may not have been read.</p>

<h2>Conclusion</h2>

<p>Overall in the last few months we have found Facebook groups to be an amazing way to connect with our most passionate users no matter where they are located. We&#8217;ve also collected some amazing feedback which has helped to shape the next version of Buffer with is launching very soon.</p>

<p><strong>If you don&#8217;t currently do anything like this at your startup - give it a try! Start a group, invite your most enthusiastic users to join in and leave a link in the comments :-)</strong></p>

An Amazing Way to Get Customer Feedback and Build a Community

<p><img src="http://media.tumblr.com/tumblr_m9990sD8nB1qz7mjl.jpg" alt="The Hurdle of Signup" title="The hurdle. It&#8217;s a metaphor!"/></p>

<h2>The Idea</h2>

<p>Like any startup, at <a href="http://bufferapp.com">Buffer</a> we are always looking for ways to reduce friction at every stage of using the product, from the moment you land on the homepage to the daily use of our browser extensions and web app.</p>

<p>One of the key points in the user lifecycle is getting people over the hurdle of signing up for your app, of course this should be as seamless as possible, particularly in the consumer internet space. In the last few years this has become easier than ever - with the advent of OAuth solutions such as Facebook Connect and Twitter Sign In users often no longer need to enter any details at all to sign up for your service.</p>

<p>This got us thinking could we completely remove the barrier of signing up all together? <strong>Could we make the account creation experience so easy that you might not even notice it had happened?</strong></p>

<h2>The Approach</h2>

<p>While there are some intricacies to handling a combined signup / signin on the server the first step is authorising the user with their social network of choice - and of course the UI is simpler than ever. We decided on a familiar &#8216;stack&#8217; of social networking buttons that can be consistently reproduced in all of the different sign in locations we have (web, browser extension, mobile).</p>

<p><img src="http://media.tumblr.com/tumblr_m99djgKIaH1qz7mjl.png" alt="Mobile sign in options"/></p>

<p class="caption">Our sign in screen, as seen on mobile.</p>

<p>On the web app the stack sits on the right hand side of our homepage and acts as a bright, strong call to action to. As more networks are added in the future we will likely add a &#8220;more options&#8221; button combined with a memory of the users last sign in choice which will always be displayed at the top of the stack.</p>

<p>Choosing the wording &#8216;Sign In&#8217; on the buttons rather than &#8216;connect&#8217; or other alternative wording hopefully gives the subtle impression that even new users already have an account and they just need to sign in to access it. The key is with &#8216;Sign In&#8217; you don&#8217;t expect to have to do any more work, which makes the hurdle smaller.</p>

<h2>Key Lessons</h2>

<h3>Users are often looking for the words &#8220;sign in&#8221;, &#8220;sign up&#8221; or &#8220;log in&#8221;</h3>

<p>Even (or perhaps especially) with a combined signup / sign in it is important to make it very clear that the user can do both actions with the same buttons. We included a friendly note on every entry point to get this message across</p>

<p><img src="http://media.tumblr.com/tumblr_m997xob0rW1qz7mjl.png" alt="Friendly Note"/></p>

<p class="caption">Let people know that they can do both actions in the same place.</p>

<h3>Many people forget which social network they used previously</h3>

<p>This is one of the biggest problems we had after rolling out the changes, many users were forgetting which social network they had used to login and were creating two, three and even more accounts. Obviously this is a terrible user experience and it can also completely skew your metrics.</p>

<p>We dealt with this situation in a couple of ways; by storing a separate long-life cookie whenever a user signs in we can check on signup if a user has been to Buffer before - we catch people that try to sign up with the cookie and display a screen like this:</p>

<p><img src="http://media.tumblr.com/tumblr_m997vegLV41qz7mjl.png" alt="Continue Screen"/></p>

<p class="caption">Detect and give users the option to sign in again.</p>

<p>Inevitably some users still fall through the cracks, perhaps because they clear their cookies or simply click on &#8216;create account&#8217; anyway. In these cases we need to let them merge their accounts together.</p>

<p>In Buffer we allow users to connect additional social media accounts on the dashboard, when the feature was first launched connecting an account already in the system would throw an error with a message to contact support - this would affect anyone who had accidentally created two accounts! As you can imagine, merging accounts quickly became one of our biggest support requests.</p>

<p>Thankfully we have now completely removed this friction point also, as authorising with the social network is proof of ownership connecting an account that is already in the database simply merges the two together, seamlessly in the background.</p>

<h3>What about their email?</h3>

<p>The disadvantage of users signing up with a social network is that you can&#8217;t always get their email address and other details that may be important for your business. At Buffer we use the email to send alerts if there are any problems or if your Buffer becomes empty as well as optional newsletters and lifecycle triggered retention emails.</p>

<p><img src="http://media.tumblr.com/tumblr_m99bkhb7bn1qz7mjl.png" alt="Email Banner"/></p>

<p class="caption">The passive email banner</p>

<p>Rather than immediately hassle the user after signing in with a social network (that kind of defeats the point, doesn&#8217;t it?) We opted to display a more passive banner at the top the dashboard which lets the user know <strong>the reason</strong> we would like to have their email address, this works well and only displays after a welcome tour which means the user is much more invested in the product than they would have been if asked on a signup page.</p>

<h2>Conclusion</h2>

<p>So, does it matter? I would say that with the right measures in place to catch and automatically repair duplicate accounts it doesn&#8217;t matter at all and in fact reducing complexity of the sign up process is well worth these measures.</p>

<p>It is now very rare that we get any of the support issues above and because the nature of Buffer is managing and connecting many social accounts we were probably more inclined to get these types of problems than many apps would be.</p>

<p><strong>Have you implemented social sign in differently or had interesting problems with it in the past? I&#8217;d love to hear your solutions and thoughts in the comments</strong></p>

<p class="caption">Photo by <a href="http://www.flickr.com/photos/nickuzma">nickuzma</a></p>

Sign Up or Sign In, Does it Even Matter?


<p>At <a href="http://bufferapp.com">Buffer</a> we are currently focused on driving growth to a new level, in the process we are trying many different channels to increase the number of visitors and signups including content marketing, web stores, mobile markets and more.</p>

<p>In the past week I decided to take a quick look at our homepage and how we might improve our conversion instead of driving more new visitors - after all, if we can improve the conversion whilst still increasing visitors it has a compound affect!</p>

<p>Previously we have not had much luck with A/B testing, it&#8217;s something we often do and have infact built an internal library called &#8216;Einstein&#8217; which makes it super easy for anyone on the team to deploy a <a href="http://www.startuplessonslearned.com/2008/09/one-line-split-test-or-how-to-ab-all.html">one-line split test</a> anywhere in the product. We have continuously been amazed at how seemingly large changes can actually make very little difference to conversion and activation, particularly in the early days of the product (more on this later).</p>

<h3>Examples of Some Failed A/B Tests</h3>

<h4>Homepage Tagline Changes</h4>

<p>This is an area we predicted would have a big effect, the thinking being that the main headline on the landing page would be a driving factor in whether people are interested in the value (and we all know not many users read further than the headline!).</p>

<p>In the early days <a href="http://joel.is">Joel</a> tested between several variations of text including &#8220;<strong>Be awesome on Twitter</strong>&#8221;, &#8220;<strong>Get 200% more clicks on Tweets</strong>" and "<strong>A Smarter Way to Share</strong>&#8221;. Unfortunately none of these variations had a significant impact on conversion.</p>

<h4>Colour of Call to Action</h4>

<p>After meeting <a href="http://twitter.com/tferriss">Tim Ferris</a>, he suggested that we try a higher contrast, orange call to action. At the time we had a single signup button that was a dark shade of green. The difference was similar to below (although unfortunately we don&#8217;t still have the exact screenshots).</p>

<p><img src="http://media.tumblr.com/tumblr_m81738uiAj1qz7mjl.png" alt="Changing colour and location of signup"/></p>

<p class="caption">The two variations used, with a bright central call to action.</p>

<h4>Positioning Changes</h4>

<p>We also tried moving the main call to action on the homepage to see if this would have any impact, flipping the page horizontally as well as trying a stark version with no introductory video and a large central signup button! The affect? Negligible.</p>

<h4>Interstitials vs Dropdowns</h4>

<p>We have also done split tests on internal product features and design variations, one in particular showed 50% of new users an interstitial to install our browser extension whilst the other 50% saw a drop down bar once they began using the product. The hope here was to increase the activity of new users by ensuring they installed the extension, but after running the test for several weeks the cohort analysis showed no discernable difference.</p>

<h3>The First Successful A/B Test</h3>

<p>In the past week we ran a new A/B test on the homepage that shows potential users more detail about <a href="http://bufferapp.com">Buffer</a>, in particular some of our most popular features run directly below the signup box (multiple accounts, analytics and team members). The hypothesis was that potential users are now discovering Buffer through more channels than just our content marketing efforts and a lot of people might not understand how much Buffer can offer when they first land on the page.</p>

<p><img src="http://media.tumblr.com/tumblr_m7vdo2A2ZQ1qz7mjl.png" alt="The two variations used"/></p>

<p class="caption">The two variations used, original on the left and the variation on the right.</p>

<p>We are now tracking all of the tests we perform with <a href="http://www.kissmetrics.com">Kissmetrics</a> which enables us to easily produce reports for our entire funnel, which currently looks like:</p>

<p><img src="http://media.tumblr.com/tumblr_m8180zPFEh1qz7mjl.png" alt="The conversion funnel"/></p>

<p>The results (and the trigger for this post!) seem to be for the first time both very positive and statistically significant although entirely unexpected. Every point in the funnel proved to be outperforming the original by multiple percentage points, but in particular upgrades were up a whopping 171%.</p>

<p>This outcome was totally unexpected and also shows the importance of tracking your split tests at a <a href="http://www.startuplessonslearned.com/2008/09/one-line-split-test-or-how-to-ab-all.html">macro level</a>, and not just whether there were &#8216;more clicks on the button&#8217;. In this case we would have seen that the increase in signups was statistically insignificant and could have even reverted back to the old layout!</p>

<h3>Conclusions</h3>

<h4>It Takes Many Tries</h4>

<p>A/B Testing is difficult! It could be easy to conclude from the many posts highlighting successful A/B tests that getting clear cut results is simple and you too can double your signups by changing the colour of a button but for us that wasn&#8217;t the case.</p>

<p>So far we&#8217;ve found that getting statistically significant results tends to take many iterations and much bigger changes than you might imagine, I don&#8217;t doubt we will need to perform many more tests to get another significant result of this type.</p>

<h4>Where Your Visitors Come From Makes a Difference</h4>

<p>Many of the unsuccessful tests listed above were performed in the first eight months of Buffer&#8217;s life, at this point in time our inbound traffic was much smaller and the traffic we did have often came from early adopters and detailed blog posts explaining how to use Buffer in great detail.</p>

<p>I am sure this will have had an affect on the results as a larger percentage of these users will have hit the homepage knowing what Buffer is and knowing they wanted to try it out. This may go someway to explaining why many of the tests in the early days displayed little variation at all.</p>

<p><strong>Have you had a run away split test success or perhaps you&#8217;ve tried hundreds of variations with no results - I&#8217;d love to hear your stories in the comments!</strong></p>

<h3>Resources</h3>

<ul><li><a href="http://www.kissmetrics.com">KISSmetrics</a> - Particularly tailored to enable easy tracking of SAAS metrics.</li>
<li><a href="http://getdatadriven.com/ab-significance-test">A/B Significance Test</a> - Handy tool to measure if your results are statistically significant.</li>
<li><a href="http://www.evanmiller.org/how-not-to-run-an-ab-test.html">How not to run an A/B test</a> - Why you shouldn&#8217;t peak at your results early.</li>
<li><a href="http://www.exp-platform.com/Pages/hippo.aspx">A Practical Guide to Controlled Experiments on the Web</a> - The techniques used for experiments at Amazon, Microsoft and NASA.</li>
</ul>

How We Increased Our Conversion to Paying Users by 171% 


<p><img src="http://media.tumblr.com/tumblr_m71l33t2qv1qz7mjl.jpg" alt="An alert deer" title="She&#8217;s alert, get it?" /></p>

<p>Recently I&#8217;ve come to realise what a critical role notifications and alerts can play in running an internet startup, enabling a small and scrappy team to stay on top of many things at once. By spending a small amount of time identifying and setting up alerts for key metrics you can give yourself a powerful weapon that can be used to minimise problems and wow customers.</p>

<p>At <a href="https://bufferapp.com">Buffer</a> we started with the very basics, using pingdom to send a text message if the website became unavailable - this works great for an MVP. Over the past year as the service has grown we have gradually built up and expanded the notifications to cover many more areas of the architecture and business to make sure we always know what is going on.</p>

<p>In my mind notifications are best split into two categories - active and passive. Active notifications are pushed through to email, sms or mobile apps and are used for emergencies or critical problems with the service. Passive notifications are displayed in our internal admin area, team chat or are sent in daily summary emails, these are things that we would ideally action but aren&#8217;t immediate emergencies.</p>

<p>The key notifications that we are using today include:</p>

<h3>Active Alerts</h3>

<h4>Macro business metrics</h4>

<p>With deploying code many times a day there is alway a chance that bugs will slip through unnoticed. It&#8217;s important that if this happens they are detected as fast as possible and don&#8217;t affect the things that really matter. We track the core metrics that are most important to our business every minute to ensure they are within preset acceptable bounds. Obviously these will be different for every business, for Buffer these are:</p>

<ul><li>Updates Sent</li>
<li>API requests</li>
<li>Signups</li>
<li>Upgrades</li>
</ul><p>If any one of these metrics steps outside of pre-defined bounds then we are immediately notified via push alerts and email, for example if for two consecutive minutes no updates are sent then there is clearly a problem somewhere in the chain that needs immediate attention.</p>

<h4>Brand sentiment</h4>

<p>Inspired by <a href="http://arstechnica.com/business/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering/1/">an interview with Chuck Rossi</a> of Facebook&#8217;s release engineering team we also track sentiment (currently only on Twitter) for people mentioning @<a href="http://twitter.com/bufferapp">bufferapp</a>. If there is a spike in negative tweets we are immediately notified that something may be wrong. This means we can jump into Twitter and both fix whatever the issue may be and also respond with very fast customer support when it&#8217;s needed most.</p>

<h4>Server status</h4>

<p>As an internet based business this is a bit of a no-brainer, but mentioned for the sake of completeness. We use <a href="http://www.serverdensity.com">Server Density</a> to perform minutely checks on all of our public facing services including the website, embeddable buttons and API. These are done in a round-robin fashion from multiple data centres around the world which means a more accurate average response time reading and ensures we are accessible from different regions of the internet.</p>

<h3>Passive Alerts</h3>

<h4>Upgrades and downgrades</h4>

<p>We display a list of the days upgrades and downgrades in the admin area which is visible to everyone on the team. We often reach out individually to users to thank them or in the case of a downgrade to try and trigger a discussion on why they left us and what we might have done differently to keep them..</p>

<h4>Influencer signups</h4>

<p>Obviously we would love to send a personal email to every new signup, but with this not being possible we thought it would still be nice to get in personal contact with influencers that signup for the service. At first this was an active notification, we setup the signup system so that <a href="https://twitter.com/joelgascoigne">Joel</a> would receive an individual email every time a user with a large number of followers signed up. This quickly became a burden and the emails we&#8217;re auto archived even after the trigger for an influencer was raised time and again.</p>

<p>In hindsight it is now obvious that this should have been a passive alert and in a similar fashion to upgrades we now display a list in the admin area of the days influencers and regularly get in contact with users to welcome them personally - this really helps to create the <a href="http://www.desk.com/blog/touchpoint-opportunity-customer-wow/">customer service wow factor</a>.</p>

<h4>Brand mentions</h4>

<p>Like many businesses and individuals we use <a href="http://www.google.com/alerts">Google Alerts</a> to inform us in a daily summary where Buffer is being talked about on the web. This lets us find posts that mention the service both in negative and positive ways. Often <a href="https://twitter.com/LeoWid">Leo</a> can jump into the comments to directly answer questions and provide support.</p>

<h4>Commits and deployments</h4>

<p>For the past few months we have used <a href="http://www.hipchat.com">HipChat</a> as the hub of day to day conversation at Buffer. In general HipChat has worked wonders at keeping the team motivated and upto date on what everyone else is working on. As part of this we push passive deployment and commit notifications into HipChat from Github, usually no action is required by anyone but this helps to keep the sense that other people are working and everything is always moving forward fast!</p>

<p>I hope some of these examples inspire you to think about how having more notifications and information at your disposal could give your startup an edge!</p>

<p><strong>What have I missed? Is there something you monitor at your business that has proved incredibly valuable? I&#8217;d love to hear how we might improve our approach or any aspects that we may be neglecting</strong></p>

<p>Image thanks to <a href="http://www.flickr.com/photos/rsteup/3876636138/">rsteup</a></p>

How to Use Notifications and Alerts to Give Your Startup an Edge


<p>Since I joined <a href="http://bufferapp.com">Buffer</a> in September last year we have seen awesome growth that has pushed both our hardware and mine and <a href="http://twitter.com/joelgascoigne">Joel</a>'s sys-admin skills to their limits. In this time we have grown from a single Linode VPS shared with Joel's previous startup to a heady total of 10 VPS's and in the last week we undertook the biggest jump so far, moving our infrastructure from this cluster to <a href="https://aws.amazon.com">Amazon Web Services</a>.</p>

<p>Our approach to scaling has always been based on necessity - with the <a href="http://www.startuplessonslearned.com/2008/09/lean-startup.html">Lean Startup</a> methodology ingrained into the company culture we push code fast and try to avoid prematurely scaling our infrastructure beyond it&#8217;s needs. This has definitely lead to some sleepless nights and the occasional hour of downtime but all in all we feel this approach is much better than over compensating from the beginning and building architecture that you may never need or use. These are a few of the key occasions when scaling became the only option&#8230;</p>

<h3>1 Server: Launch to 20,000 users</h3>

<p>The first version of Buffer was (<a href="http://blog.bufferapp.com/idea-to-paying-customers-in-7-weeks-how-we-did-it">perhaps famously</a>) the embodiment of an MVP, a single pricing page that gauged potential interest in the idea before anything was even built. This was hosted on a tiny Linode VPS, shared with several other projects. Once the idea was validated and for the next year Joel was able to scale Buffer to 20,000 users by increasing the size of the VPS and optimising SQL queries, this meant a few hours of downtime each time the server was resized but allowed costs and time investment to remain low while product market fit was reached, or in Joel&#8217;s words:</p>

<blockquote>
  <p>Focus on &#8220;scaling&#8221; too early and you may well forget to focus on &#8220;building something people want&#8221;. Don&#8217;t make that mistake.</p>
</blockquote>

<h3>2 Servers: Moving to MongoDB</h3>

<p>As I joined Buffer the first feature we decided to build was support for posting to Facebook - the main decision was how to change the code and database schema to accommodate more than just tweets. Over the course of several weeks the model layer was rewritten and the data migrated table by table from MySQL to collections in the document-based datastore <a href="http://mongodb.org">MongoDB</a>.</p>

<p>After the switchover, the new database was kept on the existing server, taking the place of MySQL. This worked well for around a month until early one Sunday morning Buffer suddenly disappeared from the internet. After tailing the error logs we quickly realised that we had reached an inherent limitation of MongoDB - 32-bit processes are limited to ~2gb of data and we had hit that limit.</p>

<p>We searched frantically for a way to get the database back in action on the existing hardware. After half an hour with no luck and <a href="http://twitter.com/leowid">Leo</a> calming distressed users on twitter we realised we had to get in touch with the best person we knew. We called <a href="http://twitter.com/elubow">Eric Lubow</a> from <a href="http://simplereach.com">SimpleReach</a> who put us on the right path in minutes - there was no other option but to accept the downtime and spin up another 64-bit server immediately. Thanks to clear, straight forward advice we got off very lightly with less than two hours of disruption in a quiet period as we setup a server, tarballed the existing data directory and shuttled it across!</p>

<h3>4 Servers: Background Processes</h3>

<p>By November 2011, Buffer had continued to grow to around 70,000 users and with 20,000 tweets per day being sent the website and browser extension were becoming noticeably slower at the peak time of the day (for us this is around 17:00 GMT, early evening in the UK and morning on the East Coast). At this point it was time to queue the sending tasks and have them processed by their own dedicated server. In hindsight this was the turning point where a Buffer &#8216;architecture&#8217; started to emerge, with modular pieces of code and servers that we&#8217;re independent of each other.</p>

<p>As soon as the core task of sending tweets was moved to queues it became obvious that a lot of other processing could be completed this way such as gathering link info, analytics and image processing. We went ahead and moved these tasks to two new utility servers, I&#8217;ll be covering the details behind how we now use queues extensively at Buffer in a future post.</p>

<h3>5 Servers: Upgrading MongoDB</h3>

<p>In December our database server was humming along nicely but quickly filling up it&#8217;s available RAM headroom and running on an out of date version of MongoDB. In order to upgrade the software and the server to more RAM (as we would end up doing several times of the next few months) we needed to be in a replica set configuration that would allow us to take the individual database servers out of circulation one by one to upgrade them.</p>

<p>This proved to be another rocky period with several hours of downtime, we found this was almost entirely caused by issues in the immature PHP drivers which have since been addressed but also partly down to our own lack of experience managing replica sets, firewalls and all of the intricacies of a multi-server setup.</p>

<h3>7 Servers: DiggDigg Acquisition</h3>

<p>In January of this year we hit the 100,000 user milestone and completed our acquisition of the popular WordPress plugin <a href="http://bufferapp.com/diggdigg">DiggDigg</a> which allows any WordPress user to quickly add a sharing bar to their blog or website. Part of the plan behind this move was to add the <a href="http://bufferapp.com/extras/button">Buffer Button</a> to DiggDigg and have it enabled by default for new installations, adding massively to the button&#8217;s reach and Buffer branding around the web.</p>

<p>In order to handle the millions of new button impressions and isolate the web interface from load generated by third party websites it was time to move the button to it&#8217;s own servers and introduce our first load balancer. It was also decided to use Nginx AND just for good measure re-write the entire button to become independent of the Buffer framework.</p>

<p>We definitely teetered on the edge of our seats after deploying all of this previously unused architecture at once, waiting for the load from DiggDigg to hit the servers. But everything went smoothly, the load balancer acted as expected and impressions gradually rose to new highs as people upgraded their plugin (it seems there is no sudden rush of traffic!). The button servers now handle around 4 million impressions per day and rising!</p>

<h3>9 Servers: Sleepless Nights</h3>

<p>Last month we reached 180,000 registered users and completed the acquisition of ShareFeed from <a href="http://www.kissmetrics.com">KISSmetrics</a>. Almost unbelievably, at this time the main website, API, blog and browser extension were all still running from a single Linode VPS (albeit one that had been upgraded on many occasions!). During peak times things we&#8217;re beginning to feel slow again and complaints started to appear on Twitter at predictable times.</p>

<p>Unfortunately late evening Hong Kong time (<a href="http://techcrunch.com/2011/12/20/sharing-scheduler-app-buffer-raises-400000-gets-kicked-out-of-us">where we are currently based</a>) is the peak time for traffic at Buffer. For almost a week I had incredibly restless sleep, I became acutely aware of every email received, waking up at the slightest sound convinced that the site would be down. It was definitely time to upgrade.</p>

<p>Thanks to all we had learnt creating the new environment for the Buttons several months before, we were able to make this move completely seamlessly. By setting up the load balancer, adding the new servers and testing thoroughly before moving the DNS we were able to ensure that the only thing users noticed was a performance increase.</p>

<h3>Thats Not All Folks</h3>

<p>It&#8217;s been an amazing ride so far with both highs and some serious lows, at one point working for nearly 30 hours straight just to keep the site online. We have learnt an incredible amount as a team in the last few months and I can&#8217;t think of any way we could have learnt more, faster.</p>

<p>Last week we migrated the whole of Buffer&#8217;s architecture to Amazon Web Services with less than two hours of scheduled downtime, making a number of huge changes and improvements in the process. I&#8217;ll cover some details of this migration in a future post.</p>

<p><strong>I&#8217;d love to hear any comments your have or similar stories of battling scaling woes as a small startup!</strong></p>

Scaling a Lean Startup, The Story So Far. 


<p>At <a href="http://bufferapp.com">Buffer</a> we try our best to be a data-driven startup, it can be hard work measuring, testing, correctly reading the data and then acting on these results - we definitely still have a lot to learn. Currently we use a combination of third party tools such as <a href="http://kissmetrics.com">Kissmetrics</a> and <a href="http://www.google.com/analytics">Google Analytics</a> as well as our own hand-rolled metrics for internal data.</p>

<p>The area where we are most happy with our approach is in measuring internal statistics, for example how many people used the latest Firefox extension last week, or how many API requests to which endpoints were there in the last 2 hours or which website with the Buffer widget provided the most signups last week?</p>

<p><strong>To make informed product decisions we need to easily access and visualise key business data in realtime.</strong></p>

<h3>Using MongoDB to measure realtime stats</h3>

<p>Our current tool of choice is <a href="http://www.mongodb.org">MongoDB</a>, using a combination of <a href="http://www.mongodb.org/display/DOCS/Atomic+Operations">atomic &#8216;inc&#8217; methods</a> and &#8216;unsafe&#8217; saves we can update key metrics in the database blindingly fast with a negligible affect on performance of the front end (as the driver doesn&#8217;t wait for save success before continuing).</p>

<p>By storing these statistics in minutely, weekly or hourly batches we can also limit data growth to a predictable rate and increase read speeds in the admin area.</p>

<pre>
<code class="javascript">
    db.clients_by_time.update({
        'hour': $hour,
        'client_id': $client_id
    }, {
        '$inc' =&gt; array(
            'requests' =&gt; 1,
            'statuses.'.$status_code =&gt; 1,
            'endpoints.'.$endpoint =&gt; 1,
            'response_time' =&gt; round($response_time)
        )
    }, true);
</code>
</pre>

<p>The code snippet above is inspired by <a href="http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics">this post</a> on the mongodb blog and is used to record the performance usage of Buffer API clients. It allows us to produce detailed graphs like the following in realtime and with upto the second data.</p>

<p><img src="http://media.tumblr.com/tumblr_m4qii3RgVa1qz7mjl.png" alt="Buffer API graph"/></p>

<p class="caption">A typical API client</p>

<p>Several individual values are incremented, one for the total requests as well as individual status codes and endpoints.</p>

<p>Sometimes tricks can be used to allow the use of incrementing values where you might not usually, for example in the above code &#8216;response_time&#8217; is incremented with the response time of each API request - the value becomes the sum total of all API requests in the hour. It is then easy to calculate the average when we return the document by dividing by the total requests. To store the average in the document itself would require an extra query for every request and this is well worth avoiding!</p>

<p><img src="http://media.tumblr.com/tumblr_m4rw5fQ6ad1qz7mjl.png" alt="Buffer extensions graph"/></p>

<p class="caption">Buffer update sources</p>

<h3>Where to go from here</h3>

<p>We believe that this approach scales exceptionally well and it has certainly done us proud so far.</p>

<p>As the dataset grows it is inevitable that we will want to automate weekly, monthly and eventually yearly rollups and with only 168 documents created per collection, per week for data recorded hourly this is a task that can be easily performed in code rather than requiring map reduce.</p>

<p>By far the biggest area for improvement is in our display of all the data we are gathering. At the moment this is largely using simple line graphs with raw values over time (we don&#8217;t even have a way to go back to previous weeks yet!). Some of the analytics would also be much better expressed as percentages of a total, stacked graphs or one of the many other types of charts.</p>

<p><strong>Have any thoughts on our approach? Have you tackled things differently in your company? I would love to hear them in the comments.</strong></p>

<h3>Further Reading</h3>

<ul><li><a href="http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics">Using MongoDB for Real-time Analytics</a> 
The original mongodb blog post that inspired this approach.</li>
<li><a href="http://www.slideshare.net/dacort/mongodb-realtime-data-collection-and-stats-generation">MongoDB Real-time Data Collection and Stats Generation</a></li>
<li><a href="http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps/">Fast, easy, realtime metrics using Redis bitmaps</a>
Not a method we are currently using, but a very interesting approach to the problem solved using redis bitmaps.</li>
</ul>

2021