Luke Carr

At Moducate, for backend and systems engineering we typically use Rust or Go. So, it made perfect sense for us to use TypeScript over JavaScript for our frontend web development.

TypeScript's static typing provides a good level of protection against runtime errors (as any statically typed language does), and typings have drastically improved our codebase's readability by allowing us to write self-documenting code.

"Better IDE Support" is a benefit of TypeScript that is typically thrown around, but, admittedly, most IDEs (we use all things JetBrains!) now have excellent support for JavaScript as well.

Next.js, our web framework of choice, has out-of-the-box for TypeScript, which was a huge factor in our adoption decision.

We're using Prisma for our MongoDB ORM; its schema-first design principle offers a rapid development workflow by removing the need for us to create swathes of bulky boilerplate code. As for Prisma's full typed client, I'll refer back to my earlier paragraph on TypeScript's protection from runtime errors! 😊

Anurag's suggestion for AWS Lambda is great, but if you're not using AWS elsewhere in your stack, I personally think that a FaaS offering like Cloudflare Workers would be much easier to get started with. If you're not already using AWS, it can be quite time consuming for you to get set up, and in your scenario (only needing to schedule a function to run a few times a day), this time cost might not be suitable.

You can write Cloudflare Workers using JavaScript (so all good on that front), and they have functionality for Cron-based triggering (see https://developers.cloudflare.com/workers/platform/cron-triggers). As for Twilio, Cloudflare even has an official tutorial for creating a Cloudflare Workers function that sends SMS notifications via Twilio: https://developers.cloudflare.com/workers/tutorials/github-sms-notifications-using-twilio.

I'd lean towards GitHub (either billing plan) for one key reason that is often overlooked (we certainly did!).

If you're planning on creating OSS repositories under your start-up's name/brand, people will naturally expect to find the public repositories on GitHub. Not on GitLab, or Bitbucket, or a self-hosted Gitea, but on GitHub.

Personally, I find it simpler to have all of the repositories (public and private) under one organisation and on one platform, so for this reason, I think that GitHub is the best choice.

On the DevOps side, GitLab is far superior to GitHub (from my experience using both GitHub Enterprise and GitLab Ultimate), but for the one aforementioned, we're using GitHub at Moducate.

I'm going to sound like a sales rep for Retool in this Stack Decision, but who cares!

Retool has been simply amazing at allowing us to rapidly create backend administrative interfaces for our platforms and services.

We've gone from having a 50:50 split of time spent developing platforms and developing internal tools to a 95:5 split at least!

I've yet to find an API/database/service that Retool hasn't been able to natively interface with, and their support for arbitrary REST/GraphQL APIs means that I don't foresee myself ever finding a truly incompatible source of data.

And to top it all off, Retool's pricing plans are extremely generous considering how much time has been freed up for us.

It's genuinely frightening how easily, agilely, and affordably we've been able to integrate Retool into our various stacks.