Creating a SaaS Entity Builder
From custom properties to auto-generated API, Views, Forms, and everything an Entity might need
Why Custom Entities?
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.
Easier to track = easier to limit
Every SaaS has plan limits, let’s say your application is an employee management system. Your /pricing page would look like this:
- Basic plan - 10 employees/month
- Pro plan - 30 employees/month
- Enterprise plan - 100 employees/month
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:
Extracting the limits logic
Let’s fix this by adding another interface/DB-model “PlanLimit”:
Look at line #9, we had to define our entity anyway!!
Custom Entity Advantages
Now, why should we define our entity properties if we already have done that on the Database/ORM layer?
The reason is:
- Plan Limits
- Instant API
- Autogenerated Views
- Autogenerated Forms
- Logs/Audit Trails
- Workflows
- Webhooks
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.
Plan Limits
Instant API
Autogenerated Views
Autogenerated Forms
Logs/Audit Trails
Workflows and Webhooks
I’m still working on those. Follow me to get notified when I publish the full Custom Entity features.
Let me know what‘s missing 😀!
