👥 YOUR FIRST 10 USERS

You've built something. Now what?

Where do first users come from?

---

THE COLD START PROBLEM

"I launched and nobody came."

This is normal. Expected, even.

Nobody knows you exist.
That's not a product problem.
That's a distribution problem.

---

WHERE SOLO DEVS FIND FIRST USERS

Free channels that work:

1. Friends & colleagues (Users 1-3)
Ask directly. "I built X, can you try it?"
Don't be shy. They want to help.

2. Communities you're already in (Users 4-7)
- Slack/Discord groups
- Reddit (carefully, no spam)
- Twitter/X if you have followers
- Your Telegram channels 😉

3. Show HN / Indie Hackers (Users 8-10+)
- Launch posts get visibility
- Be honest: "Solo dev, first launch"
- Ask for feedback, not praise

---

THE ASK THAT WORKS

Bad: "Check out my new app!"

Good: "I built a tool that does X.
Looking for 5 people to try it free
and give me honest feedback.
Anyone interested?"

Specific. Humble. Clear value exchange.

---

TRACK EVERYTHING

-- Know where your users came from
SELECT 
    source,
    COUNT(*) as signups,
    MIN(created_at) as first_signup
FROM waitlist
GROUP BY source
ORDER BY signups DESC;

This tells you where to double down.

---

THE GOAL

10 users who actually use it.
Not 1,000 signups who forget.

10 real conversations > 10,000 vanity metrics

---

Friday: Show what you've got.
Demo Friday #3. Last one before launch week.

Where will you find your first users? 👇

#DecemberShipping

🎬 DEMO FRIDAY #3

Last demo before launch week.

Next week = the real thing.

---

SHOW YOUR PROGRESS

Share:
→ Link to your landing page
→ Screenshot of what you built
→ Your launch plan for next week

No landing page yet?
Screenshot of the app works.

---

📊 WEEK 3 PULSE

Waitlists set up: ?
Landing pages live: ?
First beta users invited: ?

Drop your numbers.

---

WEEK 3 RECAP

Mon: Reality check, scope down
Tue: Minimum viable launch
Wed: Solo dev launch toolkit 💰
Thu: Finding first 10 users
Fri: You are here

---

NEXT WEEK: LAUNCH WEEK 🚀

The final sprint:
- Monday: Last-minute fixes
- Tuesday: Launch prep checklist
- Wednesday: LAUNCH DAY
- Thursday: Post-launch survival
- Friday: December retro

One week left in December.
One week to ship.

---

WEEKEND TASK

If you do ONE thing:
Get a link ready to share.

Landing page > Notion doc > Google form >
Literally anything someone can click.

---

What are you launching? 👇

Show us. We'll hype you up.

#DecemberShipping

🏁 FINAL WEEK

December ends in 9 days.

Whatever state your project is in right now —
that's your launch state.

No more "one more feature."
No more "just need to fix this."
No more "almost ready."

---

TODAY'S MISSION

If you haven't shared your project publicly yet,
today is the day.

Not tomorrow. Not after Christmas.
Today.

Share it in:
→ This chat (reply below)
→ Twitter/X
→ Reddit
→ A friend's DMs
→ Anywhere with humans

---

WHAT COUNTS AS A LAUNCH

✅ Landing page with signup
✅ Working demo people can try
✅ Beta invite link
✅ "Coming soon" page with email capture
✅ Even a Notion doc explaining what you're building

If someone can look at it and understand what you're making,
it counts.

---

THE UNCOMFORTABLE TRUTH

You will never feel ready.

The project will never feel finished.

The code will never feel clean enough.

Launch anyway.

---

Reply with your link. Any link.
Let's see what December produced. 👇

#DecemberShipping

🚀 DECEMBER LAUNCH DAY

This is it. The thread.

Post your project below.

---

FORMAT

🔗 Link:
📝 What it does (1 sentence):
🛠️ Built with:
⏱️ Time spent:

---

RULES

1. No judging. Everyone ships at their own pace.
2. Try at least one other person's project.
3. Leave actual feedback, not just "cool!"
4. Upvote/react to projects you like.

---

REMEMBER

A launched ugly project beats
an unlaunched perfect one.

Every successful product you use today
once looked embarrassing.

---

I'll start:

This channel. 1,000+ of you now.
Started as "I'll post some PostgreSQL tips."
Still figuring it out. Still shipping.

---

Your turn. 👇

What did you build this December?

#DecemberShipping

If you shipped something this month:
Congratulations. You did more than most.

