The Economics of Running a Digital Legacy Service

Building a digital legacy service comes with a constraint most startups don't have: we need to outlive our users. That's not marketing speak—it's the fundamental promise. If we optimize for rapid scaling and burn through VC money chasing growth, we might not be around when your family actually needs us. So we built Inheritfy to be profitable from day one, with transparent costs and sustainable margins. Here's exactly how the economics work.

What It Actually Costs to Run This

Our infrastructure now centers on Cloudflare. The API runs as a JavaScript Worker, relational metadata lives in D1, and vault objects are stored in R2. The frontend and marketing site are built as static web apps, while email and SMS delivery remain external services. The important part is that our core storage and API costs scale with actual usage instead of requiring always-on backend servers.

That's intentionally lean. Workers give us request-based compute, D1 keeps the relational parts serverless, and R2 stores the heavy file bytes without forcing a separate object-storage service into the architecture. No point paying for idle infrastructure at 3 AM when most legacy-vault workloads are quiet, durable, and event driven.

The Storage Math

Object storage pricing looks simple on paper, but the real cost depends on access patterns. Most files in a digital legacy vault are write-once, read-rarely. You upload documents today; your family downloads them once after verification, maybe twice. That's it.

So we optimize around that shape. Files stay in R2, metadata stays in D1, and delivery flows are mediated by Worker URLs so we can enforce package, Time Capsule, and emergency-access rules before any object is served. That keeps the storage model simple: durable object bytes in R2, authorization and lifecycle state in D1, and the Worker as the policy boundary.

Run the numbers on any inheritance product and the same truth appears: storage is only one line item. The plan price has to cover compute, email, SMS, support, security maintenance, and - crucially - the obligation to keep this service running for decades. That margin isn't greed; it's sustainability.

Grace Periods: Expensive but Essential

Here's a decision that doesn't make pure economic sense: if your payment fails, we don't immediately delete your data or stop the check-in system. We keep operating your account for 30 days on Starter, 90 days on Premium, and 180 days on Legacy.

During that time, we're paying for storage and compute with zero revenue. A Legacy user with 50GB of files costs us about $0.63/month in storage alone, plus their share of compute. Multiply by 180 days, and a single grace-period user could cost us $10-15 before they either resume paying or we can safely archive their data.

We do this anyway because the alternative is worse. If you're in a coma and your card expires, your family still needs access to your vault. If you die and your bank account gets frozen during probate, the verification system still needs to work. Protecting your legacy matters more than payment status. This is what "sustainable business" actually means for a service like ours—the mission has to come before pure profit optimization.

Verification Costs

When someone misses check-ins, we don't just flip a switch. The verification process involves multiple notifications: reminder emails to the user, alerts to trustees, escalation emails to beneficiaries. Email is comparatively cheap. The expensive part is SMS.

Twilio charges roughly $0.0079 per outbound SMS in the US, more for international numbers. A Legacy user with 10 trustees receiving SMS notifications at each escalation stage can run up several dollars per verification cycle. This is why SMS notifications are only available on Premium and Legacy plans—we can absorb that cost at those price points, but not at $4/month.

Why Cloudflare Instead of a Traditional Backend

We could keep running a conventional container backend and a separate managed database. We specifically moved away from that, for reasons that matter more than familiarity.

Workers, D1, and R2 let us keep the application small and boring: request handlers at the edge, SQLite-compatible relational state, and object storage for vault files. Fewer moving parts means fewer operational chores, fewer idle resources, and a system that is easier to reason about when the promise is long-term availability.

The goal is not novelty. The goal is a conservative architecture with a smaller maintenance surface.

Why We Don't Chase "Cheapest"

We could charge $1/month and try to make it up on volume. Here's why that would be dangerous for a service like ours.

Race-to-bottom pricing attracts price-sensitive customers who often don't value the service enough to maintain it long-term. High churn means constantly paying acquisition costs instead of building lasting relationships. If we make $0.50/user/month, we need tens of thousands of users just to cover infrastructure. That pressure leads to desperate moves—selling data, cutting security corners, or shutting down entirely when growth stalls.

Worst of all, at $1/month, a 90-day grace period would wipe out years of revenue from that user. We'd have to eliminate the very features that make a legacy service trustworthy.

Our pricing ($4-19/month) ensures profitability at small scale. We don't need 10,000 users to survive—100 committed users makes this sustainable. That's the kind of business that can exist for decades without outside pressure to "grow or die."

Where Your Money Goes

About 15-20% of subscription revenue goes to infrastructure: compute, storage, networking, email, and SMS. Another 3-4% goes to Stripe for payment processing. We set aside roughly 10% as a grace period reserve - money to cover users who stop paying but whose data we're still obligated to maintain. Development and maintenance takes about 30%: security updates, new features, bug fixes. Support runs around 10%. The remaining 25-30% is operating margin.

That margin isn't excessive. It's the difference between a service that can weather a recession and one that folds when times get tough. For a legacy service, survivability isn't a feature; it's the entire product.

Why I'm Not Worried About Longevity

Here's something that might matter more than any business plan: I use Inheritfy myself. My own family's documents are in here. The service existing long-term isn't just a business goal—it's personal.

And because we built it lean, the economics work in your favor. With serverless compute, D1 metadata, and R2 object storage, the baseline system can stay small when traffic is small and grow only when usage grows. Business slows down? The platform still has a realistic path to keep running. That's the point of building something sustainable instead of something that requires constant growth to survive.

You can also export everything anytime—SSE vaults download as decrypted files, CSE vaults export encrypted with your key. No lock-in. If you use client-side encryption, you have your 24-word recovery phrase, which means you can reconstruct your master key and decrypt your files locally even without us. But I don't expect you'll need to.

The Bottom Line

Running a digital legacy service isn't about minimizing costs—it's about maximizing trustworthiness. Every technical decision we make asks: Will this still work in 20 years? Can we afford to maintain this indefinitely? Does this compromise our users' security for short-term savings?

The answer to sustainable pricing is straightforward: infrastructure costs plus a buffer for reliability, plus grace period reserves, plus development and support, plus enough margin to survive downturns. That formula produces prices that won't win "cheapest" comparisons, but it produces a service you can actually trust with your legacy.

And that trust is the only thing that matters.