We run deep research to fact check most things to avoid hallucinations.

I tried to have a conversational, story-telling style, maybe that's why you think there are lots of "AI-isms". But I take this as a feedback for the next editions: less fluff, more straight-to-the point writing. Thanks!

Thanks for the feedback, I really appreciate it. Rankbid and other projects I've made, I built from scratch myself. They have strong, solid, technical foundations. Try them for yourself, even try to hack them if you want if it proves my point.

This was not the case of Joe AI. I joined later in the project, and the foundations where even weaker than what is shown in this newsletter (no API endpoint authentication whatsoever, open bar, for example) and so I had to secure and migrate everything myself when I joined them. This was what the Supabase migration was trying to accomplish. Before I joined, they didn't even have a database but I won't get into the details here.

Before Rankbid, and the other products I've built, I've worked at a B2C startup with millions of users and never caused a big outage there, I've been programming for more than ten years, and I have a double degree in computer science, and while I agree with what "should be done" in theory for production level apps, sometimes, you need to move very fast to build great startups. I've read many technical books in my life such as Designing Data Intensive Applications, High Performance Browser Networking. I know the theory, but sometimes you just don't have the time to do everything perfectly. That's what I try to expose in this blog post. I also wanted to share a humbling experience. Everyone makes mistakes, and I'm not ashamed of making some, even after years of software engineering.

My newsletter is about the intersection of programming and business. You might not find the "business" part interesting which is fine, but I think what you call blogspam has real value for engineers who have never sold before in their life and want to learn the ropes. I spend a lot of time writing each edition, because I try to respect the time of my readers as much as possible to deliver some actual insights (even if there is a bit of fluff or story telling sometimes).

And for Joe AI: it has since become much more secure, and is progressively implementing engineering best practices, so customers don't have to worry.

When you are a 3 people startup, I'd argue there is no such thing as "business hours". I worked every day back then. I'll concede that the "Friday Night" part in the title might be a bit clickbait to that regard.

Why do you take the paid plan when getting started?

Once you’re at a point where some of your business depends on it, you probably want the things like backups they provide…

Definitely! I had just finished the migration back then so that's why we were still on the free plan, but we had planned on enabling even PITR

I use transactions all the time for my other projects and I've read the great Designing Data Intensive Applications which cover the topic of linearization in depth.

I agree. They also push you not to git migrations at first, which is definitely not the best practice.

(Supabase ceo)

We do not push devs not to do migrations - we would strongly prefer if everyone used migrations and declarative schemas.

Especially at the scale that OP is at (see maturity model: https://supabase.com/docs/guides/deployment/maturity-model)

While I don’t question the maturity model in itself (which I read after the incident and that’s why I started gitting migrations just after), I realized it was harder than other Supabase features for it to work well, especially when you start working with other features than just authentication and Postgres.

In particular, webhooks and triggers don’t work out of the box. So maybe it’s not pushing in a particular direction but at least I’d argue it’s not nudging you to do it because it entails some hours of custom setup and debugging before the CLI commands like supabase db diff actually work as intended in my experience. But I know the Supabase team is improving it every release so I’m thankful for this work!

It's hard to have 2 people available when you have a 2 people tech team. We were very early back then, MVP stage.

While I agree with everything said here about making backups etc. and which I have done in my career at later stage companies, when you are just starting out and building MVPs, I'd argue (as I do in the newsletter) that losing 2 weeks to setup CI/CDs pipelines and backups before you can pay the rent is a waste of time! I was a Supabase noob back then so I had not explored their features for local development, which is the learning I try to share in this post.

Thanks for your takeaway. Yes the dev environment is definitely a must as soon as you start growing!