Show HN: Nextless.js: Full-Stack React SaaS Boilerplate with Auth and Payment | Hacker News Reader

Show HN: Nextless.js: Full-Stack React SaaS Boilerplate with Auth and Payment

nextlessjs.com

80 pointscreativedg76 comments

I've thought a lot about this specific idea.

I think the problem with your business model is:

- People who have already built their company/website/product are not going to move the world to adopt your platform. It's just too much work.

- This leaves you with people who haven't built/shipped anything yet, who aren't really willing to pay $500-2000 for your software (there may be exceptions, but not thaaaat many).

I think a really successful business model would be something like:

- Free for the first $10k revenue

- 3% of revenue after that (auto calculated via Stripe)

This way, many more people will get started with your software, and those that are actually successful will end up paying you a lot more than $500. "We don't get paid till you do" is the headline on your pricing page.

I'd imagine your retention would be amazing because it'd be very difficult to move off (similar reasons as Stripe, AWS).

This could be interesting for agencies and freelancers more than the customers themselves.

I own a consultancy and I might find this interesting as I don't have an internal SaaS framework yet.

The two problems I see are:

1. Lack of options... There may be some parts of the stack that I don't like or don't fit requirements

2. Unknown code quality... Cannot tell what the coding standards are. This is related to #1 in that I don't know how hard the code will be to modify unless I read it.

Otherwise it's an interesting proposition. React/Nextjs are my jam, and I prefer serverful (Django) to serverless but that might be negotiable. But even if I wanted to drop in my own server, if the front-end is well coded I could easily save 2x-3x the 1.8k sticker price in dev costs on a single project.

If I were to build a SaaS myself, I might also find this interesting with all the caveats above, but I would 200% certain not pay a revenue share unless the platform really required minimal tweaking and was about 90% adjusted to my use case, and provided continued platform value after that launch (like, say, Shopify).

I mean I think a lot of people want to build a SaaS, but it's a lot of work. You need to build a landing site, set up pricing plans, integrate with Stripe, build user authentication, build company accounts + team invites, and that's just for an MVP, not including the product itself.

If you can get all of that for free (to start), and that saves you months of building, that's pretty worthwhile. At $1m ARR you're only spending $30k/yr on the platform, which is roughly what your AWS/Stripe bill is anyway.

There can definitely be more features too like user permissions, A/B testing, CMS, analytics/tag manager integration, etc, etc that continue to deliver value / save you time/money/effort as you grow.

It's hard to build alll those things you mentioned in a deep enough fashion to make it something people would use (Which is where I think this template lands). Entire companies are dedicated to each vertical.

These all things we wanted to tackle at Clerk (https://www.clerk.dev) as a SaaS. The first thing we hit down that path is user authentication -- and that opened up an entire can of worms we're still working through. User authentication alone has been tough enough because you can't just build yet another Auth0 clone and brand it "passwordless"... you'll have a tough time competing against the incumbents. This has led us to session management, which proved tricky to get right across local development and production environments, and has led is to the disparate ways people authenticate, which is a massive API design challenge. However, we think it could be a game changer, especially with all the Next.js / React advancements as of late. Especially the component-ization of the frontend in conjunction managed backends, session management feels like something that ties it all together.

I'm certainly excited for the next decade of developer tools :). Things will get dramatically easier with all these commoditized verticals.

Yeah it's definitely not a company you could bootstrap with 2 people. You'd need funding to build the team and product. But once you've actually built everything and gotten traction it'd be really hard for competitors to catch up because nobody is ever cancelling... Great VC business tbh

Yeah, don't tell me. We are two people and we are trying to do that, open source. I can confirm it's pretty hard :-). If you want to have a look, it's http://github.com/saasform/saasform

Thank you for your valuable feedbacks and sharing your thought. I totally agree with your approach for a general Saas project/product and frankly speaking, I prefer as well your business model because it can bring recurring revenue instead of one-time sales.

Here in terms of Nextless.js, as the customer will have access to the source code, the revenue sharing like 3% as you suggest is extremely hard to implement. It raises a lot of technical challenge...

Perhaps in the future, this concern can be addressed somehow and your proposed business model shall be implemented. Have you had such concerns/experiences for your projects? Pricing is not an easy subject though :)

I think that’s probably the right outlook, but how would you run their product through your stripe and take 3%? Wouldn’t that require the purchasers Stripe information to be a child of your Stripe account?

