This is a very broad question, but the most straightforward answer is to use a popular full stack framework like Ruby on Rails. It'll give you most of what you need out of the box, and there's 3rd party packages for the rest.
I really wouldn't suggest the Elixir + Phoenix stack to someone who doesn't have experience with the Elixir/Erlang ecosystem and functional programming
Your best bet would be to use something like Supabase, which simplifies all the backend stuff. Get deep into the docs and use Claude to figure stuff out.
When does the rugpull happen? I see using a third party auth as a suicide pact. What stops Supabase from sending out the usual email that "they're proud to have been acquired?"
You can actually self host Supabase, that's really the whole point: a Firebase alternative that you can host yourself. Obviously you can use their hosted service as well.
I wrote a "user management system" in PHP back in 2000 because I thought "user management" was dark matter for almost all web sites: you don't really want to write email verification, password reset forms and all that stuff but it's the kind of "non-functional" requirement which will leave your web site "non-functional" if you don't do it.
I used the software for a few projects for myself, customers and employers. It was open source, but the industry couldn't give a damn, turned out the missing feature was "depends on a third party auth service that is someday going to get acquired and shut down". Auth frameworks like that proliferated like mushrooms after the rain around 2013 and all of a sudden people were interested.
(Oddly back then I was looking at various "API management" products that a number of "want-to-have" features but that all lacked the one feature you needed to make a business, which was integration with a payment gateway.)
I think the basic advice in 2024 is the same as it was in 2000 which is store user records in a relational or document database, encrypt your passwords like an OS does, use signed cookies for authentication (ignore the anti-JWT splogs that a certain vendor funds), etc. I think today it would not be unreasonable to take a "microservice" kind of approach where auth is handled by some self-contained system through an API but practically you might want to be able to join stuff against your user table.
However, a lot of the complexity of a good auth system is tied up to the UX for both the visitors and administrators. I've seen onboarding completion rates increase from 22% to 85% as a result of improving each and every step. Administrators deserve a great interface for managing users. Even if a "microservice" had a good internal API so much of quality, security and all that depend on the UI the system exposes and I think that is just as important to reuse as the inner logic.
> I think today it would not be unreasonable to take a "microservice" kind of approach where auth is handled by some self-contained system through an API but practically you might want to be able to join stuff against your user table.
One option for writing less code yourself might be using something like Auth0 (cloud) or Keycloak (self-hosted) with some OpenID Connect library for your tech stack, or a Relying Party implementation altogether, like: https://github.com/OpenIDC/mod_auth_openidc
They'll get you most of the way there, without making you write a bunch of security related code yourself (which is also more likely to cause issues, if someone isn't familiar with the domain).
Which imho is one of the things that make web development nowadays obnoxiously difficult - there are tons of frameworks and stuff trying to reinvent the wheel. Keeping up to date with vanilla web development alone is pretty hard, I don't know how people can keep up doing React/Django/SQL/AWS/whatever. It's too much.
Part of a reasonable answer is that you do it with whatever toolset you’re familiar with. It’s also reasonable, if you used a signed cookie system that the cookie verification module is about 50 LoC so you could use an auth system written in (say) PHP to authenticate a node.js or .NET application.
In 2000 I had been watching Yahoo buy up lots of internet properties and… integrate them with their auth system. I had a vision that you could pick “best of breed” open source and other software, plug it into your auth system and make your own “portal” web site. I had some success developing sites this way but it never caught on and I still don’t understand why.
There's a niche service nowadays called "SaaS-as-a-Service" where an entire SaaS ready to use and customize is priced to you. I didn't use one myself but [1] is a good example.
This is the correct answer. If you're trying to validate a business idea and this kind of thing is not your core competency, just get an entry-level plan with a tool like this. I'd also highly recommend you sign up for a CRM tool like HubSpot to capture leads, send marketing emails and do landing pages. It does all that kind of stuff adequately well for a small business. WorkOS is another option although I've never used it and can't endorse.
It won’t use the newest framework of the month JS library in a few months, but that’s okay. Validating an idea quickly without much fuss by having a boiler plate done for you is key. Just move sooner rather than later to something you understand once you get to a stable point.
Supabase for registration and auth, frontend framework of your choice for views, Stripe payment links for subscriptions. You'll have to sprinkle in some Supabase Edge Functions for Stripe webhooks for your entitlements flow as well. AWS SES for transactional email. Something like Basedash for your admin panel and at this point you're running an MVP at least.
I use SaaSPegasus [1] to avoid reinventing all the typical features, integrations and boilerplate code. It's based on Django. One interesting additional component that I recently discovered is PinesUI [2].
I have a go monolith, htmx for dynamic pages, and SQLite to back it. I really tried to find something for user login / auth / forgot password, but ended up just implementing it myself. Way easier than figuring out APIs and such to integrate with my pages.
Yeah but then I have to figure out the pocketbase API and keep it as a dependency. I'd rather the dependency footprint be as small as possible, accepting the minor tradeoff of having to implement auth myself.
If you are a frontend engineer already maybe a JS based backend SaaS boilerplate project is the best starting point. Something that already comes with Stripe Checkout integration could get you up and running quickly (Like https://shipfa.st and probably others, maybe someone has more recommendations there).
Personally I'm using Ruby on Rails which has a lot of plugins to get up and running quickly with payments and user management. The equivalent there would be: https://jumpstartrails.com
Lots of good advice on here. It would help to add what development environments and languages you are comfortable with.
You say you don't know how to do all that, so you're probably looking for a "SaaS boilerplate" for a web framework you feel comfortable with. There are many good paid and free boilerplates available.
Yes, you can build all of this yourself, but it will take several months or years at the point you're at now.
I'm a bit ahead of you, but I'm going through this now and it turns out that understanding all of this "extraneous" stuff is taking way more time than it took to code up the core functionality (purpose of the app).
There are basically three parts to this question, all of which can be chosen independently and then fit together.
First you choose a frontend (and often backend) framework to actually build the pages, like Next.js, Svelte, Laravel, etc.
Then, you can choose an auth solution like Clerk, auth0, NextAuth, Supabase, etc. Most of these products work with a wide variety of frameworks. Some of the frameworks (like Laravel) also have an auth framework built in.
For payments, you technically have choices but I would just use stripe.
There's also the option of working with an agency or freelancer. Since you know about frontend and design, you might be able to work out something for a reasonable price.
For these types of projects (in a validation state) I recommend using Stripe subscriptions, they have incredible low code tools that will handle all the heavy stuff. You'll save a lot of time.
I recommend learning a full-stack back-end web framework that is known like Django, ASP .NET, Ruby on Rails, Laravel, to name a few.
There's lots of tutorials on how to get started with them, it will be a lot of information to start.
If you really want to learn about the core themes each of these has:
* User authentication - Login / Registration
* User authorization - Is this user allowed to do x, y or z?
* Database connectivity and query management (usually done via ORM) which handles where your data goes to, and comes from.
* Template engine (which you can replace if you rather an API, but I recommend for starting out, to just make a boring web app)
* User management
As for payment / subscriptions, these are not included OOTB, but if you can get through the basics of any of these frameworks, I don't think you'll struggle too much to work out third party libraries that add what you need to these frameworks.
I started out my first web project with a micro web framework, but I had some experience in programming in general and used it and it worked out, I started with CherryPy. Basic "Hello" page, and gradually added pieces as I needed to add them, like database, template engine and so on. I now just use Django or ASP .NET depending on what I'm doing.
Django is regarded as the framework for people with deadlines, but it might not be for you, maybe Rails or ASP are more for you.
My recommendation is pull up a list of web frameworks that meet most of your needs, and go from there.
You could also look into ecommerce frameworks as well. Though I cannot personally speak to these. Laravel I'm sure has a few options for Ecommerce. You might want to go with Laravel if you want to host with PHP.
Ruby on Rails, Pay Gem for Payments, Devise for Login/Registration (Auth), a StaticPages controller for Landing/Product pages.
I would then use the Litestack gem: https://github.com/oldmoe/litestack + SQLite to get your DB/Cache/Job Queue working, deploy with Kamal, behind Cloudflare on a $5 Hetzner VM.
I go from idea to live app in an afternoon with this stack. I haven't gotten around to it yet, but moving all my apps to essentially free analytics dashboard/visibility with https://github.com/benvinegar/counterscale, Free APM with ScoutAPM.
If anything is ever successful, scaling is super easy. Pay for a beefier Hetzner instance, and/or start to move your DB/Cache/Job Queue off of the litestack defaults with a single LOC. Move to AWS services because those are web scale or something.
I love this stack. It prioritizes getting shit done. Feel free to email me if you have questions.
Might take a look at AWS's Amplify framework which includes a bunch of free tier and libraries. Cognito is particularly useful for just getting user auth done.
I think the best advice is use something you are comfortable with. But the second best advice is hopefully that isn't WordPress. Yes, you can do it in WP, but you would have so many more options if you picked something like Angular or React as your frontend. Then outsource auth and payments (auth0 and Stripe, for example) and that will take you pretty far. Good luck!
Been building subscription and billing logic for at least 15 y.
Boilerplate code can help.. learning from others is important.
Have you checked both videos on youtube and source code on Github?
Like you have said this is more about how to think about it and break it down before any technology issue.
My reccomendation is starting with a clean sheet of paper and learning the concepts in this area, how they could connect to help shine a light in the right direction.
You are asking two questions, the first about the customer and their subscription, and then the difference between landing and product pages is another. They are related but separate. Some people like feature flags to help handle it, but it might not be needed at all.
This becomes a bottleneck for startups, because the billing and account logic can hinder shipping code and features. So thinking about it from the start even a little more can go a long way.
You have two options, build, or buy and in both cases it's important to understand how it all works. Some people may or may not want to grandfather features and plans, for example.
1) Done for you: SaaS boilerplate can be useful, but it's important to understand the depth of the billing integration.
2) Do it yourself: I also use a series of tables in any database schema that has worked well for me in most situations, you have the right idea. It is a reflection of the reading and learning I have done and combining it into one.
There is a basic approach that if done well can grow to handle more complexity, and if you don't care, it's easy enough to include a few more tables.
Using the concepts you listed above, you can put together a rough sentence of what could be entities / tables in a database. Some may merge together, or need support tables, having the core story is important first.
A [Customer] has a [Paid Subscription], to a [Plan (Subscription)], which grants them [Permissions] to login with an [Account] to see certain [Plan Features] on the [Product Pages].
This is a basic example for your case, but it will click if you catch a few youtube videos that work for you to learn. After you've watched a few, Happy to chat here or connect offline to walk through.
To me, this is one of the single most important things a SaaS / Startup can do, it bakes flexibility into the bread.
> A [Customer] has a [Paid Subscription], to a [Plan (Subscription)], which grants them [Permissions] to login with an [Account] to see certain [Plan Features] on the [Product Pages].
This is interesting. I'm thinking about how I would implement this, and I think I could do it, but I don't really have it clear in my mind. I'm going to have to make a project to practice this with since it does seem quite important to understand. Especially since I want to work in SaaS and eventually start my own micro SaaS. Thanks for your detailed comment.
Beware of buying some starter kit to do the job for you. You may end up spending more time massaging the starter kit to fit your use case vs. starting from scratch on your own.
You mention you work with frontend engineering and design, so I'll assume you will be more familiar with a Javascript stack.
Also, consider using LemonSqueezy instead of Stripe, read about what a "merchant of record" is and evaluate if you need it. It can save you a tax headache down the road.
React or Svelte - Building landing and product pages
These tools are extremely popular and well documented, so anything you get stuck on is bound to be readily searchable online. If you've already got over a decade of front-end work experience I'd say just spin up Sveltekit or NextJS and follow along with a guide like this one:
Probably the easiest would be starting off with Firebase for the overall backend and user management. Stripe for payments including recurring.
However, if the project will take off, then you'd be dealing with a dilemma: how to switch to something more mature friendly Like, say, Django or others.
I use Django as the main backend framework (sometimes for full stack).
This sounds like a build versus buy problem. The description strongly suggests buying.
You are trying to start a business. The cost of buying what you need can be reflected in the price. Your customers will pay for the cost of your store and get what they pay for.
Running a business will provide you ample other opportunities for you to pay the dumb tax. Good luck.
I recommend not listening to most of the suggestions here that say build out some stack -- that will be a distraction and a lot of time to spend before even getting your first customer. The most likely outcome of any startup/project is that it will get ignored and you won't have any customers, so don't spend a ton of effort building out custom user/payment stuff.
Since you already have a WordPress site, add WooCommerce (https://wordpress.org/plugins/woocommerce/). It's a general-purpose eCommerce solution and has product pages, user registration and login, accept payments, etc. The one bit it doesn't do out of the box is recurring monthly paid subscriptions, for which you'll need the WooCommerce Subscriptions add-on. If your thing takes off, either this will all be "good enough", or it'll make sense to build out something custom.
I am currently working on a serverless solution that covers everything you mentioned above and is a direct alternative and upgrade to WordPress.
It's built with full-stack Next.js, and the frontend is the backend, and the backend is the frontend; it's all the same. React server components have eliminated the need to separate the frontend from the backend into separate domains, and the frontend essentially securely talks directly to the database which eliminates extra network round trips and vulnerable backend API routes.
Built with Next.js, Postgres, TipTap, Tailwind, and Auth.js.
Compatible with Vercel, Neon, Supabase, Firebase, Cloudflare R2, etc.
What do you think? Is this a solution you might consider over your current WordPress domain?
The reason for creating this boilerplate is because I needed to have a starting point that include account / user / subscription / pricing / payment for a number of B2B and B2C saas initiatives.
It did allow me to spin fairly quickly Memories (a photo / video storage to share with family ) https://m.emori.es/
In addition, I used the same boilerplate to reskin an old saas of mine. It is not live yet, but you can see the new version here https://test.bankaccountchecker.com
mrhichem | 1 year, 4 months ago
kgdiem | 1 year, 4 months ago
gregoryjjb | 1 year, 4 months ago
djaouen | 1 year, 4 months ago
pcranaway | 1 year, 4 months ago
It is amazing though.
ansanabria | 1 year, 4 months ago
PaulHoule | 1 year, 4 months ago
tomComb | 1 year, 4 months ago
pcranaway | 1 year, 4 months ago
lpapez | 1 year, 4 months ago
Has most of the things you mentioned right away, and if you need payments Laravel Cashier makes it easy as well.
PaulHoule | 1 year, 4 months ago
I used the software for a few projects for myself, customers and employers. It was open source, but the industry couldn't give a damn, turned out the missing feature was "depends on a third party auth service that is someday going to get acquired and shut down". Auth frameworks like that proliferated like mushrooms after the rain around 2013 and all of a sudden people were interested.
(Oddly back then I was looking at various "API management" products that a number of "want-to-have" features but that all lacked the one feature you needed to make a business, which was integration with a payment gateway.)
I think the basic advice in 2024 is the same as it was in 2000 which is store user records in a relational or document database, encrypt your passwords like an OS does, use signed cookies for authentication (ignore the anti-JWT splogs that a certain vendor funds), etc. I think today it would not be unreasonable to take a "microservice" kind of approach where auth is handled by some self-contained system through an API but practically you might want to be able to join stuff against your user table.
However, a lot of the complexity of a good auth system is tied up to the UX for both the visitors and administrators. I've seen onboarding completion rates increase from 22% to 85% as a result of improving each and every step. Administrators deserve a great interface for managing users. Even if a "microservice" had a good internal API so much of quality, security and all that depend on the UI the system exposes and I think that is just as important to reuse as the inner logic.
KronisLV | 1 year, 4 months ago
One option for writing less code yourself might be using something like Auth0 (cloud) or Keycloak (self-hosted) with some OpenID Connect library for your tech stack, or a Relying Party implementation altogether, like: https://github.com/OpenIDC/mod_auth_openidc
They'll get you most of the way there, without making you write a bunch of security related code yourself (which is also more likely to cause issues, if someone isn't familiar with the domain).
yardstick | 1 year, 4 months ago
This should be hash not encrypt:
“Securely hash your passwords like an OS does”
I would recommend using something like bcrypt with strong parameters.
PaulHoule | 1 year, 4 months ago
qazxcvbnm | 1 year, 4 months ago
PaulHoule | 1 year, 4 months ago
WithinReason | 1 year, 4 months ago
Gualdrapo | 1 year, 4 months ago
PaulHoule | 1 year, 4 months ago
In 2000 I had been watching Yahoo buy up lots of internet properties and… integrate them with their auth system. I had a vision that you could pick “best of breed” open source and other software, plug it into your auth system and make your own “portal” web site. I had some success developing sites this way but it never caught on and I still don’t understand why.
hombre_fatal | 1 year, 4 months ago
christophilus | 1 year, 4 months ago
fernandopj | 1 year, 4 months ago
[1] https://saasbold.com
tootie | 1 year, 4 months ago
cosmotic | 1 year, 4 months ago
beezlewax | 1 year, 4 months ago
cr125rider | 1 year, 3 months ago
chrsstrm | 1 year, 4 months ago
j45 | 1 year, 4 months ago
tanelpoder | 1 year, 4 months ago
[1] https://www.saaspegasus.com
[2] https://devdojo.com/pines
koeng | 1 year, 4 months ago
chrsstrm | 1 year, 4 months ago
koeng | 1 year, 3 months ago
sidcool | 1 year, 4 months ago
dewey | 1 year, 4 months ago
Personally I'm using Ruby on Rails which has a lot of plugins to get up and running quickly with payments and user management. The equivalent there would be: https://jumpstartrails.com
runjake | 1 year, 4 months ago
You say you don't know how to do all that, so you're probably looking for a "SaaS boilerplate" for a web framework you feel comfortable with. There are many good paid and free boilerplates available.
Yes, you can build all of this yourself, but it will take several months or years at the point you're at now.
I'm a bit ahead of you, but I'm going through this now and it turns out that understanding all of this "extraneous" stuff is taking way more time than it took to code up the core functionality (purpose of the app).
eiiot | 1 year, 4 months ago
First you choose a frontend (and often backend) framework to actually build the pages, like Next.js, Svelte, Laravel, etc.
Then, you can choose an auth solution like Clerk, auth0, NextAuth, Supabase, etc. Most of these products work with a wide variety of frameworks. Some of the frameworks (like Laravel) also have an auth framework built in.
For payments, you technically have choices but I would just use stripe.
jvaqueiro | 1 year, 4 months ago
For these types of projects (in a validation state) I recommend using Stripe subscriptions, they have incredible low code tools that will handle all the heavy stuff. You'll save a lot of time.
Disclaimer. I run my own software studio.
jvaqueiro | 1 year, 4 months ago
It'd be usefull for your marketing pages, blog and product updates, but not so much for your application logic.
giancarlostoro | 1 year, 4 months ago
There's lots of tutorials on how to get started with them, it will be a lot of information to start.
If you really want to learn about the core themes each of these has:
* User authentication - Login / Registration
* User authorization - Is this user allowed to do x, y or z?
* Database connectivity and query management (usually done via ORM) which handles where your data goes to, and comes from.
* Template engine (which you can replace if you rather an API, but I recommend for starting out, to just make a boring web app)
* User management
As for payment / subscriptions, these are not included OOTB, but if you can get through the basics of any of these frameworks, I don't think you'll struggle too much to work out third party libraries that add what you need to these frameworks.
I started out my first web project with a micro web framework, but I had some experience in programming in general and used it and it worked out, I started with CherryPy. Basic "Hello" page, and gradually added pieces as I needed to add them, like database, template engine and so on. I now just use Django or ASP .NET depending on what I'm doing.
Django is regarded as the framework for people with deadlines, but it might not be for you, maybe Rails or ASP are more for you.
My recommendation is pull up a list of web frameworks that meet most of your needs, and go from there.
You could also look into ecommerce frameworks as well. Though I cannot personally speak to these. Laravel I'm sure has a few options for Ecommerce. You might want to go with Laravel if you want to host with PHP.
iceburgcrm | 1 year, 4 months ago
https://github.com/iceburgcrm/iceburgsaas
Here is the frontend: iceburgcrm.com
Based on Laravel/Breeze
Or you can use a starter kit https://github.com/thedevdojo/wave
akskakskaksk | 1 year, 4 months ago
dmje | 1 year, 4 months ago
hahahacorn | 1 year, 4 months ago
I would then use the Litestack gem: https://github.com/oldmoe/litestack + SQLite to get your DB/Cache/Job Queue working, deploy with Kamal, behind Cloudflare on a $5 Hetzner VM.
I go from idea to live app in an afternoon with this stack. I haven't gotten around to it yet, but moving all my apps to essentially free analytics dashboard/visibility with https://github.com/benvinegar/counterscale, Free APM with ScoutAPM.
If anything is ever successful, scaling is super easy. Pay for a beefier Hetzner instance, and/or start to move your DB/Cache/Job Queue off of the litestack defaults with a single LOC. Move to AWS services because those are web scale or something.
I love this stack. It prioritizes getting shit done. Feel free to email me if you have questions.
RangerScience | 1 year, 4 months ago
sudohackthenews | 1 year, 4 months ago
fragmede | 1 year, 4 months ago
issa | 1 year, 4 months ago
j45 | 1 year, 4 months ago
Boilerplate code can help.. learning from others is important.
Have you checked both videos on youtube and source code on Github?
Like you have said this is more about how to think about it and break it down before any technology issue.
My reccomendation is starting with a clean sheet of paper and learning the concepts in this area, how they could connect to help shine a light in the right direction.
You are asking two questions, the first about the customer and their subscription, and then the difference between landing and product pages is another. They are related but separate. Some people like feature flags to help handle it, but it might not be needed at all.
This becomes a bottleneck for startups, because the billing and account logic can hinder shipping code and features. So thinking about it from the start even a little more can go a long way.
You have two options, build, or buy and in both cases it's important to understand how it all works. Some people may or may not want to grandfather features and plans, for example.
1) Done for you: SaaS boilerplate can be useful, but it's important to understand the depth of the billing integration.
2) Do it yourself: I also use a series of tables in any database schema that has worked well for me in most situations, you have the right idea. It is a reflection of the reading and learning I have done and combining it into one.
There is a basic approach that if done well can grow to handle more complexity, and if you don't care, it's easy enough to include a few more tables.
Using the concepts you listed above, you can put together a rough sentence of what could be entities / tables in a database. Some may merge together, or need support tables, having the core story is important first.
A [Customer] has a [Paid Subscription], to a [Plan (Subscription)], which grants them [Permissions] to login with an [Account] to see certain [Plan Features] on the [Product Pages].
This is a basic example for your case, but it will click if you catch a few youtube videos that work for you to learn. After you've watched a few, Happy to chat here or connect offline to walk through.
To me, this is one of the single most important things a SaaS / Startup can do, it bakes flexibility into the bread.
hanifc | 1 year, 3 months ago
This is interesting. I'm thinking about how I would implement this, and I think I could do it, but I don't really have it clear in my mind. I'm going to have to make a project to practice this with since it does seem quite important to understand. Especially since I want to work in SaaS and eventually start my own micro SaaS. Thanks for your detailed comment.
sebnun | 1 year, 4 months ago
You mention you work with frontend engineering and design, so I'll assume you will be more familiar with a Javascript stack.
The easiest way to get started these days is to use Supabase + Nextjs, using a free template like https://vercel.com/templates/next.js/subscription-starter (this is a very lightweight starter, not like the commercial ones)
Also, consider using LemonSqueezy instead of Stripe, read about what a "merchant of record" is and evaluate if you need it. It can save you a tax headache down the road.
thekiptxt | 1 year, 3 months ago
Proziam | 1 year, 4 months ago
Supabase - User Auth & Database
Stripe - Subscriptions & Payments
React or Svelte - Building landing and product pages
These tools are extremely popular and well documented, so anything you get stuck on is bound to be readily searchable online. If you've already got over a decade of front-end work experience I'd say just spin up Sveltekit or NextJS and follow along with a guide like this one:
Supabase Auth - https://supabase.com/docs/guides/auth/server-side/sveltekit
gabriel_dev | 1 year, 4 months ago
bilater | 1 year, 4 months ago
brudgers | 1 year, 4 months ago
You are trying to start a business. The cost of buying what you need can be reflected in the price. Your customers will pay for the cost of your store and get what they pay for.
Running a business will provide you ample other opportunities for you to pay the dumb tax. Good luck.
claudiulodro | 1 year, 4 months ago
Since you already have a WordPress site, add WooCommerce (https://wordpress.org/plugins/woocommerce/). It's a general-purpose eCommerce solution and has product pages, user registration and login, accept payments, etc. The one bit it doesn't do out of the box is recurring monthly paid subscriptions, for which you'll need the WooCommerce Subscriptions add-on. If your thing takes off, either this will all be "good enough", or it'll make sense to build out something custom.
attendant3446 | 1 year, 3 months ago
hoofhearted | 1 year, 4 months ago
It's built with full-stack Next.js, and the frontend is the backend, and the backend is the frontend; it's all the same. React server components have eliminated the need to separate the frontend from the backend into separate domains, and the frontend essentially securely talks directly to the database which eliminates extra network round trips and vulnerable backend API routes.
Built with Next.js, Postgres, TipTap, Tailwind, and Auth.js.
Compatible with Vercel, Neon, Supabase, Firebase, Cloudflare R2, etc.
What do you think? Is this a solution you might consider over your current WordPress domain?
https://github.com/elegantframework/elegant-cli/tree/v4.x/pa...
jslakro | 1 year, 3 months ago
https://boilerplatelist.com/ https://boilermat.es/
smarri | 1 year, 3 months ago
m4jor101 | 1 year, 3 months ago
2-3-7-43-1807 | 1 year, 3 months ago
bhag2066 | 1 year, 3 months ago
ddgflorida | 1 year, 3 months ago
kylegawley | 1 year, 3 months ago
alain34 | 1 year, 3 months ago
There is a demo at https://boilerplate.aoware.co.uk
The reason for creating this boilerplate is because I needed to have a starting point that include account / user / subscription / pricing / payment for a number of B2B and B2C saas initiatives.
It did allow me to spin fairly quickly Memories (a photo / video storage to share with family ) https://m.emori.es/
In addition, I used the same boilerplate to reskin an old saas of mine. It is not live yet, but you can see the new version here https://test.bankaccountchecker.com
is_true | 1 year, 3 months ago
I'm interested mostly in managing access to some APIs we run that aren't in the same infra and different languages also.
Thanks.