Over the last year or so, I experimented with different ways of getting customer feedback for Checkly. This post is about what worked for us and how I was totally wrong about chat widgets.

Two weeks ago we released the public API for Checkly. This post is about what parts we needed to refactor, what parts we added and how we handled generating API documentation.

This is a short follow up to last week's story on Stripe Billing as a reader on Hackernews commented that it seemed we didn't handle VAT. We do, but I just left it out of the story. For those not familiar with handling EU VAT for SaaS companies: It's a bit of counter intuitive jungle. At least that's what some dedicated SaaS startups make you believe. Also, Stripe does not handle it at all. They give you a { taxRate: null } field for you to fill.

When I started Checkly, all the typical SaaS things around billing, credit cards and prorating confused the hell out of me. I understood them from an intellectual point of view, but not really from an implementation point of view.

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. Last week we already looked at how we manage plans & features for Checkly. That write up was very back end focused, so this week I wanted to dive deeper into how we actually show this to our users in a friendly way.

How do 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?

This is a run down on the basic multi-tenant SaaS data model underlying Checkly. Users, accounts, plans, that type of stuff. When building this, I found it surprisingly hard to find any solid info in the gazillions of developer and startup blogs; most where just to vague on the implementation details.

We’re super happy to announce some big upgrades to Checkly’s alerting features for 2019 . We listened to what our customers were missing alerting wise and what parts we could polish and upgrade. Two things popped up again and again...

2018 was an interesting year for Node.js frameworks and open source software in general. Developer communities discussed the role of corporate sponsorship and how to maintain a project used by millions but not supported financially.

At Checkly, we run our browser checks on AWS EC2 instances managed by Terraform. When shipping a new version, we don’t want to interrupt our service, so we need zero downtime deployments. Hashicorp has their own write up on zero downtime upgrades, but it only introduces the Terraform configuration without any context, workflow or other details that are needed to actually make this work in real life™.