How I Shipped 4 Full-Stack Platforms in 25 Days

Between day 1 and day 25 I shipped four full-stack platforms: my own site with an admin CRM, a Nepali news platform migrated off WordPress, an agent directory, and a gaming backend for a US client. Same core every time — Next.js, Supabase, Vercel, built with Claude Code. What made 25 days possible was not typing speed. It was scope refusal: one build sequence I never re-decided, one schema shape, one auth model, and a written list per project of what it would not have. Here is the day ledger, the cut list, and the failures the sprint produced.

What actually shipped

Four things went live. They were not four equivalent things, and calling them all "platforms" flattens a real difference in depth, so here is the honest column.

Days 23 to 25 were an SEO pass across all four at once, which is the part I would move to day 1 if I ran it again.

Two honest labels before anyone reads that table as four equal launches. The gaming backend is the only one with a paying client attached. agenticai01.tech deployed and works, but the marketplace mechanics around it — billing, sandboxing, moderation — were never built, so treat it as an architecture that shipped rather than a product that shipped.

The ledger, run against the calendar

The tidy version of this story is that each platform got cheaper as I reused the last one. My own log does not support that. Here is the arithmetic, as a script you can run:

# build_ledger.py - my own sprint log. Inclusive day ranges, as published.
BUILD = {
    "santoshpaudel.me":  (1, 5),
    "TheWestNepal.live": (6, 7),
    "agenticai01.tech":  (8, 15),
    "gaming backend":    (16, 22),
}
SHARED_TAIL = (23, 25)  # SEO pass run across all four at once

def days(span):
    start, end = span
    return end - start + 1

tail = days(SHARED_TAIL)
share = tail / len(BUILD)

rows = [(name, days(span), days(span) + share) for name, span in BUILD.items()]
assert sum(r[1] for r in rows) + tail == 25, "sprint must add up to 25 days"

print(f"{'platform':20}{'build':>7}{'loaded':>9}")
for name, build, loaded in rows:
    print(f"{name:20}{build:>7}{loaded:>9.2f}")

first = rows[0][1]
rest = [r[1] for r in rows[1:]]
print(f"\nfirst platform:        {first} days")
print(f"mean of the other 3:   {sum(rest) / len(rest):.2f} days")

It prints a first platform of 5 days and a mean of 5.67 days for the three that followed. Reuse did not make later builds cheaper on average. One build got dramatically cheaper — the news site, 2 days, because it was the same shape as something I had just finished. One got more expensive — the agent directory at 8 days, because multi-subdomain routing across two hosting providers was new to me.

The variable is not "how many times have you used this stack." It is "how many decisions in this project are ones you have already made."

Why the speed came from scope, not tooling

One sequence, never re-decided

Every project ran in the same order: schema, scaffold, Supabase wiring, admin panel, content, SEO, deploy. I never spent a morning deciding what to do next, because the order was fixed before the sprint started. That is unglamorous and it is most of the saving.

The fast path on this stack is genuinely fast — I timed it stage by stage in full-stack SaaS in 2 hours, and the live authenticated app really does take about 85 minutes. What the timer does not capture is row-level security, three states per screen, and email deliverability, which is where days go.

The reuse was in the schema, not the components

I expected to reuse components. I mostly did not — layouts differed too much. What transferred was the data layer: the same table shape for content, the same auth guard pattern, the same environment variable names. The admin panel structure carried across all four almost unchanged, and I have written that structure up separately in how I structure a Supabase and Vercel admin panel.

If you copy one thing from this post, copy the schema conventions, not the UI.

What the evidence actually says about AI and speed

I want to be careful here, because "AI made me 4x faster" is exactly the kind of unsourced claim this blog is full of and I am trying to stop writing.

The best controlled evidence points the other way. METR ran a randomized trial with 16 experienced open-source developers across 246 real issues in their own repositories, and found that "when developers are allowed to use AI tools, they take 19% longer to complete issues" (METR, July 2025). The same developers estimated afterwards that they had been sped up by 20%. That gap is the finding, and I have no reason to think I am exempt from it.

The 2025 DORA report, surveying nearly 5,000 technology professionals, found AI adoption positively related to delivery throughput but still negatively related to stability, and framed the cause plainly: "AI accelerates software development, but that acceleration can expose weaknesses downstream" (Google Cloud, 2025).

That matches my sprint. Throughput was real. Stability was the bill, and I paid it later. The multi-project side of the workflow — the part that stops projects bleeding into each other — is in my Claude Code and Antigravity workflow.

The cut list

Cuts are the load-bearing part of a 25-day sprint, so here they are without softening.