I think you integrate with their Stripe account (you have to anyway to set up billing/subscriptions anyway), and each month generate a report on how much they billed, then bill their credit card 3% of that. If they don't pay then their site/product shuts down (after a grace period obviously).

$2099 plus licence fees for each client? Good luck with that. I'm assuming the client licence fee is the Single licence at $699 but it's not specified.

There are good amount of rails starter templates that going around that price with similar set of features. I think there is demand for it. (not affiliated with it in any way)

Do they have additional licence fees for each client as this does?

they usually do the same model when it is X for one site/project and ~ 1.5x unlimited use

Yes, indeed, there are something similar in Rails and Django ecosystem.

All of them give access to: - Authentication

- Payment

- Dashboard UI

- Landing page

- Form management

- ...

I just made the same for Node.js/JavaScript/TypeScript ecosystem. Nextless.js also gives access to the same features in React and TypeScript. But, I also wanted to add more into the boilerplate, things that don't offer by others:

- Infrastructure as code

- Serverless for scalability and pay-as-you-go pricing with no server to manage, no docker, no kubernetes

You didn't address the licencing issue.

What's that, 3 days of a contractor? I don't think someone could make that in 3 days.

As a developer who is in the complete opposite side of how saas are developed (i.e., dependencies to a minimum, reproducible environments, boring and stable tech vs cutting edge tech, framework-agnostic core, etc.), can someone tell me: How do you maintain a saas developed with such a framework after a few years of pushing features to production? I can only imagine that using such an approach (i.e., Nextless.js approach) is enjoyable at the beginning (when there is no product at all and you need to build from scratch), but it will become terrible painful to work with after a few iterations dealing with so many dependencies that are core to your product.

It's quite enjoyable to develop in cutting-edge tech: React, Tailwind CSS, TypeScript, Serverless, VSCode, etc. You are now in component paradigm with typing and styled with utility class for the frontend. Fully build in static mode so no need to have a dynamic server to serve your frontend: better performance, secure, cheaper. You can also deploy at each commit to preview your front.

Thanks to cutting-edge tech, you can deploy your backend in one command and the same thing to provision your cloud infrastructure (also in one command). With Serverless, everything scale based on your traffic, you don't need to worry about over/under provision with little maintenance.

I was a web developer in 2010 and the developer experience wasn't the same. You need to rent a server, SSH to the server, install OS dependencies, install a firewall, install a webserver, install a database, log management, monitoring, etc. and still, I didn't talk about your application and business logic. Launching a SaaS in 2010 has been extremely painful.

It seems there are a lot of dependencies but every dependency is integrated into Nextless.js for a reason. It's just the bare minimum to build a high-quality SaaS product in 2021.

Nextless.js speeds up development for your SaaS with UI components, authentication, subscription, form management with developer experience in mind: type checking, linter, code formatter, editor configuration.

Not only Nextless.js will help you to build your SaaS, but it also takes care of your production environment by leveraging serverless.

On the contrary, using all these dependencies, remove a lot of burden from you and give you more time to focus on your business. No need to be an Ops engineer or UI/UX designer anymore for a small SaaS.

Still not convince? You aren't dealing with these dependencies directly, a lot of them work under the hood and Nextless.js are taking care of them. So, no need to worry about these dependencies yourself and Nextless will receive updates. You just need to focus on the things that make your SaaS unique and grow your business.

PS: Sorry for this long response ;) I started with one paragraph and make a short response. But, I end up with this huge text and I hope it responds to your questions.

I see similarities with Redwood[0]. Nextless.js is just added sugar, spice and rest of the boilerplates.

[0]: https://github.com/redwoodjs/redwood

Indeed, you can use Redwood or any other framework to build a SaaS. But, at the end, you need to set up:

- Authentication

- User dashboard

- Landing Page

- Pricing

- Form management

- Stripe integration

- Infrastructure as code

- Type checking, linter, code formatter

- VSCode

Nextless.js provides everything out-of-the-box for you to build a SaaS business and focus on the things that makes your SaaS unique. You shouldn't lose time on boring UI, setup and configuration.

Related, free template: https://github.com/vercel/nextjs-subscription-payments

Just use supabase + nextjs + stripe

They have a free example on their page, covers most of what this is offering

Looks cool, if a little pricey.

What's keeping me from using serverless for more general purpose SaaS is that there is absolutely no good answer for background jobs. Sure, you can plug in some external CRON service, use GitHub Actions, or maybe use something like quirrel.dev. But none of that comes close to "rails g job example" (or your favourite frameworks equivalent).

