How to Build: Ship Fast, Refactor Never

The boring stack always wins.

Every Hacker News thread about "what should I build my SaaS on" generates 200 comments and zero signal. Founders spend a weekend reading them and come away convinced they need Rust, or Bun, or whatever just shipped. If you're thinking about Rust, you're not thinking about your customer.

The stack that ships products is Next.js + Supabase + Stripe + Vercel. Add a Cloudflare in front of it and a Resend for email. That's it. That stack covers 80% of what a SaaS company needs for the first 18 months — auth, database, payments, hosting, file storage, transactional email, analytics. None of it is impressive in a tech-Twitter sense. All of it works on day one.

Why this stack specifically? Vercel deploys Next.js without configuration. Supabase gives you Postgres, auth, and row-level security in a single dashboard. Stripe Checkout is the only payment integration that doesn't take 3 weeks. Each piece is best-in-class for early-stage, and they all compose. The combined documentation answers 99% of the questions you'll have in your first month.

The temptation to be clever is what kills early companies. I see founders pick Astro because it's faster. Or Convex because it's elegant. Or Postgres on bare metal because they once read a Twitter thread about latency. None of these decisions are wrong in isolation. They're wrong because they're upstream of building anything customers care about. Premature framework decisions are the most expensive form of procrastination, because they look like work.

The boring stack wins because nothing about it is the bottleneck. You can pour 12 weeks of feature work onto Next.js + Supabase before you start hitting real architectural choices. By then, you have customers and revenue, and the choices become tractable. Until then, you have nothing — and zero scale problems.

Don't write your own auth, payments, or DNS.

Every founder, at some point, considers writing their own. Auth seems simple — it's just hashing a password, right? Payments seem simple — it's just charging a card, right? DNS seems simple — they're just records, right?

None of these are simple. Each one is 6 months of engineering effort that adds zero value to your product. Customers don't choose you because your auth is custom. They tolerate auth, the same way they tolerate a back button. The only auth UX that matters is the one where they don't have to think about it.

Use Supabase Auth for sign-up, sign-in, OAuth, magic links, password reset, MFA, session management, and row-level security. It's free for the first 50,000 monthly active users. It handles the security audit, the OWASP edge cases, the password rotation logic, and the GDPR-compliant deletion. None of which you should be writing yourself.

Use Stripe Checkout for paywalls, trials, subscriptions, one-off purchases, refunds, dunning, tax, and invoicing. The hosted checkout page converts better than 90% of custom payment forms — Stripe has run more checkout A/B tests than your company will ever exist long enough to run. The only reason to embed payment forms inline is if you're at 8-figure ARR and 0.5% conversion lift is worth the engineering cost. You're not, yet.

Use Cloudflare for DNS, CDN, WAF, DDoS protection, and free SSL. The "I'll just use Route53" instinct adds latency, costs more, and gives you fewer security features. Cloudflare's free tier is more than you need.

Each of these is a multi-billion-dollar company because building this infrastructure is hard. Let them do their job. You do yours: shipping product to customers.

Ship a pricing page on day 1, even if it's a lie.

The pricing page is the most important page on your site. It's the page that converts traffic to customers. It's also the page that forces you to be honest about what you're selling.

Most founders avoid the pricing page because pricing is hard. They tell themselves they'll figure it out later, after they have signal. This is backwards. Building the pricing page is how you get signal. The act of writing tier names, picking a value metric, and listing features per tier surfaces every fuzzy decision in your product strategy. If you can't fill out the pricing page, you don't know what you're building yet.

Ship one anyway. Hide the actual prices behind "contact sales" if you have to. Just have a page that lists 3 tiers with names, target users, and feature lists. The mere existence of the page lets you measure intent — % of visitors who reach pricing, % who click a tier, % who reach checkout. These numbers tell you whether your positioning is working long before revenue does.

If you charge anything, the page reveals which tier is the wedge. Most companies guess wrong on launch. The free tier you thought was the wedge is empty; the mid-tier you thought was a stretch is where 80% of revenue comes from. You can't see this without a real pricing page collecting real signal.

A pricing page also forces clarity in marketing. The headline above pricing has to say "$X per Y, get Z." That's the value proposition, compressed. If you can't write that headline, you don't have one. You'll figure out you don't have one approximately 4 months earlier than founders who avoided this conversation.

Ship the page on day one. Iterate the prices weekly. Don't wait.

Deployment is the product (until it isn't).

Continuous deploy from day 1, no exceptions. Every push to main goes to production. If pushing to main doesn't auto-deploy, fix that before writing more code.

Why this matters: in the first 12 weeks, you'll deploy 200+ times. Maybe 500. Each deploy is either friction or it isn't. If you have a deploy ritual — push to main, run a script, SSH somewhere, restart a process — every single ship slows down. The friction compounds. By week 4 you stop shipping small changes. By week 8 you batch up 3 days of work into one deploy because the ceremony feels too heavy. By week 12 you're a fundamentally slower company than the one that auto-deploys.

Vercel solves this by default for Next.js. Push to main, it deploys, the URL is live in 90 seconds. You'll never beat that with custom infrastructure. Use it.

The same applies to preview deploys — every PR gets its own URL. This sounds like a luxury until you have a co-founder, a designer, or a customer giving feedback. Sharing a link is 10x better than sharing a screenshot. It's the difference between "looks good" and "I clicked through three pages and the third one is broken."

Deployment friction is the cleanest example of compounding waste. The 30 seconds you save per deploy adds up to hours per month, weeks per year. More importantly, it changes your willingness to ship. Slow deploys make you batch. Batched deploys hide bugs. Hidden bugs hurt customers. The whole problem unravels from one bad config decision in week 1.

Get this right early. After you've shipped 100 deploys without thinking about deploys, then start thinking about whether you need staging environments, blue/green, feature flags, etc. Until then, the answer is no.

When to refactor: almost never.

Refactoring is procrastination disguised as productivity. It feels like work. It produces clean code. The team looks busy. The customer experience does not change.

I've worked with founders who spent 6 weeks refactoring a 2-week-old codebase. They got a beautiful module structure and zero new customers. The refactor was sincere — they really thought it was holding them back — but the actual bottleneck was a sales problem, and rewriting the auth module in TypeScript-strict mode wasn't going to fix it.

Ship the ugly version. Your first version will be ugly. Mine were too. Functions will be too long. Files will be in the wrong place. There will be a 400-line page component that should be split. Leave it. The cost of uglies in early code is astonishingly low — almost nobody else is reading it, and the parts that need to evolve will get rewritten anyway when you actually understand the domain.

Refactor only when adding the 3rd feature to the same module. This is the rule I follow. The first feature defines the structure. The second tests it. The third reveals where the abstractions actually want to be. Before the third, refactoring is guessing — you're optimizing for a future shape you can't yet see. After the third, the right shape is obvious, and the refactor is mechanical.

Never refactor before you have 100 paying customers. This isn't because the code doesn't deserve it. It's because the team can't afford it. With under 100 customers, every engineering hour should be aimed at making one of two numbers go up: signups or revenue. Refactoring moves neither in week one. Maybe in month 18 it pays off, but you don't have 18 months — you have a runway and a deadline.

The right time to write clean code is when the messy code is actually slowing you down. Until then, mess is a feature. Ship.