The Plausible journal

The journey of building plausible.io

Read this first

How to store ‘last seen’ for users in Phoenix

This week, I worked on some under-the-hood improvements to Plausible to give me better insights into my userbase. One of these was to store a last_seen timestamp for all users. This is a private piece of data that I use to determine:

  • How many users are actively logging on and checking their analytics
  • What is the average usage frequency of Plausible?
  • When should I consider an account as ‘rotting’? Meaning I’m about to lose them as a user/customer

Let’s see how this can be achieved in Phoenix. First, we’ll start with the schema.

 Schema

We’ll need to generate a migration for the last_seen column:

$ mix ecto.gen.migration add_last_seen_to_users

and the migration itself:

defmodule Plausible.Repo.Migrations.AddLastSeenToUsers do
  use Ecto.Migration

  def change do
    alter table(:users) do
      add :last_seen, :naive_datetime, default: fragment("now()")
    end
  end
end

At...

Continue reading →


How I found my 10 first users

Last week I felt like I was ready to share the beta version of Plausible online. Contrary to all advice I didn’t build an audience before releasing my product. Instead, I did what many first-time indie founders do: build a product and hope that people will come. I now know that this is a mistake, and you should start marketing before you have an actual product.

But there I was, with a beta product and a landing page, thinking how am I going to find people to actually use this thing? Now it’s a week later and I have 10 users who have signed up, installed the javascript snippet and actually measured traffic using Plausible. It’s not a mind-blowing number but I’m happy with it. 10 is a lot better than 0. Here’s how I did it:

 1. Ask feedback

Screen Shot 2019-01-31 at 14.41.55.pngindiehackers.com

Screen Shot 2019-01-31 at 14.52.37.pngreddit.com/r/design_critiques

I genuinely wanted people to let me know how I could improve the site and I’m very thankful for the...

Continue reading →


Technology choices

In general I don’t think that the tech stack matters too much for software projects. Especially if you’re a solo maker, almost all of the risk is on the sales and marketing side as opposed to the tech side. The best approach is normally to just pick some boring tools and start solving your customers’ problems.

However I’m also very passionate about developer tooling and I thoroughly enjoy nerding out about programming languages and different databases. In this post I’ll go over the main technology choices I’ve had to make so far for Plausible.

 Elixir + Phoenix

I think most programmers have a default language or ecosystem they like and are used to. For me that would be Elixir. The first time I tried it was when I saw Dave Thomas speak about it in 2013. Since then I started the Elixir Koans project and used Elixir on a number of commercial projects.

It is a fantastic language designed...

Continue reading →


You probably don’t need a single-page application

The meteoric rise of front-end frameworks like React, Angular, Vue.js, Elm, etc. has made single-page applications ubiquitous on the web. For many developers, these have become part of their ‘default’ toolset. When they start a new project, they grab the tools they know already: a REST API on the backend, and a React/Angular/Vue/Elm frontend.

Is there something wrong with these tools? Absolutely not. In fact, I love working with them. However, I would only choose this architecture when an actual requirement is pushing me in that direction. If there are no specific reasons to build a single-page application, I will go with a traditional server-rendered architecture every day of the week. It is simpler and allows you to move faster:

  • Stateless requests
    Traditional web servers are built to be stateless. This means that each endpoint can be reasoned about and tested in isolation. SPAs, by...

Continue reading →


Learning design as a developer

Working on plausible.io I often find myself doing things I have no clue how to do. I struggle massively with marketing, copywriting, and most of all, UX/UI design. Here are some tips I’ve found helpful when trying to design for the web as an unimaginative developer who hasn’t designed a single thing in his life.

 1. Read Don’t make me think

This book basically lays out the common sense foundations for web design. It’s not a new book but it’s a classic for a reason. The principles laid out here are immediately applicable to anything you might be designing for the web.
Recommended for any developer who is looking to get into design.

 2. Copy designs you like

The secret to creativity is knowing how to hide your sources. Let’s say I need to add a pricing section to my landing page. I could stare at a blank canvas for a whole afternoon, waiting for creativity to hit me, or I can just...

Continue reading →


The analytics tool I want

While working on Gigride, our marketing head asked me to integrate Google Analytics for our landing page. My first thought was:

Ugh. Can we just use something other than Google Analytics?

Of course this turned into a half-hour discussion about the merits and problems with Google Analytics. There can be no doubt that GA is a powerful tool that has served countless web developers and marketers over a decade. Still, it manages to make hair stand up on the back of my neck every time I use it. My objections boiled down to the following points:

  • Complexity: I find GA overwhelming and difficult to learn. The UX could be a lot better, especially for new users.
  • Privacy: I don’t want Google, or anyone, to track my end users. Have you thought about why GA can be free to use? Because Google is happy to sell their analytics data to advertisers.
  • Accuracy: You kind of have to learn to ignore some...

Continue reading →