DEV Community: rokcso

How I Ran a Live Production Upgrade in 24 Minutes Without Taking the Site Down

rokcso — Wed, 15 Apr 2026 06:40:10 +0000

I do not like touching production unless I have to.

Feature work is fun. Production upgrades are not. Feature work gives you screenshots. Production upgrades give you backups, validation queries, freeze switches, and a very direct answer to the question: do you actually trust your system?

I recently had to do one of those upgrades for Shipstry, a product launch platform I run on Cloudflare Workers.

The maintenance window took about 24 minutes.

During that window, I:

froze writes with a centralized maintenance guard
backed up production D1
migrated comment data into a cleaner split model
moved payments onto a new internal purchase domain
backfilled historical orders conservatively
verified that old entitlements and historical paid amounts still matched before reopening writes

Public pages stayed up the whole time. That was the main requirement from the start.

TL;DR

The release worked because I treated it like an operational change, not a schema change.

The migration script was only one part of it. The real release was:

one switch to freeze writes
a production backup taken before any destructive step
baseline counts recorded in advance
validation gates after every risky move
no pressure to reopen writes early

One SQL migration did fail on the first run because Cloudflare D1 remote execution rejected an explicit transaction wrapper in the file. That did not turn into an incident because the safety rails were already in place.

Why I changed the model

This upgrade was triggered by two areas that had started to outgrow the old schema.

The first was comments.

Product comments and blog comments had drifted enough that pretending they were the same thing was no longer buying simplicity. It was just deferring cleanup.

The second was payments.

The old order model was good enough when it handled a narrower set of paid actions. It became less convincing once the platform started supporting multiple payment-backed behaviors:

backlinks access
paid submissions
product upgrades
upgrade pricing that respects what a maker already paid before

At that point I needed the database to answer business questions directly, instead of forcing new features to keep carrying legacy assumptions around.

The core separation I wanted was:

the payment itself
what the user bought
what that purchase unlocks

That sounds abstract until you hit questions like:

Does an old backlinks purchase still grant access?
If someone already paid for an earlier tier, does that amount still count toward the next upgrade?
Can I evolve the payment system without special-casing old data everywhere?

Once those questions become common, "we will clean it up later" stops being practical.

The rule that mattered most

I did not want a full outage.

I also did not want live writes continuing while I changed production data underneath them.

So the operating rule was simple:

reads stay up, writes freeze first

That only works if you have a real maintenance switch. Not a plan to be careful. Not a checklist item. A switch that the app actually respects.

Before release day, I added a centralized MAINTENANCE_WRITE_FREEZE guard and wired it through the places that can mutate D1:

checkout creation
Stripe webhook mutations
comments and likes
votes
profile updates
admin write actions
draft save, submit, and delete flows
notification endpoints that mutate state

I was not optimizing for elegance. I was optimizing for control.

If I have to do this again, I want one switch that really means one switch.

The boring work that makes production survivable

Before touching a migration, I exported production D1.

That should feel boring. If backups feel exciting, you are already too late.

I also recorded baselines before the destructive parts:

legacy comment count
legacy comment-like count
top-level vs reply comment counts
soft-deleted comments
legacy order count
paid backlinks count

Those numbers became release gates later.

Not "it seems fine."

Not "the page loaded on my laptop."

Actual before and after checks.

Production had a surprise waiting

Before the main cutover, I checked for old pricing-tier values that should already have been normalized.

Production still had legacy expedition values in both:

product.pricing_tier
legacy order.tier

That was annoying, but useful.

It meant I could not trust migration history in the abstract. I had to trust the database I was actually about to operate on.

So I reran the tier-normalization migration before the comment and payment cutover. That cleaned up the remaining visible tier drift before final deployment.

It is a small example, but it captures something important: production work gets easier the moment you stop arguing with reality.

The comment migration

The comment migration looked straightforward on paper and high-risk in practice.

Old comment data had to be split into four tables:

product_comment
product_comment_like
blog_comment
blog_comment_like

The schema work itself was not the scary part. The real risk was silently dropping relationships or detaching data during the move.

