How We Ship Every Day with AI

We ship something every day. Not every day has a major feature. Most days it's an improvement, a fix, a clarification. But every day, there's a deploy with something new in it.

This culture didn't happen by accident. It's built on specific practices and enabled by specific tools. Here's what actually makes it work.

Why Daily Shipping Matters#

The feedback loop is everything. When you ship daily:

• Users see improvement continuously instead of in lumps
• You find bugs faster (the gap between "when this was written" and "when it fails" is one day)
• You maintain the habit and confidence of shipping
• Investors can see momentum

Paul Graham says the best thing about being a startup is speed. Daily shipping is the concrete manifestation of that.

The constraint that makes this possible: everything that ships must be in a releasable state. No half-finished features, no temporary workarounds that degrade the experience. Every commit represents the full intended state of that change.

The gstack Workflow#

We use the gstack workflow for anything non-trivial. This is a structured SDLC adapted from Garry Tan's open-source gstack:

Think → YC office hours-style review: is this the right problem?
Plan (CEO) → First-principles thinking: what are we optimizing for?
Plan (Eng) → Architecture and implementation plan before touching code
Plan (Design) → UX review before touching code
Build → Implementation against the locked plan
Review → Staff engineer review of what was built
Test (QA) → Running and finding bugs before they reach users
Test (Perf) → Performance check
Ship → Commit, PR, merge

This sounds like overhead. It isn't, for two reasons:

1. Most of these phases take 10-30 minutes with AI assistance
2. The cost of the wrong design caught before implementation is much lower than the cost of the wrong design caught after

For small changes (a bug fix, a text update), we skip most of this and just ship. The gstack workflow is for features and anything that touches the core data model.

How AI Removes Friction from Each Phase#

Planning: We describe what we want to build in natural language to Claude. It generates a technical implementation plan that we review and amend. This takes 20 minutes instead of 2 hours.

Building: Cursor handles the implementation. For known patterns in our codebase, the AI writes the code and we review it. For novel problems, we do more of the writing with AI assistance.

Review: The staff engineer role in gstack is played by Claude with a review prompt. It finds bugs that are classically hard to catch in self-review — edge cases, off-by-one errors, missing error handling.

QA: We run the feature in our local DenchClaw instance and deliberately try to break it. AI helps by generating test scenarios we might not think of: "What are 10 edge cases for this feature that might fail?"

PR description: AI generates the PR description from the commit diff and our notes. Takes 2 minutes.

The total time from "decision to build X" to "X is in production" for a medium-sized feature: 4-6 hours for two people. Before AI tooling, this was 2-3 days.

The Daily Ritual#

Our daily shipping ritual:

1. Morning standup (15 minutes): what are we building today?
2. Build session (3-4 hours each): using the gstack workflow
3. Code review (30 minutes): each person reviews the other's work
4. Deploy (15 minutes): merge, CI passes, deploy
5. Quick verification in production (5 minutes)

That's a workday with a ship at the end.

What Makes This Sustainable#

Daily shipping is sustainable when:

• The codebase has good test coverage (breaking changes get caught, not deployed)
• The deployment pipeline is fast (under 5 minutes to production)
• Features are scoped small enough to complete in a day

The feature scoping is the hard discipline. It's easy to start building something that's "one more day" from done for a week. The practice of breaking features into one-day increments forces clarity about what's actually essential.

Ask: "What's the smallest version of this feature that's useful?" Ship that. Iterate.

Frequently Asked Questions#

How do you avoid shipping broken things?#

Tests + code review + manual verification before merge. The three layers catch different things. Tests catch regressions. Code review catches logic errors. Manual verification catches UX issues that don't manifest in tests.

What's the smallest useful thing to ship on a slow day?#

A documentation update. A fix to confusing error messages. A small UX improvement. A performance optimization. "No code changed" days are okay if you shipped documentation, but they should be rare.

How do you maintain daily shipping when you're in a fundraise?#

You don't always. Fundraising compresses your available building time significantly. The expectation should be weekly shipping at minimum during active fundraising, not daily. After the round closes, recover the daily cadence.

Does daily shipping conflict with deep technical work?#

For genuinely long refactors (migrating to a new data model, rearchitecting a core component), you ship the intermediate states. Each step of the migration is its own commit. This takes more planning but maintains the shipping cadence.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →