The structural traits that make tax prep unlike normal SaaS — read this first; it frames everything else.
Sources: research/SOURCE_INDEX.md — [S4][S7]. Seasonal-rhythm operational detail is partly Analysis, labeled.
Most of the year's revenue is earned in a ~10-week window (late Jan → Apr 15), with a second, smaller bump before the Oct 15 extension deadline. Almost no other consumer software compresses a year's demand into one quarter. Consequences:
- Engineering, marketing, and staffing all build toward a single peak ("the season").
- A bug or outage during peak is catastrophic — there's no "next sprint" to fix it before customers need it.
- Revenue recognition and cash flow are lumpy; the company is judged on one season's execution.
Filing taxes is legally required, happens every year, for ~146M households. [S7] Demand doesn't need to be created — but it's low-frequency (once a year) and high-anxiety, which shapes everything about retention and brand.
Errors have real consequences (penalties, audits, missed refunds). So the product isn't "convenience," it's confidence and accuracy. This is why:
- Brand and trust matter more than in ordinary software.
- Guarantees (accuracy, max refund, audit support) are core product, not marketing garnish.
- The assisted model (a human expert to trust) commands a premium.
The software is an implementation of the current-year tax code, which changes every year (inflation-adjusted brackets/limits, new or expired credits, revised forms/schedules, occasional major law changes). So the product must be substantially updated and re-certified with the IRS every year — not rebuilt from scratch, but the changed pieces re-implemented and the whole thing re-validated against the IRS's new schemas before the season opens (see file 07). The season's success hinges on getting the new code right, on time, every year.
🔎 This is a program-opportunity area — the annual change is known and recurring, so it rewards a proactive, classified program approach. See
PROGRAM_OPPORTUNITIES.md→ PO-1.
Because a chunk of filers have simple returns, "free" is both a customer-acquisition wedge and a reputational/legal minefield — it drove the FTC case, the $141M settlement, and the ProPublica series (file 10). Managing the line between "free enough to acquire" and "paid enough to monetize" is a defining tension.
For many filers the tax refund is the largest single check of the year. That emotional weight drives behavior: refund advances, pay-with-refund, and cross-sell of financial products (file 09) all hang off refund timing.
Users touch the product once a year, under stress, often against a deadline. That means:
- Onboarding must work for someone who forgot last year's flow.
- Prior-year carryforward (your data pre-filled) is a powerful switching cost and retention tool.
- There's little room to "learn by doing" — the UX must carry an anxious, infrequent user to a correct outcome.
Because of the above, the tax business runs on a distinctive annual calendar. Approximate anchors:
- Late January — IRS opens for e-file; season begins.
- ~April 15 — primary filing deadline; the peak (and peak-load days just before it).
- ~October 15 — extension deadline; the secondary peak.
- Off-season (summer–fall) — rebuild the product for next year's tax code, IRS certification/testing, plan the next season.
Practically, a tax-software org runs readiness programs and war-rooms into peak, and typically imposes change freezes around the highest-load windows to protect stability (nothing risky ships when a few minutes of downtime = lost filings and revenue). (This freeze/peak-readiness pattern is inferred from how the business must operate + Intuit's public peak-resiliency engineering; a specific published freeze calendar was not found — see the interview-prep notes.)
Why it matters: in this business, the calendar is a hard constraint, not a preference. Roadmaps, migrations, and launches all have to be planned around the season and its freezes.