HN Explorer

Show HN: A NextJS boilerplate to automate all the boring stuff (shipfa.st)

23 points by marclou ↗ HN
Hey HN,

I'm a solopreneur and I ship apps like a madman. 16 startups in the last 2 years.

I realized I was doing the same thing over and over: set up DNS records, connect DB, listen to Stripe webhooks...

So I built ShipFast for 2 reasons: 1. Save time and focus on what matters: building a business 2. Avoid headaches like emails ending in spam or waiting 3 days for Google to approve

I hope this boilerplate will be as helpful to you as it is for me. Would love your feedback pls

Marc

41 comments

[ 3.1 ms ] story [ 97.1 ms ] thread
audessuscest
It uses NextAuth that in my experience works well only on Vercel (and they don't care)

Also please stop using mongodb

jdthedisciple
> Also please stop using mongodb

Shouldn't be hard to replace with sqlite

alexlur
NextAuth also intentionally made username-password authentication difficult to use because they think signing in with your Twitter or Google account is better.

Meanwhile their home page advertises “own your data”.

wdb
yeah, and you cant have something like api keys
theogravity
Didn't know about this. I started a new personal project using NextAuth but without the username/pass features. Might have to reconsider since I may eventually add that back in.

If not NextAuth/Auth.js, then passport.js?

lessaligned
what other good recommendations do you have for auth?
needz
> Javascript or Typescript?

> Javascript :)

Pass

jmondi
Oof, choosing JS over TS was certainly a choice. Not one that I would have made…
quickthrower2
Arguable a reasonable choice to avoid tooling, but if you are going to use NextJS anyway… might as well choose TS
lessaligned
exactly, the build step is there anyway, so why not get "what you're paying for"
theogravity
Agreed. I refuse to work in a JS-only codebase. For small things, JS is fine, but for really large projects, TS is a must especially when you want to do large code refactors.
jdthedisciple
16 startups in 2 years?

Should I too turn every other weekend project into a startup?

Serious question.

re-thc
> Should I too turn every other weekend project into a startup?

They even have a term of it now apparently - Micro startups.

michaelmior
As someone who has been involved in a couple startups but not founded one myself, my first impression is that it depends. 16 startups in 2 years is impressive in some sense, but less so if none of them brought it any revenue (I have no idea what the case is with the OP).
marclou
if the weekend project has a buy button and a product, yes
bavell
Does that qualify as a startup? I'd call that a side project but to each their own.
scrollaway
(Not criticising your choices, they’re mostly reasonable and opinionated stacks are very useful.)

I’m curious if you can talk about why you went with mailgun, and especially why mongodb. Supabase is my backend of choice nowadays esp for b2b apps.

marclou
I've been using Mailgun for 6 years and never had any issue, so it pass my reliability filter.

Same for MongoDB. It's also free, scalable. For now I don't see a reason to migrate. Open to hear your thoughts :)

bavell
I used mailgun previously and was pretty happy with it. I'm using postmark now, forget exactly why I switched but I think it was because I can have one account with silo'd API keys for each app.
quickthrower2
Is Mongo better than it’s reputation of years ago? My main concern is it might be tricky to make secure. The other is foreign keys. I have used Firebase (also nosql) and that was a bit tricky in regards to when things need to be joined.
theogravity
As someone who have dealt with it in the past two years, no. If you want to do complex queries (aggregations), it's a huge pain in the ass to do, reason about, and also troubleshoot. Simple things in SQL like joins are more painful to reason about in mongo. Then there's these gotchas, like if you want to do a join using the $lookup operator, then you need to be aware that indices may not apply in certain situations.

On the driver side, the mongo node client has a really convoluted way of performing transactions that it is really easy to screw up where it looks like you're writing your transaction properly, but it actually doesn't get treated like one (did you remember to finalize the transaction session? did you make sure to pass the session handle to every single mongo callout you're making, etc)

If you want something like trigram searches, you'll have to pay for Mongo Atlas, their hosted mongo product; otherwise, you're stuck with a simple fulltext index.

phas0ruk
Lots of negative comments below which I think are overly critical. I think the stack looks good and I’ve also had no issues with mongo. Will take a look!
sickcodebruh
You might consider just releasing this as an open source repo. I’m sure your work is excellent but there is no way I would ever trust such foundational elements to a closed source boilerplate, especially coming from someone whose work I’ve never seen.
bavell
As a fellow solopreneur who builds a few apps a year, sorry but I'm not at all interested in something like this. Good luck though!

P.S. love your site designs and layouts. Taking notes!

multiplegeorges
And yet, likely still slower than a plain Ruby on Rails app.

This is not a troll, Rails remains one of the quickest, simplest, out-of-the-box ready solutions for a web app.

Every time I am tempted to try NextJS or the JS ecosystem in general, I immediately get frustrated by the fragmentation for what is settled and standard functionality. Typescript is what keeps tempting me, but Sorbet is helping with that.

I would absolutely love a Typescript on Rails.

sickcodebruh
I miss Rails deeply but when I tried using it earlier this year, I was struck by how limiting the templating system is compared to React. Components, unidirectional data flow, and years of thinking in Hooks made moving back to ERB feel like a step backwards. And that’s saying nothing of the TypeScript piece.

My dream is that we’ll see Rails with React Server Components support.

multiplegeorges
The ViewComponent (viewcomponent.org) project brings a lot of the benefits of components to Rails views. It makes data dependencies explicit, it makes them testable, and reusable.

Worth checking out, but it doesn't address unidirectional data flow and hooks, since those are not relevant in a Rails context.

Personally, having state on the server and updating html over the wire is far superior to managing client-side state.

lessaligned
Can you explain the choice of JS over TS?
marclou
Been using JS for 6+ years and never felt the need to upgrade, so I tried to keep the boilerplate minimal
lessaligned
Makes sense, is you're a 5+ years experienced JS dev.

But a more junior dev (or someone often switching languages between eg JS / Python / Go etc. all day who finds it hard to remember language details) would benefit a lot form the IDE suggestions and validations that can be offered with TS, and move faster at coding with all the extra help from autocomplete and stuff.

So your implicit tradeoff is to optimize for more senior developers. That's OK, but I'm not sure you intended that.

gitgud
> I hope this boilerplate will be as helpful to you as it is for me. Would love your feedback pls

It’s a commercial product, so you won’t get much feedback as not many HN readers will need/buy this.

Have you considered open-sourcing it?

rbadillap
People forget that this is a starter kit. I see complaints against JavaScript vs Typescript for large projects.

If you need to ship a web app in hours, I can guarantee that nobody will choose Typescript over a more flexible stack.

@marclou I follow you on Twitter and must say that you made a great decision selling your own tool, congrats for that!