What's the hardest / most annoying part about spinning up a new SaaS app?
I'm currently working on building a SaaS project template for .NET that tries to take care of a lot of the initial, tedious tasks involved in creating an app from scratch. Things like containerization, initial DB integration and entities, and payments / email integrations with third parties.
In the past I found the initial DB integration and entities to be one of the more tedious parts - getting EF Core set up correctly, making tests work with a live DB, and getting each entity <> table relationship operational often took days. So I built my project template to take care of that.
But I'm curious if there are other tasks people find really annoying in their own tech stacks. Could be an opportunity to fix =)
SaaS boilerplate for .NET -> https://labs.hamy.xyz/posts/build-dotnet-saas-app-in-minutes-cloudseed/
Finding customers.
Initial DB is fine.
Adding teams was a pain and big DB updates can be annoying as well.
Using https://supabase.com/ creates a secure API for you in minutes.
But they don't have much docs on teams.
Hmm, that's interesting, I thought they were going to be able to support teams. There are a couple of things that I know in the space which are much better at supporting "teams" and "orgs". Is that something that is worth sharing?
I really like the RLS postgres model. Just need more tutorials and examples with it.
I feel like that can be a good start, but it very quickly breaks down as soon as you need to do anything interesting. Also it definitely doesn't work when the permissions, roles, users are need in an ecosystem of microservices. Like a lot of things, you can start with it, but it will quickly become a bottleneck.
Why couldn't you use postgres as your service for checking permissions with microservices?
Most Indie hackers also don't have to worry about microservices.
Stick to the monorepo lol.
You would never want to expose that database directly to consumers, that violates microservices. And most of the interesting things come not from the vanilla database, but from out services interact with the permissions API.
It's also easy to start with microservices, tossing things into a monorepo => monolith service => mono database, is a great way to sink your startup and especially larger eng orgs. Microservices are critical to move quickly through pivots.
Same - RLS is great, but I'd like more complex and meaningful examples.
Very cool! Supabase looks like a great way to get a DB and API up quick.
I'm curious about costs of things. Looks like a lot of projects will end up in the Pro tier after a few recurring users. How've you found the cost ramp up?
Hi Hamilton,
As a .Net developer, I would be interested in checking this out. Biggest things for me would be a) how much I could generate the pieces I want without the pieces I don't want, i.e. no Docker, EF Core with SQL Server, etc; and b) how much time I save using, and then modifying, the boilerplate code generated versus the way I usually do things (for example, for my own project I would only create one or two projects, not 6 or so like a 'Clean Architecture' solution might. That's my two cents.
Yeah I think this is a great point around simplicity and customizability. There are existing solutions out there like ABP and ASPZero that provide a lot of functionality but I found them to be too heavyweight (lots of code and hard to parse) and different than my own coding style which led to net losses in dev time for me.
Something I'll need to think about.
The tedious things are going a little deeper (like 2FA for auth) while keeping everything well tested and clean.
Personally, I don't like to develop with Docker.
Why don't you like Docker?
I like Docker, but developing native or in a virtual machine (Vagrant) is more comfortable for me. It's just easier.
Curious - what do you do when it's time to deploy your project? Do you deploy with / without containers?
While I use containers when they make sense (and practically always at work), I usually deploy just a simple Rails app with PostgreSQL and Redis for myself, so I have a short script that sets things up.
Then I use git to git push new changes.
I like it because it's one less thing to worry about (Docker) and I skip a local build of a container.
I do what I describe in https://deploymentfromscratch.com/ (the book does include containers, too, so everyone choose what they want :)).
Every time I start a new project, I have to come up with a new landing page design, color scheme, content, routes, pricing components, etc.
I actually just recently started developing a product where developers can customize optimized pre-made React/VueJS templates.
Off topic: I think it's just a matter of time until no-code tools start affecting developers and that's where I see the future of no-code, especially if you are working with different clients every day.
Total agree here! I don't think that no-code will completely take over frontend/UI, but I think there's tons of growth for no/low-code tools that will help developers build faster!
I love frontend! But it can be tedious at times. Just like you, I built this headless forms tool to help devs build and render forms in their code.
Yeah I definitely feel this.
For frontend I've been gravitating towards NextJS and its ecosystem of extensions like MDX for content and Tailwind for styling and themes. I'm one of those people that would rather work on the backend stuff but you have to have UI to sell.
Figuring out what to build.
I tend to use Laravel as a framework for developing applications which makes it easy to create the database and model relationships.
Laravel Sail works great for local development environment and testing.
Laravel Forge and Laravel Envoyer for handling production infrastructure.
Laravel Spark for Stripe and Paddle integration.
The database?
This comment was deleted 2 years ago