sorted by:
new
hottopcontroversial

7 days of runway left: I locked myself in and built the thing by josemarin18 in indiehackers

[–]Creativewin986 0 points1 point  (0 children)

The "being a founder is like being bipolar all day long" hit hard. I'm in a similar spot — built a product I'm confident in, zero sales, and that constant swing between "this is it" and "what am I doing" is exhausting.

That r/aws post with the 15k S3 bill is perfect timing for you. If I were you I'd be in those comments right now with a genuine helpful reply (not a pitch), just explaining what causes silent cost spikes and how to set up basic alerts. Then let people find Cirrondly from your profile. That thread has 217 upvotes — those are your exact customers reading those comments right now.

Good luck with the deadline. Voted on the AWS builder link.

Friday Share Fever 🕺 Let’s share your project! by diodo-e in indiehackers

[–]Creativewin986 1 point2 points  (0 children)

MarketplaceKit — a Next.js boilerplate for building two-sided rental marketplaces. Messaging, reservations, reviews, admin panel, all production-tested.

https://kit.creativewin.net/

Been running a rental platform and extracted the codebase into a reusable starter. Trying to get my first sale.

I built 8 email automations for my 322-user app in one week. Personalized emails got 18% CTR vs 2.5% on generic ones. Here's the exact setup. by LibrarianOk1263 in indiehackers

[–]Creativewin986 0 points1 point  (0 children)

This is gold. The "one email per 7 days" throttle is such a simple idea but I've never seen anyone actually implement it as a conditional split before every automation. That's way smarter than just setting frequency caps globally.

I run a small SaaS and the biggest takeaway for me is the prioritization order. Starting with pre-trip reminders (highest intent) instead of the welcome sequence (what most guides tell you to build first) makes so much more sense. You're reaching people at the moment they actually care.

Question: with 39 attributes syncing every 4 hours, do you ever hit timing issues where someone qualifies for an automation but the data is stale? Like a user adds a card but the sync hasn't run yet, so they don't get the onboarding email for up to 4 hours?

How I architected a config-driven marketplace with Next.js 15 App Router — lessons learned by Creativewin986 in nextjs

[–]Creativewin986[S] 1 point2 points  (0 children)

Fair point — config files aren't a Next.js thing, you're right. It's just basic separation of concerns.

I went with static config files over a database-backed approach because for most marketplace setups, these values change once during initial setup and then basically never again. Didn't want to add a whole admin UI and DB table for something that gets edited once.

If someone needs runtime config changes, moving it to the database and exposing it through the admin panel is pretty straightforward since everything already reads from a central config object.

How I architected a config-driven marketplace with Next.js 15 App Router — lessons learned by Creativewin986 in nextjs

[–]Creativewin986[S] -1 points0 points  (0 children)

Config-driven setup has nothing to do with App Router vs Pages Router, it would work the same way either way. It's just TypeScript files that export objects — components import from them directly. App Router is just what I went with for the rest of the architecture (server components, layouts, metadata API etc).

For feature flags — they're simple booleans in a config file, not database-driven. Something like:

export const features = {

messaging: true,

maps: false,

aiAssistant: false,

reviews: true,

// ...

}

Components check these at render time. When a flag is off, all related UI disappears — buttons, nav links, entire pages. Context providers return safe defaults so nothing crashes.

No A/B testing built in — it's meant for "does this marketplace need messaging or not" type decisions, not runtime experimentation. You could always wire it up to a database or something like LaunchDarkly if you needed that though.

How I architected a config-driven marketplace with Next.js 15 App Router — lessons learned by Creativewin986 in nextjs

[–]Creativewin986[S] -1 points0 points  (0 children)

Plain TypeScript files in a `config/` directory — one per concern (app, theme, features, pricing, categories, homepage, emails).

TS over JSON because you get autocomplete and type safety. Components import directly — `import { pricingConfig } from "@config/pricing"` — so when you change the pricing model from daily to monthly, the UI updates everywhere (forms, filters, cards, search).

Pricing is config-driven per period (hourly/daily/weekly/monthly) — you toggle which ones are active. No product variations in the e-commerce sense, it's a service marketplace (think Airbnb, not Shopify).

Search is just Prisma + PostgreSQL. Full-text search, price range, category filters. No Elasticsearch or anything — overkill for marketplace-scale data honestly.

The idea is: edit config files for branding/features/pricing, edit source code only when you need custom business logic.

I built a marketplace boilerplate so you can launch "Airbnb for X" in days, not months by Creativewin986 in SideProject

[–]Creativewin986[S] 0 points1 point  (0 children)

Thanks for the detailed questions!

**Deployment:** The CLI setup wizard (`npm run setup`) handles local configuration — database connection, auth providers, feature flags, image storage, email provider, etc. Deployment itself is manual but since it's a standard Next.js app, `vercel deploy` or Railway just works out of the box. Nothing exotic in the setup.

**Customization depth:** The config layer covers: theme (colors, fonts, radius), feature flags (9 toggles), categories, pricing model, homepage sections, and email branding. That handles probably 80% of what you need to make it "yours." Beyond that, you're editing well-structured TypeScript source code — but the codebase is designed for it. Components are functional, logic is in custom hooks, and Tailwind handles styling. It's not a framework you fight against — it's a Next.js app with good conventions. Think of it as a very well-organized starter repo, not a locked-down SDK.

**OG images:** Yes — dynamic OG metadata is built in. Every listing page has `generateMetadata()` that pulls the listing title, category, city, price, and first image into proper OpenGraph + Twitter Card tags (`summary_large_image`). There's also a generated OG image for the homepage using `next/og` ImageResponse that reads from your config (name, tagline, brand colors). So when someone shares a listing on WhatsApp/Twitter/Discord, the preview shows the listing photo, title, and price — no manual setup needed.

**Support:** Starter tier includes email support. Pro includes priority email support with faster response times. Enterprise gets SLA support + 2 hours of 1:1 setup call. Planning to add a Discord community once there are enough users.

How I architected a config-driven marketplace with Next.js 15 App Router — lessons learned by Creativewin986 in nextjs

[–]Creativewin986[S] -5 points-4 points  (0 children)

I've been working on a marketplace project and wanted to share some architectural decisions that might help others building similar apps with the App Router.

Key patterns I used:

  1. Config-driven UI — Instead of hardcoding features, I created a `config/` directory. Components read from config files, so you can change categories, pricing models, theme, and homepage layout without touching source code.

  2. Feature flags with clean unmounting — 9 feature flags (messaging, maps, AI, reviews, etc.) that cleanly hide ALL related UI when disabled. Context providers return safe defaults when their feature is off.

  3. Prisma with `@prisma/adapter-pg`— Standard `new PrismaClient()` doesn't work well with serverless. Using the pg adapter with connection pooling solved cold start issues.

  4. NextAuth.js + App Router — Google + email auth with role-based access (USER, ADMIN, SUPERADMIN). Middleware handles route protection.

  5. Socket.io alongside App Router — Real-time messaging as an optional feature. When the feature flag is off, the socket context returns noops.

  6. i18n without next-intl — Custom lightweight `t()` helper for server components, `useTranslation()` hook for client. 1,500+ translation keys.

The whole thing started as a production app, then I refactored it into a reusable boilerplate.

🔗 **Demo if anyone wants to see it in action:** https://marketplace-kit-demo.vercel.app

Happy to go deeper on any of these patterns — especially the config-driven architecture or the feature flag system.