10
5 Comments

Custom Entity builder for SaaS apps, what do you think?

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.

Only 22% voted for Custom Entities

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

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

Extracting the limits logic

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

PlanLimit interface

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

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.

Custom Entity Builder

Plan Limits

Plan Limits for “Employees”

Instant API

“Employees” API

GET — /api/employees

Autogenerated Views

Table View

Autogenerated Forms

Create Form

Logs/Audit Trails

Logs/Audit Trails

Workflows and Webhooks

I’m still working on those 🛠️.


Let me know what‘s missing 😀!

posted to Icon for group Software as a Service
Software as a Service
on May 9, 2022
  1. 2

    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.

    1. 1

      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:

      • Authentication - Register, Login, Forgot password...
      • Pricing - Subscriptions, Payments...
      • User Settings - Name, Avatar, Preferences, Password...
      • Landing page
      • Admin portal (optional) - Users, Logs...

      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:

      • Entity Builder
      • Pricing Plan Builder
      • Set up email templates (welcome email, reset password email...)
      • Manage tenants/users (delete tenants/users, manually set subscriptions...)
      • Audit Trails (SaaS users' events, who did what, and when?)
      • Blog posts
      • API Keys' manager

      Get some SaaS pages (what your users would see):

      • dashboard
      • settings/profile
      • settings/members
      • settings/subscription

      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!

  2. 1

    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.

    1. 1

      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).

  3. 1

    This comment was deleted 2 years ago.

    1. 1

      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
      1-w

      5 days ago
      5-d

Trending on Indie Hackers
I shipped a productivity SaaS in 30 days as a solo dev — here's what AI actually changed (and what it didn't) User Avatar 183 comments Never hire an SEO Agency for your Saas Startup User Avatar 101 comments A simple way to keep AI automations from making bad decisions User Avatar 67 comments Are indie makers actually bad customers? User Avatar 36 comments We automated our business vetting with OpenClaw User Avatar 35 comments I sent 10 cold DMs about failed Stripe payments. Here's what actually happened. User Avatar 33 comments