No test framework, on any of the four. Verification on my own site is still npm run build plus loading the affected page. That is not a recommendation. It is a debt I took knowingly and have not repaid, and it is the direct cause of the instability DORA describes.

No scheduler. Booking is a Calendly embed. Building a calendar with availability, timezones and reschedule links is a week I did not have.

No mail infrastructure. Resend, a verified sending domain, done. Deliverability is somebody else's operations problem.

No API layer for reads. Public pages query Supabase directly in server components. Fewer files, fewer hops, one less thing to keep in sync. If I ever need per-request auth on public data this decision breaks, and I will rewrite it then.

The cut I still defend: agents propose, they do not write

The site runs an autonomous agent system on a cron trigger. It has never written a row to a live business table, and that was deliberate. Every tool that touches a business table ends the same way — an insert into pending_actions with status: 'pending', waiting for me:

// lib/agent-tools.ts
const { data, error } = await db
  .from('pending_actions')
  .insert({
    run_id: runId,
    agent_slug: agentSlug,
    action_type: 'create_blog_post',
    payload: { title, slug, excerpt, content, tags },
    status: 'pending',
  })
  .select('id')
  .single()

return JSON.stringify({
  queued: true,
  pending_id: data.id,
  message: 'Blog post submitted for approval.',
})

Ten minutes of extra work per tool. It means a bad model day produces a queue I ignore instead of pages I have to unpublish. The reasoning is in why my AI agents get an approval queue, not write access.

What the speed actually broke

279 posts, 22 clicks

This is the failure that matters, and it is measured, not felt. Over the 85 days to 3 September 2026, santoshpaudel.me recorded 22 clicks from 4,553 impressions — a 0.48% click-through rate across roughly 390 indexed URLs.

The corpus is 279 posts. About 150 of them average 380 words with no table, no code, no internal links and no image. Across the seed files the corpus carries about 1,120 H2 headings and fewer than 40 H3s, which is what a flat, unstructured library looks like from the outside.

The split inside that data is unambiguous. Posts that are build logs or worked arithmetic rank between positions 2.8 and 15.5. Posts titled "[industry] content marketing" rank between 46 and 81. Same author, same domain, same quarter. Volume did not rank. Specificity did.

Shipping four platforms in 25 days taught me a build sequence. Shipping 279 posts taught me that the same sequence applied to content produces a large amount of nothing.

Two admin modules nobody has ever used

app/admin/hrm and app/admin/pos exist, are wired to real Supabase tables, and have never been used for anything. I built them because they were easy to build once the admin shell existed, which is the worst possible reason. They are still in the repo, still in the type-check, still in my head every time I open that directory.

SEO arrived on day 23

On the first platform I added sitemaps, schema and meta tags at the very end — roughly six hours of cleanup that automation would have handled for free. By the third project it was scaffolded on day one, which is the setup I wrote up in auto sitemap, schema and robots in Next.js.

Worse: I also shipped the wrong canonical hostname, and that one cost three months of indexing before I noticed. That story is its own post-mortem.

What I would change with the same 25 days

• —Day 1 is SEO scaffolding and the canonical hostname, before the first content page exists.
• —One test per money path, per project. Not a suite. One.
• —Write the cut list before the schema, not after the deadline slips.
• —Publish four deep posts instead of forty shallow ones. The Search Console data above is not ambiguous about which one works.
• —Delete a module the week it becomes clear nobody uses it.

Frequently asked questions

How long does it take to build a full-stack site with Next.js and Supabase? My own range across four builds was 2 to 8 days for something live and usable, and the variation was driven almost entirely by how many decisions were new, not by the stack. The 2-day build was a rebuild of a shape I had just finished. Add the hardening tail — RLS, error states, email — before you quote anyone a number.

Can one developer really ship four platforms in 25 days? Yes, with two caveats I would insist on. They will not be four equally deep products — mine were not. And the acceleration is real at build time and gets billed back later in testing and stability, which is what the 2025 DORA data describes.

Did AI coding tools make this possible? They compressed the distance from decision to running code. They did not make the decisions, and the controlled evidence on speedup is genuinely mixed — the METR trial found experienced developers 19% slower with AI on their own repositories. What removed weeks from my sprint was a fixed build sequence and a written cut list, and both work without any AI at all.

What would you not attempt in 25 days? Anything with money movement, real multi-tenancy, or a compliance surface. The wallet layer in the client project was the one piece where I slowed down deliberately, and I would slow down further next time.

Want a build sprint scoped so the cut list is written before the deadline? I will tell you in one call what four weeks can realistically ship and what it cannot. See my services or get in touch.