DEV Community: Usama Habib

How to Prevent Double Bookings in Next.js (Race Conditions & DB Constraints)

Usama Habib — Wed, 15 Jul 2026 11:16:08 +0000

Most booking tutorials show you how to build a pretty calendar and save a reservation. Then they skip the one problem that actually matters in production.

What happens when two people book the same slot at the same time?

👉 Full guide here

Why "check then save" is a trap

The obvious approach:

const existing = await prisma.booking.findFirst({
  where: { resourceId, startTime },
});
if (existing) throw new Error("Slot taken");
await prisma.booking.create({ data: { resourceId, startTime } });

This works - until two requests arrive at the same moment. Both pass the check. Both create a booking. Race condition. Invisible in testing, guaranteed in production.

The fix isn't better app code — it's letting the database enforce the rule atomically.

Fix 1: Unique constraint (fixed slots)

model Booking {
  @@unique([resourceId, startTime])
}

Try to insert and catch the error:

try {
  await prisma.booking.create({ data: { resourceId, startTime } });
} catch (e) {
  if (e.code === "P2002") {
    return Response.json({ error: "Slot just taken" }, { status: 409 });
  }
}

Whoever commits first wins. Second request gets a clean 409. No race condition — uniqueness check and insert are one atomic op.

Fix 2: Overlapping bookings (the hard case)

Unique constraints only catch identical start times. A 60-min booking from 2:00 can still conflict with one from 2:30.

PostgreSQL exclusion constraint handles this:

CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE "Booking"
ADD CONSTRAINT no_overlapping_bookings
EXCLUDE USING gist (
  resource_id WITH =,
  tstzrange(start_time, end_time) WITH &&
);

Database now rejects any booking whose time range overlaps an existing one — no matter how many concurrent requests hit it.

Fix 3: Transactions for multi-step bookings

await prisma.$transaction(async (tx) => {
  await tx.booking.create({ data: { resourceId, startTime, endTime } });
  await tx.credit.update({
    where: { userId },
    data: { balance: { decrement: 1 } },
  });
});

Constraint prevents double booking. Transaction keeps related changes consistent.

Don't forget timezones

Always store timestamps in UTC. Convert to local time only for display. "2:00 PM" without timezone is meaningless for overseas customers.

Full guide with FAQ on Redis, queues, and when constraints are enough:

👉 osamahabib.com — Prevent Double Bookings Next.js

Spreadsheet to Web App: What It Actually Costs in 2026 (3 Options Compared)

Usama Habib — Tue, 14 Jul 2026 12:10:13 +0000

Almost every growing business hits the same wall: the spreadsheet that used to run everything starts causing more problems than it solves.

Someone overwrites a cell. Two people edit different copies. One wrong formula quietly costs you real money.

👉 Full honest breakdown here

Your 3 real options

Option 1: Keep the spreadsheet — $0

Fine if only 1–2 people touch it and process is simple. The real cost is hours lost and risk of costly errors — not money.

Option 2: No-code tool — $20–100+/month

Glide, Softr, Airtable — turn a spreadsheet into a simple app without a developer. Great starting point for simple needs.

Honest catch: you're renting, not owning. You hit a ceiling fast when you need custom logic or specific integrations.

Option 3: Custom web app — $3,000–15,000+

Built exactly for your workflow. No per-user fees, no ceiling, you own it permanently.

For one focused workflow — logins, clean interface, proper data — realistic range is $3,000–8,000.

What drives the price up

Number of workflows being replaced
User roles and permissions — role-based access costs more
Third-party integrations — email, payments, accounting
Automation and live dashboards

How to spend the least

Don't rebuild everything at once. Pick the single workflow that causes the most pain and turn just that into an app first.

Cheaper upfront, you see value fast, and it tells you whether digitizing the rest is worth it.

Full comparison with FAQ on no-code vs custom, pricing breakdown,
and when to make the switch:

👉 osamahabib.com — Spreadsheet to Web App Cost 2026

How to Hire a Next.js Developer When You're Not Technical (2026)

