I posted a poll on LinkedIn about “Typed-interfaces vs Custom Entities” and it would seem that custom entities are a bad choice. But let me explain why I think it’s in your best interest to implement them.

Every SaaS has plan limits, let’s say your application is an employee management system. Your /pricing page would look like this:
The standard way of implementing this is to have your PricingPlan object track the “Employee” limits:

It might seem easy, but imagine down the road you need to track another entity EmployeePayments, and for the sake of the argument, you want to let your Basic plan members make up to 10 payments and Pro plan members up to 20 payments PER MONTH.
Plan limits just became more difficult:

Let’s fix this by adding another interface/DB-model PlanLimit:

Look at line #9, we had to define our entity anyway!!
Now, why should we define our entity properties if we already have done that on the Database/ORM layer?

The reason is:
If we were to build our application manually, we’d need to implement all these features for EVERY new entity, or worse, start over when creating a new SaaS.
That’s why I’m building this Entity Builder on my Remix SaaS kit.







I’m still working on those 🛠️.
Let me know what‘s missing 😀!
What are the instances that it makes sense for someone to start with a boilerplate vs. building a site themselves?
Is the idea that this boilerplate gives you the basics, and then you can work with whatever API you want to display the data you want (or you could build your own API too I suppose as well). I haven't used a boilerplate before, but I'm intrigued by the option because it seems it could speed up development, and let me focus more on reading API docs and figuring out what data I want to show users ect.
I guess that every dev that has made a SaaS boilerplate has the same origin story: Someone that wanted to start a SaaS but needed to implement some core things first:
It's ok to start from scratch, but if there's already some code that you can use for "XYZ", you would save weeks... or even months.
My vision with my Remix SaaS boilerplate is to make SaaS development as easy as possible, meaning 2 things:
1) Low code
Set your app from /admin portal:
Get some SaaS pages (what your users would see):
2) Highly customizable
For example: When you created a custom entity (eg: invoice), you did not like the default /app/invoices table? Override it with code, but keep all its benefits: permission manager, instant API Key, workflows, webhooks, dynamic properties (like Asana custom fields or Notion custom properties, and more...
Not to mention that all these mean that there are a ton of UI components that you can reuse: Inputs (Text, Number, Selectors, Dropdowns...), Buttons, Page layouts (List, New, Edit), Modals, Tables, and more.
I'm happy to clarify or answer more questions!
This is dope! :) Like how it saves time and money for devs. By far it's also the most expensive Gumroad product I've seen ahah!) Can help you get first 20 sales, let's connect on Twitter.
Yeah! I want to make the best boilerplate out there, and I’m starting to realize that this Entity Builder is a no-code feature.
Yeah it’s expensive and it will be more expensive! I want to price it like usegrativy, abp.io and other multi-tenant SaaS boilerplates, but only when I get to v1.0 (currently v0.2.5).
This comment was deleted 2 years ago.
Yeah, I believe that I wrote this tired. I'm not proud of it, but it would've haunted me the whole week if I didn't post it then. I agree that is sloppy writing, I just wanted to give a follow up on these two polls about why I did it anyway:
1 week ago

5 days ago
