Creating a SaaS Entity Builder
Tags: saas, boilerplate, remix, tailwindcss
Published: 2022-05-09 21:47:50

---
title: Creating a SaaS Entity Builder
published: true
description: From custom properties to auto-generated API, Views, Forms, and everything an Entity might need.
tags: saas,boilerplate,remix,tailwindcss
cover_image: https://yahooder.sirv.com/blog/creating-a-saas-entity-builder/cover.png
---

## Why Custom Entities?

I posted [a poll on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:6928108178219970560?utm_source=linkedin_share&utm_medium=member_desktop_web) 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.

![Only 22% voted for Custom Entities
](https://miro.medium.com/max/1400/1*XoL5BKFqCm-JB18bzD7jug.png)

### 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:

![Employees per month](https://miro.medium.com/max/1400/1*9ohqKH9MnVO3siwiyNDT8Q.png)

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:

![max payments or payments per month
](https://miro.medium.com/max/1400/1*KjTRzxLlsYoNoMMdMWrwmw.png)

### Extracting the limits logic

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

![PlanLimit interface
](https://miro.medium.com/max/1400/1*Vxs42DsGKMoN0ko5rDPa2Q.png)

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?

![Employee database model
](https://miro.medium.com/max/1400/1*MGiibLCV2-AOhMG69aHVpg.png)

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](https://alexandromg.gumroad.com/l/SaasFrontends-Remix).

![Custom Entity Builder](https://miro.medium.com/max/1400/1*dBzDgciMapcRR0MutI1OJg.png)

### Plan Limits

![Plan Limits for “Employees”
](https://miro.medium.com/max/1400/1*DPz9vXxIyxR5UX9IQlKAvw.png)

### Instant API

![“Employees” API
](https://miro.medium.com/max/1400/1*1JRPDAF17JaST85DVL48IQ.png)

![GET — /api/employees
](https://miro.medium.com/max/1400/1*qT02r8XFHYePSP4YwpnaGw.png)

### Autogenerated Views

![Table View](https://miro.medium.com/max/1400/1*AeMTNDNeZJWsM-4bls40gg.png)

### Autogenerated Forms

![Create Form](https://miro.medium.com/max/1400/1*LxSH6A9OZwrJwV2KWTbYSA.png)

### Logs/Audit Trails

![Logs/Audit Trails](https://miro.medium.com/max/1400/1*W5tUlQ61UO4XFgzfythdqw.png)

### Workflows and Webhooks

I’m still working on those 🛠️.

---

Let me know what‘s missing 😀!