If you didn't finish:
You learned. That counts too.

If you just followed along:
You're more prepared than you were December 1st.

---

THE DECEMBER STATS

Builders who joined the challenge: 200+
Projects shared publicly: [we'll count Friday]
Community posts: hundreds
Excuses defeated: countless

---

Tomorrow: No post. It's Christmas.

Friday: December retrospective.
We'll count the wins and plan for January.

---

Enjoy the break. You earned it.

Merry Christmas to those celebrating. 🎄

See you Friday.

@postgres

📊 DECEMBER RETROSPECTIVE

The month is almost over.
Let's count what happened.

---

BY THE NUMBERS

Subscribers Dec 1: ~1,000
Subscribers now: 1364


---

WHAT WORKED THIS MONTH

✅ Daily accountability posts
✅ Simple, actionable content
✅ Community sharing progress
✅ "Ship broken, not perfect" mindset
✅ PostgreSQL doing everything

---

WHAT I LEARNED RUNNING THIS

→ You want simple, not complex
→ You want "today" not "someday"
→ You're building real things, not just learning
→ Community momentum is real

---

THE REAL WIN

December wasn't about finishing.
It was about starting.

If you wrote one line of code,
created one table,
deployed one thing —

You're ahead of December 1st you.

---

WHAT'S NEXT

January: New challenge?
Keep shipping?
Something different?

What do you want from @postgres in 2025?

Reply below. Seriously.
This shapes what comes next.

---

Thank you for being here.

1,000+ people learning PostgreSQL together.
That's pretty cool.

See you next year. 🎉

@postgres

#DecemberShipping

🎯 2026 STARTS NOW

December is done. Holidays over.
No more excuses.

What are you building this year?

---

DECEMBER RECAP

We had 200+ people join the shipping challenge.
Dozens of projects launched.
Some ugly. Some broken. All real.

That momentum doesn't have to stop.

---

2026: SIMPLER APPROACH

Last year I overcomplicated things.
Big masterclasses. Complex systems.

This year: small wins.

One useful thing per week.
Something you can implement in an hour.
Actually use it. Move on.

---

THIS WEEK

Mon: Fresh start (you're here)
Tue: The 3-table SaaS (all you actually need)
Wed: 💰 Copy-paste auth queries (3 ⭐)
Thu: Your first mass email (from PostgreSQL)
Fri: Week 1 check-in

Simple. Useful. Cheap.

---

QUESTION FOR YOU

What's the ONE thing you want to build in January?

Not a roadmap. Not a vision.
One thing. Reply below.

Let's make it happen.

#January2026

🗄️ THE 3-TABLE SAAS

Every SaaS tutorial shows you 47 tables.
Users, profiles, settings, preferences,
organizations, memberships, roles, permissions...

You don't need that.

You need 3 tables to start making money.

---

TABLE 1: USERS

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email TEXT UNIQUE NOT NULL,
    password_hash TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

That's it. No name, no profile, no avatar.
Add them when ONE user asks for them.

---

TABLE 2: THE THING YOU'RE SELLING

CREATE TABLE projects (  -- or whatever your thing is
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID REFERENCES users(id),
    name TEXT NOT NULL,
    data JSONB DEFAULT '{}',  -- flexibility for now
    created_at TIMESTAMPTZ DEFAULT NOW()
);

Projects, documents, dashboards, reports —
whatever your product creates.

---

TABLE 3: PAYMENTS

CREATE TABLE payments (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID REFERENCES users(id),
    stripe_payment_id TEXT,
    amount INTEGER,  -- cents
    status TEXT DEFAULT 'pending',
    created_at TIMESTAMPTZ DEFAULT NOW()
);

Not subscriptions. Just payments.
Stripe Checkout handles the rest.

---

THAT'S THE WHOLE DATABASE

3 tables. 20 lines of SQL.
Add complexity when you need it.
Not before.

---

Tomorrow: Auth queries that work with this.

Session management.
Password reset.
Magic links.
All copy-paste ready.

3 ⭐ — less than a coffee.

#January2026

📧 YOUR FIRST MASS EMAIL

You have a waitlist. Or users. Or both.
Time to email them.

No Mailchimp. No Sendgrid dashboard.
Just PostgreSQL + one API call.

---

THE SIMPLE WAY

-- Get everyone who should receive this email
SELECT email, name 
FROM users 
WHERE created_at > '2025-12-01'
  AND email_verified = true
  AND unsubscribed = false;

Export. Paste into your email tool.
Or loop through in code.

---

TRACK WHAT YOU SEND

CREATE TABLE email_log (
    id SERIAL PRIMARY KEY,
    user_id UUID REFERENCES users(id),
    email_type TEXT,  -- welcome, update, promo
    sent_at TIMESTAMPTZ DEFAULT NOW()
);

-- Before sending, check:
SELECT user_id FROM email_log 
WHERE email_type = 'jan_update' 
  AND user_id = $1;

-- If empty, safe to send

No double-sends. Ever.

---

SIMPLE UNSUBSCRIBE

ALTER TABLE users ADD COLUMN unsubscribed BOOLEAN DEFAULT false;

-- Unsubscribe link: /unsubscribe?token=xxx
UPDATE users SET unsubscribed = true
WHERE id = (SELECT user_id FROM unsubscribe_tokens WHERE token = $1);

---

THE ACTUAL SENDING

Use what you have:
- Resend: 3,000 free/month
- Postmark: 100 free/month
- AWS SES: $0.10 per 1,000

One API call per email.
PostgreSQL handles the logic.

---

YOUR ASSIGNMENT

If you have ANY users or waitlist signups,
send them an email this week.

"Hey, just checking in. Still interested in [thing]?"

That's it. You'll learn something.

---

Tomorrow: Week 1 check-in.
What did you ship?

#January2026

📊 WEEK 1 CHECK-IN

First week of 2026. Done.

---

THIS WEEK WE COVERED

Mon: Fresh start, what are you building
Tue: 3-table SaaS (users, things, payments)
Wed: Copy-paste auth queries 💰
Thu: Mass email from PostgreSQL

Simple stuff. Foundational stuff.

---

WHAT DID YOU DO?

Reply with one of these:
- 🚀 Started something new
- 🔧 Worked on existing project
- 📚 Just learning for now
- 😴 Honestly, not much

No judgment. Just curious where everyone is.

---

NEXT WEEK PREVIEW

More simple wins:

- Background jobs without Redis
- The $0 monitoring stack
- Making PostgreSQL fast (indexes that matter)

Still keeping it simple.
Still keeping it cheap.

---

QUICK POLL

The 3 ⭐ pricing — better or worse?

Too cheap = feels low quality?
Just right = removes friction?

Genuinely want to know.

---

See you Monday.

First week done. 51 to go.

#January2026

⚡ WEEK 2: NO MORE REDIS

Last week: Auth queries.
This week: Background jobs.

---

THE PROBLEM

Your app needs to:
- Send emails without blocking requests
- Process uploads after response
- Run daily reports
- Clean up old data
- Sync with external APIs

The "normal" solution:
Redis + Sidekiq/Bull/Celery

The cost:
- Another service to run ($15-50/month)
- Another thing to break
- Another thing to monitor

---

THE POSTGRESQL WAY

Your database can be your job queue.

Not "for small projects."
Not "until you scale."

For real production apps.

---

THIS WEEK

Tue: How PostgreSQL job queues work
Wed: 💰 Copy-paste job queue (4 ⭐)
Thu: Scheduling with pg_cron
Fri: Week 2 check-in

---

LAST WEEK'S WIN

The auth queries got their first buyer. 🎉

Small wins. Real progress.
That's the 2026 energy.

---

What background tasks do you need to run?

#January2026

🔄 POSTGRESQL AS A JOB QUEUE

"Use Redis for queues."

Why? PostgreSQL handles queues fine.

Here's how it works.

---

THE BASIC IDEA

CREATE TABLE jobs (
    id SERIAL PRIMARY KEY,
    task TEXT NOT NULL,
    payload JSONB,
    status TEXT DEFAULT 'pending',
    run_at TIMESTAMPTZ DEFAULT NOW(),
    created_at TIMESTAMPTZ DEFAULT NOW()
);

Add job:

INSERT INTO jobs (task, payload) 
VALUES ('send_email', '{"to": "[email protected]"}');

Get next job:

UPDATE jobs SET status = 'processing'
WHERE id = (
    SELECT id FROM jobs 
    WHERE status = 'pending' AND run_at <= NOW()
    ORDER BY created_at 
    LIMIT 1
    FOR UPDATE SKIP LOCKED  -- This is the magic
)
RETURNING *;

---

THE MAGIC: FOR UPDATE SKIP LOCKED

Multiple workers can poll the same table.
Each gets a different job.
No duplicates. No conflicts.

PostgreSQL handles the locking.

---

WHAT YOU NEED FOR PRODUCTION

Basic table? Easy.
Production-ready? Needs more:

- Retry logic for failures
- Dead letter queue for permanent failures
- Priority levels
- Scheduled jobs (run at specific time)
- Job timeout handling
- Proper indexes

---

Tomorrow: All of that. Copy-paste ready.

4 ⭐ — Replace your Redis bill forever.

#January2026

⏰ SCHEDULING WITH PG_CRON

Background jobs: done.
But what about scheduled tasks?

"Run this every night at 3 AM"
"Send weekly report every Monday"
"Clean up old data daily"

---

PG_CRON: CRON INSIDE POSTGRESQL

-- Enable the extension
CREATE EXTENSION pg_cron;

-- Run every night at 3 AM
SELECT cron.schedule(
    'nightly-cleanup',
    '0 3 * * *',
    $$DELETE FROM sessions WHERE expires_at < NOW()$$
);

-- Run every Monday at 9 AM
SELECT cron.schedule(
    'weekly-report', 
    '0 9 * * 1',
    $$INSERT INTO jobs (task, payload) VALUES ('send_weekly_report', '{}')$$
);

That's it. Runs inside PostgreSQL.

---

COMMON SCHEDULES

-- Every minute
'* * * * *'

-- Every hour
'0 * * * *'

-- Every day at midnight
'0 0 * * *'

-- Every Monday at 9 AM
'0 9 * * 1'

-- First day of month
'0 0 1 * *'

---

MANAGE YOUR SCHEDULES

-- List all jobs
SELECT * FROM cron.job;

-- Disable a job
SELECT cron.unschedule('nightly-cleanup');

-- See job history
SELECT * FROM cron.job_run_details 
ORDER BY start_time DESC LIMIT 10;

---

THE COMBO

pg_cron schedules → inserts into jobs table → workers process

No external scheduler.
No cron on server.
All in PostgreSQL.

---

WHERE TO GET PG_CRON

✅ Supabase: Built-in
✅ Neon: Available
✅ Railway: Available
✅ Render: Available
✅ Self-hosted: apt install postgresql-14-cron

Most managed PostgreSQL has it now.

---

What do you need to schedule?

#January2026

📊 WEEK 2 CHECK-IN

Background jobs week: done.

---

THIS WEEK

Mon: Why PostgreSQL for job queues
Tue: How FOR UPDATE SKIP LOCKED works
Wed: Complete job queue system 💰
Thu: pg_cron for scheduling

---

THE REDIS QUESTION

"But Redis is faster for queues!"

Sure. Redis is faster.
But is your bottleneck really queue speed?

For 99% of apps:
- PostgreSQL queue: Fast enough
- One less service: Priceless
- Simpler stack: Fewer bugs

Optimize when you need to.
Not before.

---

WHAT DID YOU IMPLEMENT?

- ⚡ Set up a job queue
- ⏰ Added pg_cron schedules
- 📚 Just learning for now
- 🤔 Still thinking about it

---

NEXT WEEK PREVIEW

Making PostgreSQL fast.

Not "optimization theory."
Actual indexes. Actual queries.
Before/after benchmarks.

The stuff that makes your app stop being slow.

---

MONTH CHECK-IN

Week 1: Auth ✓
Week 2: Background jobs ✓
Week 3: Performance (coming)
Week 4: ???

What should Week 4 be?

Reply with requests.

---

See you Monday.

#January2026

🐢 WHY YOUR QUERIES ARE SLOW

"PostgreSQL is slow."

No. Your queries are slow.
PostgreSQL is waiting for you to help it.

---

THE USUAL SUSPECTS

1. Missing indexes
PostgreSQL scans every row.
Millions of rows = slow.

2. Wrong indexes
You have indexes.
They're not being used.

3. Too much data
SELECT * when you need 2 columns.
JOINs that pull entire tables.

4. N+1 queries
1 query to get users.
100 queries to get their posts.
Death by a thousand cuts.

---

THE GOOD NEWS

Most slow queries are fixed with:
- One or two indexes
- Minor query rewrites
- EXPLAIN ANALYZE (so you know what's happening)

No magic. No expensive consultants.
Just knowing where to look.

---

THIS WEEK

Tue: Indexes that actually matter
Wed: 💰 Query speedup cheat sheet (3 ⭐)
Thu: EXPLAIN ANALYZE decoded
Fri: Week 3 check-in

---

What's your slowest query right now?

Paste it below. Let's fix it together.

#January2026