There is a lot of dogma around shipping a product in startup land. Many founders follow strict patterns they got from a book or some influencer's tweet. "Ship Early" is one of the more stubborn ones, and in many cases it is exactly the right thing to do. The earlier you start learning about what your users' problems and how your product solves that, the better. I shipped Checkly fairly late.
Hello, Checkly community and Monitoring as Code (MaC) aficionados! We have some exhilarating news that we can't wait to share. Our mascot is sporting sunglasses today because Checkly has been named in Gartner®'s 2023 Cool Vendors in Monitoring and Observability: Where Awareness Meets Understanding report!
During the spring and summer of 2018 I was negotiating a possible acquihire of Checkly / moi with Datadog. I'm only writing about it right now because Datadog recently launched their Synthetics product — the product I would be involved with as some form of product manager. This post details how this all came to be, what steps we took in the process and some reflections on the whole thing.
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.