Usama Habib — Tue, 14 Jul 2026 12:05:00 +0000

Hiring a developer is nerve-wracking when you can't read code.
How do you tell a genuinely good Next.js developer from someone
who just talks a good game?

Most hiring guides are written for technical people. This one isn't.

👉 Full guide here

Green flags — signs someone is the real deal

✅ Live projects you can actually click — not screenshots, real URLs

✅ They explain things simply — if they can teach it, they understand it

✅ They ask about your business, not just the tech

✅ They talk about speed and reliability

✅ They mention code ownership from day one

Red flags — walk away

🚩 No live work to show

🚩 Every answer is a wall of jargon

🚩 Vague timelines — "it'll be done soon, roughly a few thousand"

🚩 Dodgy about post-launch ownership

🚩 Price feels too good to be true — $5/hr often costs more in rework

4 questions to ask — no tech knowledge needed

"Show me something similar you've built that's live"

Good: real link + short story. Weak: excuses.

"How will you keep me updated?"

Good: weekly demo + shared board. Weak: "I'll let you know when done."

"Do I own everything after launch?"

Good: straight yes. Weak: vagueness.

"Walk me through how you'd approach my project."

You're judging if they listened — not the tech answer.

The smartest move: start small

Don't bet your whole project on a first impression. Start with
a small paid task or discovery session. In one week you'll learn
more than any interview could tell you.

Good developers welcome this. The ones to avoid resist it.

Full guide with FAQ on technical requirements, frontend-only
developers, and testing before committing:

👉 osamahabib.com — How to Hire a Next.js Developer

5 Signs Your Business Has Outgrown Its Website in 2026

Usama Habib — Tue, 07 Jul 2026 11:35:57 +0000

When you first launched your website, it did the job. But businesses grow websites don't automatically grow with them.

The tricky part is that outgrowing a website is gradual. There's rarely one dramatic moment.

👉 Full guide here

The 5 signs

1. It's slow — and slow costs you customers

A 1-second delay in load time can cut conversions by up to 7%. Visitors abandon sites that take more than 2–3 seconds. You're losing customers before they ever see your offer.

2. You need a developer for every small change

Changing a price or adding a page means emailing someone and waiting. If routine updates require a developer every time, the platform is working against you.

3. You've outgrown a brochure site

You started needing a contact form. Now you need bookings, payments, a client portal, CRM integration. Your business runs on workflows your website can't handle.

4. It looks dated next to competitors

94% of first impressions are design-driven. If your site looks 5 years behind while competitors look modern, visitors quietly assume your business is behind too.

5. Traffic comes in, but inquiries don't

People visit but don't book or reach out. Something between interest and action is broken — unclear messaging, weak CTAs, confusing layout.

Redesign or rebuild?

Redesign — if it's mainly about looks and messaging.

Rebuild — if it's slow, fragile, and can't do what your business now needs. Patching it again just buys a few months.

The honest test: are you fighting your website to do normal things? If yes, it's time to rebuild.

Full guide with FAQ on redesign vs rebuild decision:

👉 osamahabib.com — Outgrown Your Website?

Freelance Developer vs Agency for Your Startup MVP: The Honest 2026 Comparison

Usama Habib — Mon, 06 Jul 2026 11:07:22 +0000

When you're ready to build your MVP, one of the first real decisions is who builds it - a freelance developer or an agency.

I'm a freelance developer, so I'll be upfront about that. But I'd rather give you an honest comparison than a sales pitch.

👉 Full breakdown here

The cost difference - real numbers

Freelancer: $12,000 – $35,000

Agency: $35,000 – $120,000

Same MVP. The gap isn't better code - it's overhead. Office, project managers, and team coordination.

When agency is genuinely the better choice

Complex product needing multiple specialists at once
Budget $50k+ with a hard, immovable deadline
Compliance or regulatory requirements
No time or technical comfort to manage a contractor

When freelancer is the smarter choice

Early-stage, budget matters
One focused product, not five things at once
Want to work directly with the builder
Speed and flexibility over heavy process

The real freelancer risk - and how to remove it

