ShipNext
Ship your product in a weekend
Hey everyone,
I'm an indie hacker. I quit my job a few months ago after around 6 years of professional software development experience, and started building my own products.
Since then, I've built a few apps, including CoffeeTrans, and also had 7+ projects that didn't really work out.
One thing kept showing up in almost every project: I was rebuilding the same boring but necessary SaaS infrastructure again and again.
Auth, payments, storage, emails, blog, docs, SEO, dashboard, user management, subscription logic, usage limits, notifications, captcha, customer support integration, and so on.
That is why I started building ShipNext.
It's a SaaS starter kit focused on helping indie hackers and developers ship production-ready apps faster, without spending the first few weeks wiring up the same foundation every time.
It includes:
PostgreSQL / SQLite / MySQL support
Auth with email, Google, GitHub, and magic link
Storage support for AWS S3, Cloudflare R2, Supabase Storage, etc.
Stripe, PayPal, Paddle, and LemonSqueezy integrations
Resend email integration
Built-in blog and docs
SEO-friendly structure
Theme system with many design variations such as shadcn and tweakn
Notification system for events like user signup, payment success, subscription changes, etc.
Discord, Slack, Telegram, and Feishu notifications
Cloudflare Turnstile, Google reCAPTCHA, and hCaptcha support
Crisp integration for customer support
Dashboard for billing, users, profile settings, newsletters, and basic admin operations
I know there are already a lot of SaaS boilerplates out there, so I tried to focus on a few areas that were painful for me personally.
Database support
ShipNext supports PostgreSQL, SQLite, and MySQL out of the box, with the schema already adapted for different database types.
For example:
PostgreSQL: Neon, Supabase, and other hosted PG providers
SQLite: Cloudflare D1, Turso, or local file
MySQL: any MySQL provider or self-hosted setup
Storage
Storage is usually treated as a simple upload feature, but in real products it gets more complicated very quickly.
ShipNext includes:
Per-user storage limits
Different storage quotas for different plans, for example 100MB for free users and 5GB for paid users
Multipart upload support
Expiration time support
Scheduled cleanup for expired files
A built-in
<S3Upload />component that works with multipart upload
Multiple implementations for common modules
A lot of templates leave placeholders for integrations, but you still have to implement most of the actual logic yourself.
ShipNext tries to include 2–3 working implementations for important modules.
For example:
Payments: Stripe, Paddle, LemonSqueezy
Captcha: Cloudflare Turnstile, hCaptcha, Google reCAPTCHA
Notifications: Discord, Slack, Telegram, Feishu
Storage: S3-compatible providers
The idea is that you can switch providers mainly through configuration instead of rewriting the whole module.
Entitlement and usage model
This was one of the biggest pain points for me.
Most SaaS products are not just “paid or not paid”. You often need to support things like subscription credits, one-time credit packs, unlimited usage during a billing period, storage limits, and different priority rules when consuming credits.
ShipNext has a built-in entitlement model that supports:
Subscription + unlimited usage For example, unlimited downloads during an active subscription.
Subscription + usage quota For example, an AI product with 500 credits per month.
One-time purchase + usage quota For example, a $10 credit pack with 100 credits.
Subscription + extra credit packs For example, users get monthly subscription credits, but can also buy additional credits when they run out.
The goal is to cover the common SaaS pricing models without forcing you to redesign billing and usage logic from scratch.
I'm also including a 1:1 consultation call and access to a Discord channel for people who buy the kit. I can help with things like MVP planning, database design, billing models, or general product architecture.
You can check it out here: https://shipnext.pro
Happy to answer questions or hear feedback from other builders.
6 Comments
The difficult part usually begins after the basic payment integration is working. Monthly credits, add-on packs, storage limits, plan changes, and credit consumption order can turn into a lot of edge cases very quickly.
How are you handling upgrades and downgrades when a user already has unused subscription credits or separately purchased credits? That seems like one of the areas where founders could save a lot of development and testing time.
Interesting build.
The thing I'd be careful with is that once a product gets broad enough, the biggest risk is not usually the missing feature.
It's a decision that sits underneath the feature list.
That decision tends to affect far more than most founders expect.
I wouldn't make that call casually in a thread.
Thanks for the feedback. That's definitely something I've thought about.
My goal isn't to build a giant feature bundle. Instead, the template is designed around independent modules with a consistent abstraction layer. Most modules have very little coupling, so features can be removed entirely or implementations can be swapped without forcing changes across the codebase.
I agree that architectural decisions matter more than individual features. In fact, modularity and replaceability are the core decisions I'm optimizing for here.
Makes sense.
The reason I stopped short is that I'm not talking about the architecture itself.
I'd rather not unpack the underlying decision casually in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.
Rebuilding billing, auth, and usage tracking across multiple projects gets old fast, especially when pricing models start evolving after launch.
One thing many founders discover later is that changing entitlement logic is often harder than swapping payment providers.
Have buyers been using it more for brand-new products or migrating existing apps?
best for brand-new products, because the table is different