So I checked what actually mattered:

comment counts matched
comment-like counts matched
orphan replies were zero
orphan likes were zero

The production dataset was still small. I treated it like a serious migration anyway. Row count does not change the standard.

The payment migration was the real reason for the window

The bigger job was payments.

Shipstry now reads runtime payment state through a cleaner domain:

payment_order
purchase
product_submission_purchase
product_upgrade_purchase

I wanted this because the old model was trying to do too much with too little structure.

Once the platform started supporting more than one kind of paid action, I needed the schema to preserve meaning, not just store rows.

The most important example was upgrade pricing.

If a maker already paid for an earlier tier, Shipstry should not pretend that money never existed. Their next upgrade should take prior payment into account. From the user's perspective that is obvious. From the schema's perspective it is only obvious if the model supports it.

The backfill was where I had to stay conservative

Schema migration alone was not enough.

The new read paths needed old production data to make sense inside the new payment model. That meant historical orders had to be backfilled into the new tables in a way the current code could actually use.

There were two things I absolutely did not want to break:

historical backlinks access
historical paid-amount continuity for product upgrades

I tested the backfill locally against production snapshots before touching live production.

That helped answer the key question:

Could the old data safely reconstruct exact historical upgrade transitions?

Not reliably.

Legacy order rows could safely tell me:

this user bought backlinks access
this product had a paid submission
this product had this historical paid total

What they could not always tell me, with enough confidence, was the exact boundary between an original submission and a later upgrade in every case.

So I kept the backfill conservative.

I backfilled what I could defend. I refused to invent precision that the old data did not actually contain.

A clean new schema built on guessed history is still guessed history.

The one thing that broke

There was exactly one real hiccup during the window.

The first run of 0040_backfill_order_to_payment_domain.sql failed.

The data was fine. The logic was fine. The problem was operational: D1 remote execution rejected the explicit BEGIN TRANSACTION / COMMIT wrapper in the SQL file.

That was survivable because the release was already set up to absorb surprises:

write freeze was still on
the backup already existed
nothing was forcing me to reopen writes early

So I removed the explicit transaction wrapper, reran the migration, and it completed cleanly.

No rollback. No restore. Just a contained operational fix.

That is the kind of surprise I am willing to accept in production. Not "nothing went wrong", but "something went wrong and stayed small".

The database gate was the real release gate

I did not consider the release done because the migrations stopped erroring.

I considered it done only after the database proved that the migration had preserved what mattered.

The gate looked roughly like this:

comment counts still matched
no orphaned comment relationships existed
no leftover expedition or admiral rows remained
payment_order count matched legacy order count
migrated purchase count matched expectations
active backlinks purchases matched the old paid backlinks count
a known historical backlinks buyer still resolved correctly
a known paid product still reported the exact same historical paid total under the new model

I also kept write freeze enabled while checking public routes:

homepage
product detail
explore
blog
RSS
sitemap

The site stayed readable the whole time, which was the goal from the start.

Only after the database gates passed did I flip write freeze back off and deploy the final version.

What users actually care about

From the outside, this could be described as infrastructure work.

That is true, but incomplete.

Users do not care that I created payment_order and purchase.

They care that:

paid access still works
previous payments still count
comments still load
upgrades make sense
the platform feels stable

The invisible part is what makes the visible part credible.

What I took away from it

The biggest lesson is the obvious one: if a release needs a maintenance switch, build the maintenance switch before release day.

The second lesson is that production always gets the last word. If the live database says an old tier is still there, then it is still there, no matter how tidy your migration history looks in Git.

The third lesson is that conservative backfills are underrated. When historical data cannot safely reconstruct perfect semantics, preserve runtime correctness first. Do not make up a cleaner story for the database than the source data can support.

And maybe the most important lesson is this:

The release is not the migration script.

The release is the gates.

Backups, baselines, validation queries, smoke tests, and the discipline not to reopen writes early just because you are tired.

That was the part that made a 24-minute maintenance window possible without turning it into a full outage.

