The 3-day SaaS: what shipping daily looks like at month 1

Plyrium started on April 25, 2026. By April 28 we had a working sign-up flow, a Stripe checkout, a portal, and the first version of the AI receptionist. By May 9 we had paying customers, recurring billing, a marketing site, and a tech mobile app. Today is May 27 and we've shipped something every day for 33 straight days. Here's what that's actually like.

The shipping cadence is the part of Plyrium that surprises people most. Not the product surface — every SaaS in 2026 is a sprawling thing. The cadence. We push to production roughly 3-7 times per day. We release a feature meaningful enough to mention to customers roughly twice a week. The Academy you're reading this on shipped its CMS rewrite in 3 days. The Forge desktop app (a separate product) is at version 1.3.14 after 7 days of public release.

Some of that is leverage. Some of it is the deliberate decisions we made on day one. None of it is sustainable forever, and we're already thinking about what slows down when the codebase doubles in size again. Here's an honest look.

What enables it

One operator, modern tools, zero meetings

The single biggest accelerant is also the most boring: there is one person making product decisions and writing all the code. No standups, no PRDs, no design reviews, no Slack threads about whether a button should be 4px wider. The decision-to-code latency is roughly 30 seconds.

This obviously doesn't scale past one person. We're not pretending it does. The model we're optimizing for is "stay solo as long as the cadence holds, hire only when the bottleneck is unambiguous." For now the bottleneck is genuinely "how fast can I think and type." Adding a second engineer right now would make things slower, not faster, because they'd need ramp-up time on a codebase that's still moving 30 commits per day.

Default-deploy-to-staging-first

Every push goes to staging first. Staging deploys are free of customer impact, so we can push aggressively (4-6 staging deploys per day) without ever risking production. When something is staging-green for an hour with no Sentry errors and a smoke-test pass, it gets merged to main and ships to production.

This is the single hardest discipline to maintain. The temptation to "just push the one-line fix to main" is constant. We hold the line because every time we don't, something breaks 6 hours later in a way that's harder to undo than the friction of waiting an hour for staging.

The Ops Board IS the roadmap

There's no separate product backlog tool. The board at /ops inside Plyrium is both the customer-facing ticket queue AND the internal product roadmap. Bugs, features, ideas, customer asks all flow through the same surface. When you're shipping at this cadence, you can't afford to have the source-of-truth roadmap in a different system from the actual work queue — drift creeps in within a week and you ship the wrong thing.

Aggressive logging from day one

Sentry was wired up in week 2, not month 6. Every API route logs the request, every webhook has audit history, every cron job tracks its last run. The cost in code is maybe 4-6% overhead per route. The benefit when something breaks in production is huge — you can usually find the root cause in 5 minutes instead of 5 hours.

What it costs

It's not free. Three real costs we pay for this cadence:

Documentation lags ship date by 1-2 weeks

We have a hard rule: every feature ships with a KB article. We mostly hit it, but "mostly" means about 70% of features have the article live within 48 hours, and 30% are written 1-2 weeks later. The remaining 30% creates a small support overhead — customers find a feature, can't find the docs, email us, we send the link in real-time. Works for now at our customer count; won't work at 10x.

Test coverage is below what most engineering shops would tolerate

We have integration tests for the high-stakes flows (signup → Stripe → portal, webhook ingestion, billing edge cases). We don't have unit-test coverage of every utility function. The combination of "TypeScript strict mode + small codebase + same engineer who wrote it deploying it 30 minutes later" gets us most of the safety net at a fraction of the maintenance cost. This will change as the team grows, but it's the right tradeoff right now.

Some features get shipped slightly raw

The version-1 of a feature usually has 1-2 obvious polish issues we'll fix in the next push. We've made peace with this. The alternative — wait an extra 3 days to polish before shipping — means the customer who needed it now gets it later. Shipping at 92% polish today beats shipping at 99% polish in a week, for almost every feature.

What it changes about the product

Three things customers notice that we wouldn't be able to do at slower cadence:

1. You can request a feature and have it shipped same week. Genuinely. We've shipped customer-asked features inside 4 hours when the ask was clear. The flip side: the longer something sits in the backlog, the less likely it is to ship at all, because something newer and more urgent always shows up.

2. The product looks meaningfully different every 30 days. Customers who signed up in week 1 came back in week 4 and didn't recognize half the surfaces. We try to communicate this through the changelog so people don't feel like we're moving their cheese silently.

3. Bugs get fixed in hours, not weeks. This is the biggest gap between us and the established competitors. A Sentry error that fires at 9am on a Tuesday usually has a fix shipped by lunchtime. Customers who report bugs get a "fixed, deployed" reply often within the same business day.

What we're not telling you

In the spirit of building-in-public — three things this cadence creates that we have NOT solved yet:

The single-operator bus factor. If something happens to the founder, Plyrium has a real problem. We're 4-6 months from the team-of-2 milestone that would meaningfully reduce this; not there yet.
Feature sprawl. At this velocity it's easy to ship 30 small features in a month instead of 5 deep ones. We're starting to feel this. The roadmap-discipline work for the next quarter is more "go deeper on existing surfaces" than "add new surfaces."
Customer cognitive load. A product that changes weekly is hard to write training material for. Larger customers (Front Office tier) get a private Slack channel where we narrate the changes as they ship. Solo and Voice tier customers see them via changelog + in-app toast.

Why this matters to you

If you're considering Plyrium, the cadence is part of the product. We're not the most polished CRM you can buy. We're the one that's going to change every week to fit the contractors actually using it. Six months from now, half of what's on the site today will be different — better, more refined, with the patterns that emerged from real use.

If you want the locked-down, slow-moving enterprise CRM with quarterly release notes — that's ServiceTitan. We respect that some customers want that. We're building the other thing.

If you want to send us a "wouldn't it be cool if..." email and see it ship by Friday — that's us. We genuinely love that mode. Email any time.