Good luck with your project, though!

Thank you for your support and message.

I've never tried it myself but there several option to build a background jobs in serverless mode: Amazon EventBridge and CloudWatch Events. You can check the documentation at https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/S...

So, no need to plug any external service.

I'm totally bias but I love Serverless, you can do everything. Background jobs shouldn't stop you using Serverless ;)

Your main competition is going to be Laravel. And they're a hell of a lot cheaper, better supported, bigger community ...

What's the strategy here?

it's not PHP

This is such a stupid, stupid argument. Anyone who makes this argument has clearly never written PHP or has some personal stake in the Node.js ecosystem.

I've written Node.js/Javascript/TypeScript for the past 5-years and my last few projects have been Laravel just because of how damn easy it is. I've used Next.js, Gatsby, [insert flavor of the month here], but nothing has stood the test of time like PHP has. I never had a PHP server die on me because of a lost network connection. I never had a PHP server kill thousands of connections because of one error. I never was 4 versions behind a framework because it changes every fucking week. PHP never had me deploy a Kubernetes cluster with seven thousand pods and monitoring systems just to stay alive.

Node.js is a horrible programming language with a worse package system and anyone who thinks otherwise hasn't had the privilege to work with something else.

The only person who seems to have personal stake on Laravel is you. No mainstream backend framework make you have your infra managed in k8s. There lots of reason to not use Laravel or PHP (or ruby on rails, or django, ...) in general. "It won't beat Laravel" , why? That's like saying to Django maintainers: give up what you are doing , because you will never beat Spring/Actix/.... Laravel might be useful for people who want to go the PHP route, but most people don't(save the wordpress sites fallacy). Also benchmarks put Laravel, and even Lumen in the bottom of the list (https://www.techempower.com/benchmarks/ ), I get the appeal of Laravel, and I have used it in the past. But is not like the only and must have solution for all problems. Edit: I wrote this before noticing you called NodeJS a "programming language". Well there is that, but my point remains.

I have no stake in Laravel. I just honestly think it's better than any Node.js framework you'll point at me.

You also seem to have a vendetta against me. You okay?

You are right, it is a stupid argument, but does answer "why?"

You think clients care?

I think if you're starting up today you may find easier to find someone who can build you a site with React than with PHP. Or if not today, then give it a few years.

Likewise I think someone starting up for themselves is more likely to be a React programmer than a PHP programmer.

I think it's hard to fine good PHP developers.

I also think it's damned near impossible to find React developers who are capable of doing anything that isn't React flavored.

For those reasons alone, I'd choose PHP over React, especially if I want to scale.

If the argument is that clients don't care (the comment I was replying to) then why would it matter to them that their develoeprs struggle with things that aren't React-flavored? Especially in 2021, when you can build just about anything on the web and stay within the React ecosystem.

Because real businesses that generate real revenue through software processes usually require more than tinker-toy websites built on a teetering pyramid of dependencies.

Couldn't agree more. The people who are against using PHP are those who never used it and think they are being clever and ahead-of-the-curve by bashing it.

Who said they were against PHP? I'm just said there are probably more React developers around these days than PHP ones, thus it's probably easier to hire from that pool.

Laravel is well-integrated with Vue.js as an option so you might want to look into that.

Oh, I know, I'm just poking at the "I know this thing so everything that we deal with must have a solution derived from this thing" crowd. The SAAS company I work for is about to start migrating away from the monolithic framework we have to a tiered services architecture, and we'll be using laravel because it meets our needs.

The CTO and security teams and devs will care. The language decision has a broad impact on how to secure the application, engineering community (who can you hire), etc. It’s a big decision.

So PHP should be the obvious choice then, considering what a bloated mess and security nightmare Node.js is.

As someone who ran a company for 5+ years on a Node.js stack, never again.

Before when I managed 5k+ servers running PHP, I actually slept at night knowing nothing was suddenly going to go wrong because of some stupid memory consumption bug or exploit in a popular and critical package.

Laravel and modern PHP are as secure as Rails or Django and arguably more secure than plain Node.js. Your point is at least 10 years out of date.

Clients may not care but the founder or development team may.

Not really, this is like a full-on boilerplate with multiple JS frameworks, templates and all while Laravel is really just a PHP web framework (from my understanding). If someone created a boilerplate SaaS product with Laravel, I think that would be more comparable.

Admin Panel[0] Subscriptions[1]

Anything you can think of, chances are there is not only a PHP package for it, but probably an out-of-the-box Laravel package.

Whatever this is, it won't beat Laravel.

[0] https://nova.laravel.com/ [1] https://laravel.com/docs/master/billing

What if you know JS or a front-end framework but not PHP (like a HUGE number of devs)? It's definitely a win then.

What if you know PHP (like a HUGE number of devs)? It's definitely a win for them.

I'm currently in the middle of building such a thing. It's nice to see that there are more efforts in that directon.

I'm do it more "on the side", the actual goal is an SaaS product.

Also, I'm looking more into non-AWS solutions right now. Cloudflare Workers, FaunaDB, Auth0, Paddle, etc.

Thank you for your support and extremely happy you are also building a SaaS.

Definitively, there are several ways to build a SaaS product and I also think Cloudflare Workers, FaunaDB, Auth0, Paddle, etc. is a good stack.

One good thing to use AWS, everything is centralized. Another good thing is you can use Infrastructure as code. As a developer, you can provision everything with code (TypeScript), no need to click and remember user interface.

That's right.

AWS brings more out-of-the-box.

But stand alone solutions are usually more polished.

Currently, I'm using Pulumi, which is like the AWS CDK, but for more than AWS.

I built some resource providers for unsupported services, and it worked like a charm.

This looks nice but you might want to read over the site for spelling issues.

My fault, I've already tried to fix the spelling issue, I've done my best. As you can see, English isn't my mother tongue :s

I'll seek the help from a native english speaker.

* Authentification -> Authentication

* Infrastucture -> Infrastructure

* Dasbhoard -> Dashboard

Thank you for your feedbacks, I've just fixed your suggestion and should be available on production.

This is a great idea that I wish I'd got stuck into doing when I thought of it :) Very nice.

You're not too late. Do it! You'll learn more along the way. You don't need to be first, you just need to be good.

Stripe offers self serve customer portals for managing subscriptions out of the box with their Billing offering, plus checkout pages, so it’s super quick to integrate Stripe into your own project now with minimal boilerplate.

As long as you don't have any international customers that would necessitate VAT support...

Currently, Stripe is addressing this issue. Couple months ago, they released Stripe Tax... I didn't have the chance to try it but it seems very promising and it's only the first version.

That's what I was thinking. For this to succeed, they'd have to differentiate themselves from Stripe's own offering and, at least to me, that's not obvious.

To clarify my own comment, clearly Stripe doesn't offer hosting, but I don't see that as the main offering here. Today, hosting a landing page is trivial and linking that to Stripe's portal is just as easy.

I do wish the project success and hope they're able to find their market.

How does this compare with https://blitzjs.com/ ?

Definitively, blitzjs is extremely good full-stack framework to build applications and there are a lot of things we can learn from them.

Nextless.js is different compared to blitzjs, here is the feature which aren't available in blitzjs:

- Payment integration

- Dashboard UI

- Landing Page

- Infrastructure as code

- Deploy in Serverless environment

Nextless.js focus on SaaS application and help you build your SaaS product faster.

Add hosting for one year to your offer and I'm in, otherwise I simply pick a free and open source starter from GitHub.

Can someone explain the advantages of using nextjs serverless?

Server-side rendering (SSR) is an ass-backwards attempt to recover what is lost when you go all-in on the SPA approach. SPA buggers-up SEO, navigation and history so what's the answer - duplicate the "page" on the server. Why not just render on the server to begin with and spice-up the front with JS as needed a la Phoenix Live View (Elixir), Laravel Livewire and Rails Hotwire?

Sorry to clarify... I understand the benefits of serverless, but what does nextjs add beyond just built in routing. Seems like most of it's benefits are part of the server

And the "server" is Lambda, I think?

I assumed it was using the "export" but that makes sense

All frontend is in "export" mode, made in static. So, no dynamic server needed to run the frontend, 100% compatible with any static hosting like Cloudflare page.

For the backend, it uses AWS lambda with API gateway and protected by AWS Cognito for private route.

But Next SSR should work on Lambda, right?

I know it possible but I've never tried it.

We can do similar with Webflow, or Bubble.

I'm not an expert about Webflow, or Bubble. But, if I'm not wrong, I don't think you can build a SaaS with these two nocode tools.

https://bubble.io/template/ultimate-saas-template-1603380654...

Check the review :)

Reply on news.ycombinator.com