Avatar of Tim Nolet

Tim Nolet

Founder, Engineer & Dishwasher at Checkly

Decision at ChecklyHQ about vuex, Knex.js, PostgreSQL, Amazon S3, AWS Lambda, Vue.js, hapi, Node.js, GitHub, Docker, Heroku

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

16 upvotes·26.6K views

Decision at ChecklyHQ about vuex, JavaScript, Vue.js

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

Vue.js JavaScript vuex

If you run a SaaS, you probably want to show your users when they are almost running out of widgets. Or that they can get some cool feature on a more expensive plan.

Or, in other words, how can you be nice and commercial in dealing with plan limits?

We use Vue.js with Vuex for our front end, but the patterns and code examples here can be applied to any other SPA framework.

We implemented some very specific data structures in Vuex to make it easy for components to check what a user's status is with regard to plan limits and usage. This centralizes and encapsulates the knowledge about typical SaaS things in one place and leverages Vue's component system nicely. Read more in the dedicated blog post.

13 upvotes·7.1K views

Decision at ChecklyHQ about Amazon DynamoDB, MongoDB, Node.js, Heroku, PostgreSQL

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

PostgreSQL Heroku Node.js MongoDB Amazon DynamoDB

When I started building Checkly, one of the first things on the agenda was how to actually structure our SaaS database model: think accounts, users, subscriptions etc. Weirdly, there is not a lot of information on this on the "blogopshere" (cringe...). After research and some false starts with MongoDB and Amazon DynamoDB we ended up with PostgreSQL and a schema consisting of just four tables that form the backbone of all generic "Saasy" stuff almost any B2B SaaS bumps into.

In a nutshell:cPostgreSQL Heroku Node.js MongoDB Amazon DynamoDB

When I started building Checkly, one of the first things on the agenda was how to actually structure our SaaS database model: think accounts, users, subscriptions etc. Weirdly, there is not a lot of information on this on the "blogopshere" (cringe...). After research and some false starts with MongoDB and Amazon DynamoDB we ended up with PostgreSQL and a schema consisting of just four tables that form the backbone of all generic "Saasy" stuff almost any B2B SaaS bumps into.

In a nutshell:

  • We use Postgres on Heroku.
  • We use a "one database, on schema" approach for partitioning customer data.
  • We use an accounts, memberships and users table to create a many-to-many relation between users and accounts.
  • We completely decouple prices, payments and the exact ingredients for a customer's plan.

All the details including a database schema diagram are in the linked blog post.

8 upvotes·41.5K views

Decision at ChecklyHQ about Slate, Swagger UI, Vue.js, hapi, Node.js, JavaScript

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

JavaScript Node.js hapi Vue.js Swagger UI Slate

Two weeks ago we released the public API for Checkly. We already had an API that was serving our frontend Vue.js app. We decided to create an new set of API endpoints and not reuse the already existing one. The blog post linked below details what parts we needed to refactor, what parts we added and how we handled generating API documentation. More specifically, the post dives into:

  • Refactoring the existing Hapi.js based API
  • API key based authentication
  • Refactoring models with Objection.js
  • Validating plan limits
  • Generating Swagger & Slate based documentation
7 upvotes·9.3K views

Decision at ChecklyHQ about Drift, MailChimp, GitHub, Hotjar

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

Hotjar GitHub MailChimp Drift

When I started Checkly, I had no clear strategy on collection, managing and acting on customer feedback.

Over the last year, going from private beta to the first couple dozen customers I found my way in the jungle of customer feedback tooling and found something that worked for me and my company.

The linked post is a bit less technical than normally. The post goes into:

  • Using Hotjar and how it sorta worked for me.
  • Using Drift and why I was totally wrong about chat widget.
  • Using GitHub as a public roadmap.
6 upvotes·3.2K views

Decision at ChecklyHQ about Vue.js, Stripe Billing, Stripe

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

Stripe Stripe Billing Vue.js

When I started building a SaaS from scratch, I adopted the Stripe Billing product for managing plans and subscriptions. At that moment (roughly a year ago) I did not fully realise that this was a new addition to the Stripe product line.

One year down the road, I can write this decision and support it with technical details on how I implemented Stripe Billing and integrated it with the Checkly backend.

Key takeaways are:

  • Keep coupling minimal. I hardcode our pricing and plans into the pricing page.

  • Choose good ID's and a good structure to segment product and pricing. This enables grandfathering customers and adding ad hoc new products.

  • Use one or two webhooks to keep things in sync. We use just one webhook.

See all details with code examples in the linked blog post.

5 upvotes·4.6K views

Decision at ChecklyHQ about PostgreSQL, hapi, JavaScript, Vue.js, Node.js

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

Node.js Vue.js JavaScript hapi PostgreSQL A pretty basic question for any SaaS is how you deal with what a user can do on their account in a SaaS app? Can Jane on the "Starter" plan create another widget when she is near the limit of her plan? What if she's a trial user?

When building Checkly, I found it pretty hard to find good, solid examples on how to implement this. Specifically for my stack of Vue.js and Node.js / hapi

Turns out this is a mix of things:

  • Feature toggling
  • Counting stuff™
  • Custom API middleware very specific to your situation

Read my post on how we did this and where the bottlenecks are. The HackerNews thread on this has some great contributions too.

5 upvotes·4.6K views