You scoped the MVP for a sprint. Three months later you're still debugging why the password reset email lands in spam for Outlook users. The distance between the SaaS you pitched and the SaaS you're shipping is rarely the headline feature — it's the plumbing nobody writes on the roadmap.
The r/SaaS thread that prompted this article asked builders one question: what wasted the most time? The answers weren't exotic — auth, billing, deployment, and the long tail of edge cases that never surface in a demo. Here is the survey, and where current tools genuinely help.
The plumbing that never makes the roadmap
Authentication. A login form is an afternoon. Authentication is a state machine. Signup, email verification, login, password reset, session expiry, "remember me," logging out from every device, OAuth with two or three providers, refresh-token rotation, and account deletion that actually satisfies a GDPR request. Each transition carries a security decision. The happy path is the tip; the rest is the iceberg you hit in week three.
Billing. Stripe Checkout drops in fast — that part really is an afternoon. The work is everything after the redirect. You handle invoice.payment_failed, customer.subscription.updated, proration when someone switches plans mid-cycle, dunning for failed cards, trial-to-paid conversion, and idempotency keys so a retried webhook never bills a customer twice. Stripe documents dozens of webhook event types, and you will care about a meaningful fraction of them. Then there is sales tax.
Deployment. "Works on my machine" is where the timeline goes quiet. Environment variables across three stages, secret management, a build pipeline, database migrations that do not lock a table during peak traffic, a rollback plan, and log aggregation you can search at 2am when checkout starts throwing 500s. The first production incident teaches you what your deploy setup was missing.
Edge-case debugging. Timezones. The user who imported 12,000 rows. The double-submit that creates two orders. The race between two webhook deliveries. The browser back button that breaks your onboarding wizard. None of these show up in a demo. All of them show up in support tickets.
Treat "auth" and "billing" as single line items in your estimate and you have already lost the timeline. Each is a subsystem with a dozen branches. Break them into their actual states before you commit to a date — the line-item version of the estimate is always the optimistic one.
Why the estimate is always wrong
You estimate the thing you can picture. Auth as a feature is a form with two fields — you can see it finished in your head, so you price it at a day. Auth as a system is a dozen state transitions, each one a place where a session can leak or a token can be replayed. The part you cannot picture in advance is exactly the part that consumes the calendar.
This is the boring-but-deep trap. Flashy-but-shallow work — the dashboard, the marketing page — looks expensive and estimates well, because what you see is what you build. Boring-but-deep work looks cheap and estimates terribly, because the visible surface is a fraction of the real shape. Your build timeline gets wrecked by the second category, not the first.
The fix is not heroics. It is recognizing the category before you write the date down, then decomposing those items until each piece is something you can picture.
Where AI dev tools actually cut the time
AI coding tools do not remove this work. They compress the part of it that is lookup and boilerplate rather than judgment.
Three concrete wins. First, exhaustive boilerplate: an AI editor scaffolds a Stripe webhook handler with a branch for every event you name, or generates the OAuth callback for each provider, faster than you can tab between docs. Second, the edge cases you forgot: ask the model to write tests for a function and it probes the empty input, the negative number, the duplicate call — the cases that otherwise reach you as tickets. Third, less context-switching: the timezone fix arrives without a detour into date-fns documentation.
What it will not do: design your pricing model, know your VAT obligations, or decide your rollback strategy. Those are judgment, and judgment stays with you. The honest framing is narrow — AI drafts the 200-line webhook switch statement quickly, but you still have to know which events matter and what each one should do.
Point the tool at the boring-but-deep work, not the demo. Generating a marketing page saves you minutes. Generating the full set of subscription-webhook branches, with idempotency handling, saves you the debugging week you never budgeted for.
Estimate the iceberg, not the form. The teams that ship close to schedule are not faster typists — they recognized auth, billing, deployment, and edge cases as subsystems early, decomposed them, and aimed their tools at the deep part. The plumbing is still the work. It just does not have to be the surprise.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)