Biggest risk: dependency on one person. Fix it by:

Hiring full-stack - removes designer/developer handoff
Working in milestones - pay against deliverables
Weekly demo - never guessing where things stand
Code is yours from day one - no hostage situation

Simple decision framework

Simple product, can stay involved, flexible deadline → Freelancer
Complex product, no time to manage, hard deadline → Agency
Somewhere in between → Senior freelancer, best value

Full comparison with FAQ on cost, risk, and speed:

👉 osamahabib.com - Freelancer vs Agency 2026

Multi-Tenant SaaS with Next.js, Prisma & PostgreSQL (Practical Guide)

Usama Habib — Mon, 06 Jul 2026 06:01:27 +0000

Multi-tenancy quietly decides whether your SaaS scales cleanly or becomes a security incident. Get it right early - you barely think about it again. Get it wrong — you're rewriting your data layer at the worst time.

👉 Full architecture guide here

The 3 isolation strategies

1. Shared schema + tenant_id column ← recommended default One database, every table has orgId. Simplest to build, works for 100–10,000 tenants comfortably.

2. Schema-per-tenant

Separate PostgreSQL schema per tenant. Good for mid-market with customization needs, but pooling gets complicated.

3. Database-per-tenant

Maximum isolation. Enterprise only - operationally the heaviest.

Start with shared schema. Graduate specific tenants later.

The rule you never break

Every Prisma query must include the tenant filter — no exceptions:

const projects = await prisma.project.findMany({
  where: { orgId: currentOrgId }, // always
  orderBy: { createdAt: "desc" },
});

One forgotten where clause leaks another tenant's data.

Add RLS as a safety net

Row-Level Security makes PostgreSQL itself enforce isolation:

ALTER TABLE "Project" ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON "Project"
  USING (org_id = current_setting('app.current_tenant_id'));

Now even if app code forgets a filter, the database won't hand over wrong tenant's rows.

The production gotcha nobody warns about

PgBouncer in transaction mode resets session variables between transactions - your SET app.current_tenant_id disappears before the query runs.

Fix: use session mode, or set tenant context inside the same prisma.$transaction as your query.

Full guide with Prisma schema, middleware tenant resolver, RLS setup, and FAQ:

👉 osamahabib.com — Multi-Tenant SaaS Guide

How Long Does It Take to Build a Custom Web App in 2026?

Usama Habib — Mon, 22 Jun 2026 04:21:13 +0000

"How long will it take?" — the second question every founder asks, right after cost. And like cost, the honest answer is a range.

Most articles on this topic are written by agencies who nudge every answer toward big, long, expensive projects. Here's the straight version.

👉 Full breakdown here

The short answer

Simple app - 4 to 8 weeks
Standard app - 3 to 4 months
Complex platform - 6 to 12 months

Most focused MVPs land between 6 and 12 weeks. Anything past 6 months is either genuinely complex or suffering from unclear scope - and the second one is far more common.

What actually speeds it up

Narrow, ruthless scope in v1
Developer who has built similar systems before
Modern stack - Next.js + Prisma + PostgreSQL lets one developer move fast without a big team
AI tools - in 2026 they compress routine coding by 30–50%, but they speed up the typing, not the thinking

What quietly slows it down

"Can we also add…" mid-build - number one timeline killer
Too many features in v1
Slow feedback loops - if approvals take a week, calendar stretches even when work doesn't
Rushing - demanding unrealistic deadlines adds 15–30% in rework

The one thing most people skip

Discovery and planning. Skipping it to "save time" is the single most expensive shortcut. Two weeks of clarity upfront saves months of rebuilding later.

Full timeline breakdown by complexity, FAQ, and honest advice on getting yours built faster:

👉 osamahabib.com - Custom Web App Timeline 2026

How to Add Stripe Subscription Billing to Next.js 15 (Webhooks Done Right)

Usama Habib — Thu, 18 Jun 2026 11:02:37 +0000

Most Stripe tutorials stop at "redirect to Checkout." That's the easy part. The part that actually matters - webhooks - is what keeps getting skipped.

