Guides for using Futurnu products

Launch your first B2B SaaS in 4–6 weeks

Use this with the Futurnu Next.js SaaS Starter. The goal is not to build a perfect product; it is to get a simple, paid SaaS in front of 3–5 small teams in about 4–6 weeks without rebuilding boilerplate.

1. Pick one narrow B2B niche and a single painful workflow you can improve (for example reporting, approvals, or simple analytics for small teams).
2. Week 1–2: run the starter, rename routes and layout to your product, sketch your data model, and wire one end‑to‑end flow inside the existing dashboard shell.
3. Week 3–4: invite 1–2 friendly teams, tighten the core workflow based on how they actually click around, and keep everything else deliberately boring.
4. Week 5–6: onboard 3–5 paying teams, add only the settings and reports they need, and avoid refactors that do not change whether someone pays you.

For a concrete example, see the B2B analytics SaaS case study linked from the Next.js SaaS Starter product page.

If you want to launch the SaaS and its landing together on one stack, you can use the Next.js Launch Bundle.

Go from Notion to live landing in a weekend

This plan assumes you already have a Notion doc with a rough outline of your product. With the Next.js Landing Kit, the goal is to ship a clear first landing in one weekend instead of tweaking layouts for weeks.

1. Friday evening: duplicate one of the base pages from the Landing Kit, pick a layout that roughly matches your product (SaaS, digital product, or service), and drop in your logo/name.
2. Saturday morning: write a sharp hero section (problem, promise, and who it is for), then fill in 3–5 feature bullets that mirror the pains in your Notion doc.
3. Saturday afternoon: add a simple pricing block, 1–3 short testimonials or clear lines that spell out exactly who the product is for, and a tiny FAQ that answers the last doubts.
4. Sunday: wire the primary CTAs to your signup or waitlist flow, deploy to your own domain, and send the link to a small list of people who might actually care.

Keep your Node.js app responsive with queues

Use this with the Node.js Job Queue Starter. The goal is to move heavy work off the request‑response path so your main API can stay fast even when emails, reports, internal alerts, or clean‑up jobs pile up.

1. List the slow tasks that currently block responses (long emails, PDF reports, database clean‑ups, third‑party API calls) and also the alert checks that run on a schedule, then estimate how many you run per day.
2. In your API route, enqueue a job with the minimal data needed instead of running the heavy work inline, and immediately return a success response to the user.
3. Move the actual heavy logic into a dedicated queue worker using the starter patterns, add logging for success and failures, and cap concurrency so the database does not get overwhelmed.
4. For internal alerting, send jobs through the queue that evaluate thresholds and notify people by email or chat, instead of running many checks inline on every request.
5. Add a simple admin view or log summary so you can see stuck jobs, retry them, and prove to yourself that the app stays responsive even when the queue grows.

A typical wiring looks like this: in a Next.js API route you validate input, enqueue a job such asgenerateUsageReportwith the organisation id and date range, return a success response, and let the worker create the CSV or Excel file in the background.

در عمل یعنی در routeهای API فقط ورودی را چک می‌کنی و یک job مثل generateUsageReport با شناسهٔ سازمان و بازهٔ تاریخ در صف می‌گذاری و اجازه می‌دهی ورکر در پس‌زمینه فایل گزارش را بسازد.

For a scheduled reports scenario built on this pattern, you can read the Node Job Queue case study linked from the product page.