The 48-Hour Ship Cycle: My Actual Workflow from Concept to Deployed Product

People ask me how I ship so fast. The answer isn’t talent or caffeine — it’s process. A repeatable 48-hour cycle that takes a product from “I have an idea” to “it’s live and people are using it.” The cycle works because every step is optimized for speed without sacrificing quality.

Here’s the exact breakdown, hour by hour.

Hours 0–4: Define the Wedge

I don’t start with a feature list. I start with the wedge — the single, specific problem this product solves better than anything else. Not “project management” but “tracking design feedback across Figma frames.” Not “AI writing tool” but “generating accessible alt text from screenshots.”

The wedge exercise takes 30 minutes: write one sentence describing what the product does, who it’s for, and why they’d use it today. If I can’t write that sentence clearly, the idea isn’t ready.

The remaining 3.5 hours go to research. I search for existing solutions, test them, document what they get wrong, and identify the gap. This research becomes the product’s positioning and informs every design decision that follows.

Hours 4–10: Design in Code

I skip traditional wireframing for 48-hour cycles. Instead, I design directly in the browser using Next.js and Tailwind CSS. The “design” is production code from the first line.

I start with the core screen — the one view that delivers the wedge. If it’s a dashboard, I build the dashboard. If it’s a form flow, I build the first form. No navigation, no settings, no profile page. Just the core value proposition rendered in a browser.

Tailwind makes this fast because I’m not context-switching between a design tool and code. A flex items-center gap-4 px-6 py-3 bg-white rounded-xl shadow-sm is both the design spec and the implementation. Change it in one place, see it in the browser instantly.

By hour 10, the core screen looks and feels like a finished product. It has real typography, proper spacing, hover states, and responsive behavior. It just doesn’t do anything yet.

Hours 10–24: Build the Engine

This is where AI-assisted development earns its keep. I use Cursor with Claude to build the backend logic: API routes, database schema, AI integrations, and data processing.

My approach: describe the data model in a types file, then ask the AI to generate the API route that serves it. Review every line. Adjust. Move to the next route. Because my files are small and my concerns are separated, the AI generates accurate code on the first try 80% of the time.

Database: PostgreSQL with Drizzle ORM. I define the schema in a single file (under 100 lines for a new product), run the migration, and the database is ready. No ORM magic, no abstraction layers — just SQL that I can read and understand.

AI integrations: I call model APIs directly. No LangChain for simple products — it adds complexity without value when you’re just sending prompts and parsing responses. For multi-agent products, LangGraph handles the orchestration.

By hour 24, the product works end-to-end. You can interact with it, data persists, AI features produce real results. It’s ugly in places. Some edge cases aren’t handled. But the core loop works.

Hours 24–40: Polish and Edge Cases

This is where most people stop. “It works, let’s ship.” No. A product that works but feels rough generates negative word-of-mouth. Users don’t say “it works but the loading state is missing.” They say “it felt janky.”

I spend 16 hours on polish:

• Loading states: Skeleton screens, not spinners. Every async operation has a visible loading state.
• Empty states: Helpful messaging when there’s no data. “No projects yet — create your first one.”
• Error handling: Graceful degradation. If an AI call fails, show a retry option, not a crash.
• Responsive design: Test on mobile. Fix the three things that break. Don’t over-engineer for every viewport.
• Keyboard navigation: Tab through the core flow. Fix focus traps and missing indicators.
• Animation: Subtle transitions on state changes. Page transitions. Hover effects. Under 200ms each.

Hours 40–44: Deploy and Test

Deploy to Vercel. Connect the domain. Set environment variables. Run through the entire flow on the live URL. Test on a real phone. Fix the two things that look different in production.

I don’t write automated tests during a 48-hour cycle. Controversial, I know. But the product will change dramatically in the first week based on user feedback. Tests for the wrong features are wasted effort. I add tests once the core experience stabilizes.

Hours 44–48: Launch Content

The last four hours go to launch content: a clear landing page (often the product itself), a LinkedIn post documenting what I built and why, and a direct message to five people in the target audience asking them to try it.

No Product Hunt launch. No Twitter thread with 47 screenshots. Five real users who will actually use the product and give honest feedback. That’s the goal for day one.

Why This Works

The 48-hour constraint forces ruthless prioritization. There’s no time for features nobody needs. No time for architecture astronautics. No time for bikeshedding over button colors. You build the wedge, polish the experience, and ship.

The products I’ve shipped this way aren’t perfect. They’re intentionally minimal. But they’re real — live, deployed, with actual users providing actual feedback. That feedback is worth more than a month of planning would have been.

Perfect is the enemy of shipped. Shipped is the beginning of learning.