This is the same billing flow I use in production SaaS apps.

👉 Full guide with copy-paste code

What you'll build

A complete subscription loop: user clicks Subscribe → Stripe Checkout → pays → your database reliably knows they're a paying
customer - even if they close the tab immediately after payment.

The part most tutorials miss

`// metadata is how you link a Stripe payment to YOUR user
const session = await stripe.checkout.sessions.create({
  mode: "subscription",
  line_items: [{ price: "price_XXXXXXXX", quantity: 1 }],
  metadata: { userId }, // ← most tutorials skip this
  success_url: `${process.env.NEXT_PUBLIC_APP_URL}/dashboard`,
  cancel_url: `${process.env.NEXT_PUBLIC_APP_URL}/pricing`,
});`

Without metadata.userId, your webhook has no way to know which user just paid.

Two webhook mistakes that break everything

1. Parsing body as JSON - you must use req.text() for raw body, otherwise signature verification fails.

2. Skipping signature verification - without it, anyone can fake a "user paid" event to your endpoint.

`const body = await req.text(); // NOT req.json()
const event = stripe.webhooks.constructEvent(
  body,
  req.headers.get("stripe-signature")!,
  process.env.STRIPE_WEBHOOK_SECRET!
);`

Gate features in one line

Once your DB knows who's paying:

`if (!user.isPro) redirect("/pricing");`

That's the whole loop: checkout → webhook → DB → gate.

Full guide covers all 6 steps, local webhook testing with Stripe CLI, common mistakes, and FAQ:

👉 osamahabib.com - Stripe Billing Next.js 15

How Much Does It Cost to Build a SaaS MVP in 2026? (Real Numbers)

Usama Habib — Tue, 16 Jun 2026 03:45:13 +0000

"How much will it cost to build my SaaS?" - the first question
almost every founder asks. And the hardest to answer in one number.

Honest answer: anywhere from $3,000 to $50,000+. The difference
usually isn't the code. It's the decisions made before a single
line is written.

👉 Full breakdown with real numbers

The 3 tiers - what you actually get at each price

Lean MVP - $3,000 to $8,000
One core workflow, auth, dashboard, Stripe billing, database.
Buildable by one experienced developer in a few weeks.
Most early founders should aim here.

Standard MVP - $8,000 to $20,000
Multiple user roles, polished UI, integrations (email, payments,
third-party APIs), automation, proper deployment.
Sweet spot for a fundable SaaS.

Complex MVP - $20,000+
Multi-tenancy, real-time features, AI integration, compliance,
or a team building it faster.

What actually drives the price up

User roles - one role is simple, admin + customer + team-member triples the logic
Integrations - Stripe, email, calendars, AI APIs each add real engineering hours
Who builds it - an agency costs 2-3x more than an experienced independent developer for the same output

Where founders waste money

Building features nobody asked for yet
Over-designing before product-market fit
Hiring a $5/hr freelancer who disappears mid-project — the rework costs far more

The right approach

Cut scope, not quality. Pick the one workflow that proves your
idea. Ship it. Let real user feedback direct version two.

Full breakdown + FAQ on timeline, stack, and freelancer vs agency:

👉 osamahabib.com - SaaS MVP Cost 2026

Website vs Custom Web App: What's the Real Difference in 2026?

Usama Habib — Thu, 11 Jun 2026 08:14:33 +0000

Still running your business through WhatsApp groups and spreadsheets?

Most businesses hit the same wall. The website looks great - but the actual business runs on workarounds. That is the moment a website stops being enough.

👉 Full breakdown here

Website vs Web App - the actual difference

A website is a digital brochure. Visitors read it. That is its job.

A custom web app is a digital engine. It takes bookings, processes orders, manages inventory, sends automated reminders, handles payments. It works while you sleep.

Same browser. Completely different purpose.

The real cost of patching things together

Most businesses end up paying for 8–10 subscriptions that do not talk to each other. Team spends hours moving data manually. Customers fall through the cracks.

The tools that helped you start are now holding you back.

What a custom web app actually does

Automates repetitive work - confirmations, invoices, follow-ups
Connects everything in one place - no more manual data entry
Scales with your business - add features, not new platforms
Real-time visibility - revenue, orders, performance from anywhere
You own it permanently - no monthly fees, no vendor lock-in

Real examples

A clinic replaced phone bookings with self-booking - no-shows dropped 40%.

A courier company replaced WhatsApp order management with a live tracking dashboard - support calls dropped to near zero.

A coaching business replaced Google Forms with a client portal - payments, materials, and progress all in one place.

None of these needed a big tech budget.

Is it right for you?

You need a custom web app if you are managing business processes through WhatsApp or spreadsheets, paying for tools that do not integrate, or losing customers due to slow manual processes.

A standard website is still fine if you are a new business that just needs an online presence.

Full guide with ROI breakdown and honest cost analysis:

👉 osamahabib.com — Custom Web App vs Website 2026

FastAPI vs Node.js in 2026: Which Backend Should You Choose?

Usama Habib — Tue, 09 Jun 2026 11:15:16 +0000

Both are fast. Both are async. Both handle production workloads.And that is exactly what makes this choice genuinely difficult.

After building production projects with both stacks - and helping clients make this exact call - here is my honest breakdown.

👉 Read the full comparison here

Quick summary: What each tool actually is

Node.js: JavaScript runtime on Chrome's V8 engine. In production since 2009. Powers 6.3 million web apps globally. Usually paired with Express or NestJS.

FastAPI: Modern Python framework built on Starlette and Pydantic. Released 2018. 88,000+ GitHub stars. Used by Microsoft, Netflix, Uber.

Both support async/await. Both are production-grade. The question is not which is better - it is which is right for your project.

Where Node.js wins

Full-stack JS with React/Next.js frontend - one language, shared TypeScript types, one CI/CD config
Real-time apps - chat, live notifications, collaborative tools
Maximum ecosystem maturity - 2.5 million npm packages

Where FastAPI wins

AI/ML integration: scikit-learn, PyTorch, LangChain work natively. No awkward bridging layers like with Node.js
Automatic validation: Pydantic handles complex nested data far cleaner than manual JS validation
Auto-generated docs: Swagger UI at /docs with zero config

The one thing most comparisons miss

For 90% of web API use cases, neither framework will be your bottleneck. Your database queries, caching strategy, and architecture decisions matter far more than the framework benchmark.

Choose based on your team and your project requirements - not raw performance numbers.

Full breakdown with code comparisons, performance numbers, and detailed decision framework:

👉 osamahabib.com - FastAPI vs Node.js 2026

Git & GitHub for Beginners: Learn the 5 Commands You'll Use Every Day

Usama Habib — Mon, 08 Jun 2026 07:36:49 +0000

Every developer uses Git. Most beginners avoid it for weeks because
it looks complicated. It is not - and this guide proves it fast.

When I started learning web development, I avoided Git for weeks.
Every tutorial mentioned it. Every job posting listed it. And every
time I tried to understand it, I ended up more confused than before.

It is not complicated. I just needed someone to explain it the right way.

👉 Read the full guide here

Git and GitHub are not the same thing

Git runs on your computer and tracks changes in your code over time.

GitHub is a website that stores your Git-tracked projects online.

Simple relationship: Git works locally. GitHub stores it in the cloud.

The 5 commands you will use every single day

git init        # Turn a folder into a Git project
git add .       # Stage your changes
git commit -m " # Save a version with a message
git push        # Upload to GitHub
git pull        # Download latest from GitHub

That is honestly 90% of your daily Git usage - even as a professional.

The one habit that separates good developers from great ones

Commit often. Not once a day - after every meaningful change.

Finished a navbar? Commit. Fixed a bug? Commit. Added a new section? Commit.

Small frequent commits save hours of debugging. This habit takes
less than 30 seconds each time.

For the complete walkthrough - setup, first push to GitHub, and
what to learn next:

👉 Git & GitHub for Beginners - osamahabib.com