Building Shipstry: 640 Commits, 9 Days, One Launch

rokcso — Thu, 26 Mar 2026 09:13:20 +0000

On March 3, 2026, I started with an empty folder. On March 11, 2026, Shipstry went live.

In between: 640 commits, countless cups of coffee, and a lot of lessons learned about building on the edge.

This is the story of how I built it, the technical decisions I made, and what I learned along the way.

The Name

Before writing a single line of code, I needed a name.

I spent an entire afternoon brainstorming with AI. I must have asked for hundreds of suggestions. The AI probably hated me by the end of it.

I wanted something that captured the essence of what makers do — we ship products. And I wanted it to feel like a registry, a place where products are officially recorded and discovered.

Ship + Registry = Shipstry

It sounded nautical, it felt right, and the .com was available. Done.

The nautical theme evolved into something more organic:

Primary color: Olive Moss (#6B8A67)
Accent: Warm Sand (#D4A574)
Pricing tiers: Harbor, Voyage, Expedition, Admiral
The logo: a geometric sailboat with twin sails

The Why

After launching several side projects over the years, I kept running into the same problem: Product Hunt is great, but it's not built for indie makers anymore.

Big-budget launches dominate. Marketing teams game the algorithm. Great products from solo developers get buried in hours.

I wanted something different:

A place that celebrates builders, not marketers
Weekly cycles instead of daily chaos
Quality over quantity
Built by a maker, for makers

So I built Shipstry — "The Launch Registry."

The Stack Decision

Before writing code, I spent time on stack selection. This is the most important decision you make at the start of a project — it will haunt you for months if you get it wrong.

I chose:

TanStack Start for the framework. It's a full-stack React framework with file-based routing and excellent TypeScript support. The type safety is incredible — if you change a route, the compiler tells you everywhere that needs updating.

Cloudflare Workers for deployment. Edge computing means my users in Singapore, London, and New York all get the same fast experience. No cold starts, global distribution.

Cloudflare D1 for the database. It's SQLite at the edge. Yes, SQLite — the same database that powers your phone, now running in 300+ locations worldwide. For a product like Shipstry, it's perfect.

Cloudflare R2 for file storage. When users upload product logos and preview images, they go here. It's S3-compatible but with zero egress fees, which means I don't have to worry about surprise bandwidth bills.

Better Auth for authentication. Email/password plus Google OAuth, and it integrates natively with TanStack Start.

Stripe for payments, Resend for emails, Tailwind CSS v4 for styling, shadcn/ui for components.

The key insight: TanStack Start + Cloudflare is a powerful combination. You get React's ecosystem with edge performance, and D1 gives you a real database with zero configuration.

The First Week

Day 1-2: Foundation

The first commits set up the entire foundation — TanStack Start with SSR, Cloudflare Workers adapter, Drizzle ORM, basic routing structure.

I also built the design system. I didn't want another generic AI landing page with purple gradients. I created a custom "Olive Moss" palette — muted greens and warm grays that feel organic and calm.

By end of Day 2, I had a working dev server, a distinctive visual identity, and basic page layouts.

Day 3-4: Authentication

Authentication is always more complicated than you expect.

Better Auth needs to create its auth instance per-request, not as a singleton. In Cloudflare Workers, each request is isolated anyway, so this architecture actually works well. But figuring that out took a few hours of head-scratching.

I also designed the database schema upfront. The key decision: separating drafts from products.

Drafts have all nullable fields — users can save at any point in the submission flow and return later. Products have required fields — they only exist when fully submitted. This kept the data model clean and the code simple.

Day 4-5: The Submission Flow

The submission form is the heart of Shipstry. I wanted it to feel smooth, not overwhelming.

I built a progressive form with collapsible sections. Each section tracks its completion status. Users can save at any point, leave, and pick up where they left off days later.

For the product description, I integrated Milkdown — a plugin-driven Markdown editor with a custom toolbar. The tricky part was focus management: the toolbar kept stealing focus from the editor. I eventually fixed it by preventing default on mousedown for toolbar buttons.

Day 5: Pricing and Payments

I designed a nautical-themed pricing system:

Harbor (Free): Basic submission, normal review
Voyage ($9.9): Fast 24-hour review, same-week ship
Expedition ($29): Featured on homepage, 7 days exposure
Admiral ($59): 30 days featured, premium badge

Stripe integration was straightforward, but the webhook handler needed careful attention. D1 doesn't support nested transactions, so I had to restructure the code to use sequential queries instead of wrapping everything in a transaction.

The AI Feature

Filling out product forms is tedious. Users paste a URL and then have to manually enter the name, tagline, description, logo, preview image...

So I built an AI-powered metadata fetcher.

When a user pastes their product URL, the system:

Fetches the page and extracts Open Graph tags
Sends the information to AI to generate an enhanced, compelling description
Auto-fills all the form fields

The user can review and edit everything before submitting. It's not about replacing human input — it's about reducing friction.

Multi-Provider Failover

AI APIs are unreliable. They timeout, they rate limit, they have outages.

I built a failover system that tries multiple AI providers in priority order. If one fails, it automatically tries the next. The configuration is a simple JSON array in environment variables:

[
  {"name": "openai", "priority": 1},
  {"name": "claude", "priority": 2},
  {"name": "gemini", "priority": 3}
]

If all providers fail, the form still works — users just fill it manually. Graceful degradation is key.

SSRF Protection

Allowing users to fetch arbitrary URLs is dangerous. You don't want someone hitting your internal services through your server.

I implemented multiple layers of protection:

Block private IP ranges (10.x, 172.x, 192.168.x)
Block localhost
Only allow HTTP and HTTPS protocols
Rate limit: 5 requests per minute per user

The Community Features

Comments and Voting

Comments support nesting — users can reply to replies. I used soft deletes instead of hard deletes, so if a parent comment is removed, the threading structure stays intact.

For voting, I wanted instant feedback. Nobody wants to wait for a server round-trip to see their vote register.

I implemented optimistic updates: when you click vote, the UI updates immediately. The server request happens in the background. If it fails, the UI rolls back. This makes the app feel snappy and responsive.

Notifications

Users get notified for:

Comments on their products
Replies to their comments
Award wins (weekly and monthly)
Product status changes (approved, rejected)

For email delivery, I used Cloudflare's waitUntil() function. This sends the response to the user immediately while the email sends in the background. The user doesn't wait for the email to send.

The Final Days

Caching

To reduce database load, I built a caching layer using D1 itself as the cache store. Cached data has TTLs, and mutations trigger automatic cache invalidation.

This pattern dramatically reduced read load on the main tables during high-traffic periods.

Environment Configuration

I centralized all environment variables with validation. In development, the app validates that all required secrets exist and throws clear errors if something is missing. In production, I trust that Cloudflare has the secrets configured.

This caught several configuration mistakes during development that would have been painful to debug in production.

Launch

On March 11, 2026, Shipstry went live.

The final commits added a launch promo banner with a 50% discount code, and adjusted the ship week logic to allow immediate launches during the launch period.

What I Learned

TanStack Start is ready for production. The framework is stable, well-typed, and SSR works seamlessly with Cloudflare Workers.

D1 is good enough. SQLite at the edge sounds limiting, but for most applications, it's perfect. Zero configuration, fast queries, generous free tier. The main gotcha is no nested transactions.

Edge functions change how you think. No global state, waitUntil() for background tasks, zero cold starts, environment access through imports rather than process.env.

AI integration is easier than expected. With the right abstraction — multi-provider failover and graceful degradation — you can build reliable AI features.

640 commits in 9 days. That's roughly 71 commits per day. Each commit was small, focused, and reversible. The discipline of atomic commits saved me multiple times when I needed to roll back a bad decision.

What Happened After Launch

Shipstry has been live for two days.

In that time, I've been doing link building — submitting to directories, reaching out to communities, getting featured on various platforms.

The results? DR went from 0 to 14 in two days.

Built with TanStack Start, Cloudflare Workers, D1, R2, and too much coffee.