Questions, answered honestly.

Holdfast runs as Python serverless functions on Vercel, with Supabase Postgres as the primary datastore, Supabase Auth for identity, and Supabase Storage for video messages. Resend handles transactional email, Stripe handles billing, Cloudflare provides DNS plus Turnstile CAPTCHA, and Plausible provides cookieless analytics. The whole architecture is deliberately serverless and managed — there are no long-running servers we maintain, no Redis tier, no Kubernetes.

Yes, and we engineered around both. Vercel's Python runtime caps execution at a fixed window per request, and request bodies are capped at 4.5MB. Both constraints are treated as hard product limits: the encrypted vault blob ceiling is 4.5MB by design, and any operation that could exceed the window (bulk delivery, video uploads, scheduled escalations) is split into discrete, idempotent calls. Cold starts are noticeable on the first hit after idle — 200–600ms typically — and acceptable for a product where the primary user action is a check-in once every week or month, not a real-time interaction.

Postgres on Supabase with row-level security (RLS) policies enforcing per-user access on every read and write. Core tables: users (auth-linked), vaults (one per user, holds the encrypted blob and metadata), recipients, check_ins, deliveries, deletion_log, and Firm-tier tables for solicitor accounts and their clients. Every endpoint resolves identity via a bounded lookup before any query runs.

Supabase Postgres and Storage are hosted in their EU region (Frankfurt). Vercel functions are configured for European edge regions. Resend processes outbound mail through their infrastructure. All data subjects are handled under UK GDPR; we are ICO registered as Nexus-Sec Ltd.

Authentication, vault access, and check-in endpoints depend on Supabase availability. If Supabase Postgres is unreachable, users cannot check in or modify their vault during the outage. The escalation logic is forgiving by design: a missed check-in does not trigger immediate delivery — it triggers a grace period (currently 7 days), then an escalation window (another 7 days), then up to 3 reminder attempts before delivery fires. A platform outage of hours, even a day, cannot cause an erroneous delivery. If Vercel is down, the marketing site and dashboard are unreachable but stored data is unaffected.

Supabase performs continuous physical backups on the Postgres tier with point-in-time recovery within their retention window. Storage objects (video messages) are replicated within Supabase's backend. We do not currently take an additional independent off-platform backup; this is a recognised gap on the roadmap, particularly as we onboard more Firm-tier customers. Recovery point objective is effectively minutes for the database; recovery time objective depends on Supabase's incident response.

When a user sets up a vault, they choose a passphrase. The passphrase never leaves their browser. We derive a key from it using PBKDF2 with 250,000 iterations (SHA-256, with a per-user salt). All vault contents — credentials, letters, wishes, attachments — are encrypted client-side using AES-256-GCM. The ciphertext, IV, and salt are uploaded; the key and passphrase are not. On retrieval, the encrypted blob is downloaded and decrypted in the browser using the same passphrase the user enters.

Encrypted blobs and metadata. They get the IV, the salt, the ciphertext, and structural fields like "this user has 14 entries" and recipient email addresses. They do not get the passphrase, the derived key, or any plaintext content. A successful database breach without also compromising every individual user's passphrase yields no readable vault contents. This is the meaning of zero-knowledge in our context: the operator (us) cannot read user vaults, even with full database access.

Honest answer: PBKDF2 with SHA-256 is FIPS-validated, available natively in WebCrypto across every browser without polyfills, and 250k iterations puts a meaningful cost on offline guessing. Argon2id is the modern preference and is memory-hard, which makes GPU/ASIC attacks more expensive. Migrating to Argon2id is on the roadmap; it would require shipping a WASM implementation and a migration path for existing vaults (re-derive on next unlock). For the current threat model — a database leak where the attacker would still need to brute-force each user's passphrase individually — 250k PBKDF2 plus a strong passphrase policy is defensible. We're transparent that this is a deliberate trade-off, not a final answer.

Their vault is unrecoverable. We cannot reset it, we cannot recover it, and we will not pretend otherwise. This is the fundamental cost of the zero-knowledge design: we have no copy of the key. Users are explicitly warned at vault creation, and the UX encourages them to share the passphrase with a trusted person offline and to store it physically. For the recipient delivery flow, we use a separate per-vault key/passphrase that the user shares with recipients out-of-band — see the question on recipient delivery below.

This is the part most people miss. There are two passphrases. The owner's passphrase encrypts the vault during normal use. When the user nominates recipients, they generate a separate delivery passphrase — they share this with the recipient offline (text it, write it on a card, leave it with a solicitor). On delivery, the system sends the encrypted vault and instructions to the recipient; the recipient enters the delivery passphrase to decrypt. We never see either passphrase. Recipients do not need a Holdfast account in advance — the vault explains itself on delivery. This is a locked principle of the product.

No. AES-GCM IVs must be unique per key per encryption. We generate a fresh 96-bit random IV for every vault encryption operation, stored alongside the ciphertext. Reusing an IV with the same key in GCM is catastrophic — it leaks the keystream — so we treat this as an invariant in the client-side code.

Some users add a hint to help them remember their passphrase. Hints are stored encrypted at rest under a server-side key, separate from the vault key — so a database leak of hints is a layer of work for an attacker rather than a freebie. We are honest that a hint useful enough to jog a tired user's memory is, by definition, useful enough to narrow an attacker's search space; the strongest move is no hint at all, and we say that in the UI when the user is about to set one. The hint is never sent to recipients on delivery, and never leaves the server in plaintext.

We use Supabase Auth. Email-and-password with email verification, plus magic-link as an option. Passwords are hashed by Supabase using bcrypt at their backend; we never see plaintext passwords for the account login. Note this is separate from the vault passphrase — your account password gets you into the dashboard, but it does not decrypt your vault. Even if someone compromised your account password, they would still need the vault passphrase to read content.

TOTP-based 2FA is shipped and self-serve. Once a user enrols a TOTP factor, every protected endpoint automatically requires the second-factor step on subsequent requests — there is no separate global toggle; the gate is conditional on enrolment so users without 2FA are unaffected. The next step on top is mandatory 2FA for Firm-tier solicitor accounts, where the operational case for forcing it is strongest.

Two layers. Application layer: every endpoint resolves the requesting user's identity first and constrains the query to records they own. Database layer: Postgres row-level security policies enforce the same constraint independently — even if an application bug omitted the WHERE clause, the database would refuse to return another user's row. Both layers must agree for a query to succeed. (See IDOR in the glossary.)

Cloudflare Turnstile on signup, account recovery, and the support form — the surfaces where bots create the most noise. On login itself, the primary defence is Supabase Auth's built-in rate limiting on credential endpoints, plus the fact that an account password alone gets an attacker into the dashboard but not into vault contents (which require the separate vault passphrase). Suspicious patterns (rapid check-in toggling, mass recipient adds) are visible in the admin dashboard. We do not rely on a single defence — Turnstile alone is bypassable, rate limiting alone is bypassable; layered with the zero-knowledge architecture, they raise the cost of attack considerably. (See credential stuffing in the glossary.)

A user's vault has a check-in cadence (default monthly, weekly available on Family and Firm tiers). On the due date, we send a reminder email. If the user checks in (a single click on a tokenised link, or a login to the dashboard), the clock resets. If they don't, a grace period begins (currently 7 days). After grace, escalation begins (a further 7 days), during which we send up to 3 reminder emails to the user. If all reminders elapse without a check-in, delivery fires: encrypted vault contents and instructions go to nominated recipients.

Several things. The grace plus escalation window is roughly two weeks, configurable. The escalation reminders use distinct delivery infrastructure and copy, so a single deliverability failure does not silence the whole sequence. Users can pause check-ins (e.g., for travel or hospital stays) directly from the dashboard. And for the Firm tier, solicitor alerts can be configured to escalate to a professional before delivery to recipients.

Pause is the supported mechanism. From the dashboard, a user can pause check-ins for a defined period; during pause, no reminders are sent and no escalation runs. Pause requires the account login (so an attacker who only has the vault passphrase can't pause it; an attacker who only has the account password can pause but can't read or alter vault contents).

Vercel scheduled functions trigger a daily check-in cron. The architecture is event-driven rather than a periodic full-table sweep — due transitions are pre-scheduled and claimed atomically, so concurrent runs cannot double-fire. Reminders during the grace window use a targeted query against vaults whose next check-in falls inside the reminder threshold, not a scan of the whole table. Every run writes a heartbeat to a monitoring table, so a missed cron is visible to us long before it could become a missed delivery to a user.

When a user deletes an entry, recipient, or their entire vault, we record the action, timestamp, and acting user — not the content. This is for forensic and dispute purposes (a recipient asks "why didn't I receive X?", we can show the entry was deleted by the owner on date Y). The deletion log itself is retained per the Privacy Policy's stated retention window and is included in subject access requests.

Not yet by an external firm. The codebase has been reviewed internally against OWASP Top 10 and the typical attack surface of a SaaS vault product. An external pen test is on the planned spend, prioritised after the Firm tier reaches a customer count where one solicitor's data is stored alongside many. Until then, we will not claim what we have not earned: no certification, no audit badge, no SOC report. The architecture is designed so that even an unaudited operator (us) cannot read user data.

Three primary attackers we design against: (1) An external attacker who breaches Supabase or Vercel and reads the database — they get encrypted blobs, no plaintext. (2) A malicious or compromised Holdfast operator (us, in a worst-case scenario) — same outcome; we cannot read vaults. (3) A targeted attacker who compromises an individual user's account — they need both the account password AND the vault passphrase to read content; even with both, they cannot impersonate the user to recipients without also intercepting the offline-shared delivery passphrase. We do not currently defend against a state-level attacker with full network observability and endpoint compromise — no consumer SaaS does.

Frontend dependencies are pinned and audited via npm audit on each deploy. Python dependencies are pinned with hashes. We minimise client-side JavaScript on the encryption path specifically to keep that surface small and reviewable. The encryption logic is implemented against the WebCrypto API directly rather than via a third-party crypto library, to avoid the dependency hijack risk on the most sensitive code path. (See supply chain attack in the glossary.)

Honest answer: yes, in principle. Any web application operator can serve different JavaScript to different users on different days. This is the structural limit of browser-delivered zero-knowledge — we are not Signal, where you install a binary and verify its signature. Mitigations: the encryption code is small and deterministic, we are an ICO-registered UK company with a real director and a real address, and the legal and reputational consequences of doing this would end the business. For users whose threat model includes "the operator might turn evil", browser-delivered crypto is not the right product — they want a local-first tool with verified binaries.

Yes, twice. Supabase encrypts the underlying storage volumes at the infrastructure level (AES-256). On top of that, the vault blobs we store are themselves AES-256-GCM ciphertext with keys we never possess. Decommissioning a Supabase disk does not leak vault contents, because the contents are already ciphertext under user-held keys.

Strict CSP with no inline scripts on the vault pages, allowing only same-origin and our explicit CDN. CORS is restricted to our own origins. HSTS is enforced via Cloudflare. Cookies are HttpOnly, Secure, SameSite=Lax for session, with explicit Strict on the most sensitive flows. Subresource integrity on bundled assets where the build pipeline allows.

None to date that have affected user data. Any future incident will be disclosed per UK GDPR Article 33 (notification within 72 hours where the incident meets the threshold), via direct email to affected users and a public statement. We commit to "no quiet patches" on anything that touches the encryption boundary.

Browser AES-GCM via WebCrypto is implemented by the browser vendor (Chrome, Firefox, Safari) and uses constant-time primitives where the platform supports them. We cannot guarantee constant-time behaviour on every CPU under every load, and a sophisticated local attacker with timing access to the user's machine has more direct attacks available than crypto side-channels. This is not a meaningful concern for the threat model we serve.

Yes. Nexus-Sec Ltd is registered with the Information Commissioner's Office (registration ZC120755) under the standard data controller fee. The single registration covers Holdfast and our other products operating under the same legal entity.

Nexus-Sec Ltd is the data controller for all personal data processed via Holdfast. The user is the data subject for their own account and vault; recipients become data subjects when they are nominated and contacted. For the Firm tier, where a solicitor uses Holdfast to manage client vaults, the relationship is more nuanced — the firm is typically a joint controller with us for the client list and a controller (with us as processor) for client-side vault operations. The Firm tier comes with a written DPA.

Contract performance for everything the user has signed up to (storing their vault, running check-ins, executing delivery to nominated recipients on their stated wishes). Legitimate interest for security operations, fraud prevention, and basic analytics (Plausible is cookieless and consent is not strictly required for it under UK guidance). Consent for any optional marketing email beyond transactional service messages. (See lawful basis in the glossary.)

On verified request, we provide all personal data we hold on the requester: account fields, vault metadata (entry counts, recipient email addresses, check-in history), payment records, support correspondence, and a copy of the encrypted vault blob. We cannot decrypt the vault for anyone, including the data subject — they must use their own passphrase. The deletion log entries relating to that user are also included. Standard 30-day response window applies. (See SAR in the glossary.)

On verified request, we delete the account, the encrypted vault, recipient records, and check-in history. Self-serve deletion goes through a deliberate cooling-off path: the user requests deletion, confirms with a one-time code sent to their email, and the vault then enters a 7-day pending-deletion state during which a reversal token in the confirmation email lets them cancel. After the window the hard delete fires automatically via a scheduled event. The cooling-off exists because vault deletion is irreversible at the cryptographic level — we would rather a user have a calm week to reconsider than try to fix it from backups. Payment records are retained for the period required by HMRC (six years). The deletion log retains a tombstone — the fact that user X requested deletion on date Y — because removing it would defeat the log's purpose. We disclose this retention in the Privacy Policy.

We delete their email address and any name we hold from the vault metadata, and we surface this to the vault owner on their next login so they can choose a replacement recipient. We cannot decrypt and re-encrypt the vault to remove references inside the encrypted blob, because we have no key — that's the user's job at next vault edit. We document this asymmetry openly.

Supabase (database, auth, storage), Vercel (compute, hosting), Resend (email delivery), Stripe (payments), Cloudflare (DNS, CDN, CAPTCHA), Plausible (analytics). All listed in the Privacy Policy with their roles and locations. A formal DPA exists with each. The DPA chain for the Firm tier is on the active legal review list. (See sub-processor in the glossary.)

Resend, Stripe and Cloudflare process some data in the US under standard contractual clauses and the UK extension. Supabase is configured for EU hosting. Any change in data residency would be disclosed in the Privacy Policy and notified to existing users.

No. Holdfast is not a will and does not replace one. A will is a legal instrument that disposes of property, appoints executors, and is subject to formal execution requirements (witnessing under the Wills Act 1837 in England and Wales, or the equivalent in your jurisdiction). Holdfast is a digital estate manager: it delivers credentials, instructions, letters, and wishes to people you nominate, when you can no longer do so yourself. It complements a will; it does not stand in for one.

On its own, none with respect to property disposition. Practically, an enormous amount, with respect to access. Estates routinely stall not because of legal disputes but because executors cannot get into accounts, find documents, or know what the person wanted to communicate. Holdfast solves the access and intent layer. A solicitor administering an estate where Holdfast was in use spends days, not months, gathering the digital footprint.

They operate in different domains. A will controls who legally inherits property; a Holdfast vault controls who receives information and access credentials. If the two conflict (the vault names a person as a recipient of a credential, the will names someone else as the inheritor of the asset behind it), the will governs ownership but the vault has already delivered the practical access. We strongly recommend users align them, and we provide guidance to that effect.

This is a real and unsettled question that affects every estate administrator, not just Holdfast users. The Computer Misuse Act 1990 remains in force, and unauthorised access to a computer is still a criminal offence. UK solicitor commentary treats executor access as a grey area rather than a clearly settled position — in practice, prosecutions in bereavement situations are vanishingly rare, but the legal risk is not zero. Two recent developments are worth knowing about. The Property (Digital Assets etc) Act 2025, which received Royal Assent on 2 December 2025, confirmed that digital assets can be owned as property and therefore inherited; it does not change the access-permission rules under the CMA. A narrower CMA reform protecting cybersecurity researchers was committed to by government in December 2025 and remains pre-legislation as of writing. Each platform's terms of service may separately forbid credential sharing, and a recipient should treat credentials from a vault as a means to retrieve information for proper estate administration rather than to operate the account indefinitely. We document this in onboarding and recommend users name an executor as a recipient where credentials are involved. For anything contested or high-value, take specialist legal advice.

No. Holdfast is a software product. Where we discuss estate planning concepts in our content, it is general information, not advice on a particular set of circumstances. We refer users to qualified solicitors for the legal layer — and the Firm tier is built precisely for solicitors who want to offer Holdfast to their clients as part of their professional service.

Yes. Under the Consumer Contracts Regulations, UK consumers have a 14-day cancellation right on distance contracts, including paid subscriptions. We do not begin the period with deemed consent to immediate service that overrides this; users get a full refund on cancellation within 14 days. For Lifetime purchases, the same right applies.

This is the question every long-horizon product owes a clear answer to. Our commitment: in the event of business closure, we will provide users with a minimum 90-day notice, an export tool that returns the encrypted vault blob plus enough metadata for the user to recover the contents with their passphrase via a documented decryption procedure, and where possible a transfer to a successor operator under the same architectural commitments. The decryption procedure is documented publicly so that even without our cooperation, a user with their passphrase and their exported blob can recover their data using standard cryptographic tools.

Terms of Service specify England and Wales, with non-exclusive jurisdiction of the English courts. Consumers retain their statutory rights in their country of residence.

Holdfast is operated by Nexus-Sec Ltd, a UK limited company. The director has 20+ years of enterprise security experience. The company is registered at Companies House under number 17126982, with a registered office at 71-75 Shelton Street, Covent Garden, London. It is a small operator running a focused product, not a large team — and we believe that's a feature for a product whose value proposition is structural simplicity and a tight security boundary.

Email support, with response targets of one business day for paid tiers and best-effort for Free. Critical issues — anything affecting check-ins, escalation, or delivery — are treated as priority regardless of tier; we will not let a bug starve someone's recipient of an alert. Firm tier customers get a named contact and a faster SLA defined in the order form.

The dead man's switch model means delivery fires automatically based on the user's check-in pattern, without any human at Holdfast needing to verify documentation. This is intentional: it removes us from the bereavement workflow entirely, which is faster and more dignified, and avoids the awful position of a grieving family arguing with a SaaS company about paperwork. For users who prefer a verified model, the Firm tier can be configured so a nominated solicitor receives an alert before recipient delivery, allowing professional verification.

The grace and escalation windows make this much harder than it first sounds. A typical user pattern is monthly check-in; missing one means at least two weeks of additional reminders before delivery fires. Anyone going on holiday for two weeks plus is reachable by at least one of email, dashboard login, or the partner check-in mechanism on the Family tier. Pause exists for longer absences. In years of operation we have not had a false-positive delivery; we are honest that the model trades off some risk of false positive against the much larger risk of a user who genuinely needs delivery to fire.

Theoretical and very rare; the social cost of staging the disappearance required is high relative to the alternatives an adversary has. Practically, the recipient receives instructions stating the vault was set up by the named user and delivered because they stopped checking in. A recipient who is suspicious can verify the user's status via normal means before acting on vault contents. We are not an instrument of identity fraud — we deliver information; we do not move money or transfer accounts.

White-label delivery (the recipient receives the vault under the firm's branding, not ours), CSV bulk client invite, a solicitor-facing dashboard at holdfast-co.uk/firm, vault completeness scoring per client, alerts on missed check-ins, and a referral tracking system. The solicitor is excluded from the recipient count on every tier — they are the channel, not the recipient. Onboarding includes a written DPA and integration support.

Stripe handles the dunning ladder. A failed payment triggers retries over the standard window. Throughout, the vault remains intact and check-ins continue to fire — we will never let a billing failure turn into a missed delivery for an end user. If subscription lapses, the account moves to Free tier limits (5 entries, 1 recipient) but existing data is not deleted. Restoration is a single click.

Current themes include an external pen test, expanded Firm-tier features, and migration to Argon2id for new vaults. Prioritisation is driven by user requests visible in support, security review findings, and partner (solicitor) feedback — in that order.

The client-side encryption code is shipped to your browser; it's reviewable in DevTools on every page load. The relevant calls are crypto.subtle.deriveKey for PBKDF2 and crypto.subtle.encrypt with AES-GCM. We are working towards publishing the encryption module separately with a stable hash for users who want to verify what they're running matches what we claim. A test you can run today: encrypt the same content twice and compare blobs — they will differ (different IVs); modify a single byte of ciphertext and the GCM tag will fail to verify on decrypt. Base64 fails both tests.

Nothing, structurally — see the operator-trust answer earlier. This is the unavoidable limit of browser-delivered zero-knowledge. There is now one cryptographic mitigation in addition to the non-cryptographic ones: the encryption code is published as a standalone module at github.com/Nexus-sectech/holdfast-crypto with Subresource Integrity enforced on every page load. The browser verifies the module's SHA-256 hash before executing it — if the file has been altered in any way, the vault page refuses to function rather than silently running modified code. Additional non-cryptographic mitigations: legal entity exposure, reputational exposure, and our public commitment that any change to the encryption boundary is announced and described before it ships. If your threat model excludes operator trust, browser-delivered crypto is the wrong category of product for you and we will tell you so. (See MITM in the glossary.)

Bring-your-own-key (a hardware token, a saved local key file) is a valid alternative architecture. We chose passphrases because the recipients of a Holdfast vault are typically non-technical — a spouse, a child, a sibling — and a passphrase shared offline ("the word is autumn-river-9") is something they can act on under stress. A hardware token requires the recipient to have the token, know how to use it, and not have lost it during the months or years between vault setup and delivery. We trade some cryptographic strength for a delivery flow that actually works for the people receiving the vault.

All time arithmetic is done server-side in UTC against the database clock, not the client clock. A user with a wrong system clock cannot trick the system into firing early or late by sending a forged check-in time — we record the time we received the request, not the time the client claims. Cron sweeps run on Vercel's clock against the same UTC reference.

Yes, that's the entire point. A check-in is exactly "I am still here, do not deliver yet." It does not require interaction with the vault content. The lightest-weight check-in is a single click on a tokenised email link, which we explicitly support precisely so that users with deteriorating capability can keep the switch from firing without needing to remember a password.

The token is single-use, time-bound (it expires after a short window), and does not authenticate the user for any operation other than "mark this check-in as done." An attacker who has full read access to the user's email already has many more direct attacks against them; preventing the check-in token from being one of them does not raise the floor. We mitigate the practical risk by not extending what the token can do.

From settings, there is a one-click export that returns the encrypted vault blob, a metadata JSON (entries structure, recipient list, check-in history), and a documented decryption procedure (the algorithm parameters needed to decrypt the blob with your passphrase using standard tools). With these three artefacts and your passphrase, you can recover your data without us. This is the answer to the lock-in question — the exported blob is the same ciphertext we store, by design.

Not fully, by design. The server-side code is closed source — a commercial choice, not a security one. The cryptographic boundary — the only code in Holdfast that touches plaintext — is published as a standalone, auditable module at github.com/Nexus-sectech/holdfast-crypto. It contains exactly the four functions that matter for the zero-knowledge property: key derivation, encrypt, decrypt, and salt generation, with zero external dependencies. The module is served with Subresource Integrity: the browser verifies its SHA-256 hash before executing it. The part of the codebase that actually matters for zero-knowledge is now under external eyes.

AES-256 is considered quantum-resistant for symmetric encryption; Grover's algorithm halves effective key strength but 128-bit post-quantum security against AES-256 is fine. PBKDF2 is similarly fine. Where things get interesting is TLS — Cloudflare and major browsers are rolling out post-quantum hybrid key exchange, which we benefit from automatically. Zero-knowledge content stored under AES-256-GCM with a strong passphrase is not the part of the stack that should worry anyone about quantum.

Not as a supported product. The architecture would permit a self-hosted deployment, but supporting it as an offering would change the threat model and the support model in ways that don't fit the company we are. For users with that requirement, we are honest that they want a different product.

An early build of the Firm-tier dashboard returned a solicitor's client list in a different order on each page load — not a security issue, but it meant the roster looked subtly different between sessions, and we got a confused support email from a careful early user. Root cause was a missing ORDER BY clause; patched within hours of the report. We share examples like this because the answer to "what's the worst bug" is never "none" from anyone honest, and a vendor who claims otherwise should worry you more than this answer does.

No. Plausible is cookieless and only records page views and very coarse referrer info. We do not record vault contents, entry counts beyond aggregated tier statistics, recipient lists, or check-in patterns to anything outside our own database. We do not have a product analytics suite (Mixpanel, PostHog, etc.) running on the vault pages.

Onboarding non-technical recipients to the delivery flow without requiring prior contact with them. The current solution — the user shares a passphrase offline, the vault explains itself on delivery — is the right architecture, but the moment of receipt for a grieving recipient is delicate, and we keep iterating on the language and UX of that first email. We do not consider this finished.

Free tier with 5 entries and 1 recipient. Personal at £5 per month or £45 per year, with unlimited entries, 3 recipients, and a choice of weekly, fortnightly, or monthly check-in. Family at £9 per month or £79 per year — two independent vaults on one plan, one per partner, 5 recipients per vault (10 total). Each partner's vault is fully private; neither can read the other's. A partner invitation flow links the accounts to a single billing cycle. Firm at £39 per month or £399 per year for the solicitor B2B tier, with the soft-capped client model, white-label delivery and the dashboard. Lifetime is a one-time purchase at Family-tier features for users who want to remove the recurring relationship from the equation.

Honest answer: launch pricing. The current rate is positioned as an early-adopter rate, guaranteed for 36 months from each firm's start date. After the 36-month protected window, pricing will move to a published standard rate with 90 days' written notice before any move. Existing Firm customers are price-protected on the entry rate for the full window regardless of any change.

Not literally unlimited — it's a soft cap of 20 clients included in the £399 annual rate, with tiered overage above that. The model is built so that a small firm running 10–20 clients pays nothing extra, a mid-sized firm pays a modest per-client amount above the cap, and a larger firm pays a rate that reflects the operational cost of serving many end-user vaults under one solicitor account. We picked tiered rather than flat because flat pricing either overcharges small firms (driving them away) or undercharges large firms (eroding our unit economics). Tiers let both extremes be fair. Full pricing tiers are visible during Firm-tier signup.

A firm offering Holdfast as part of a client engagement typically prices it into their fee at or near our list Personal rate. The margin scales with the firm's client base under the tiered model — comfortably profitable from the first handful of clients, materially profitable at the top of the soft cap, and structurally rewarding above it. We do not police what firms charge their clients; the upsell sits in the firm's engagement letter, not in ours.

Annually at renewal, against the live client count at that moment, with quarterly upward-only true-ups if the firm grows materially between renewals. A firm that drops from 80 to 78 mid-year (through two delivered vaults purging) is not refunded mid-year; the lower count is reflected at the next renewal. A firm that grows from 40 to 80 mid-year sees a quarterly true-up rather than discovering the new bill at renewal time. The firm's dashboard at holdfast-co.uk/firm shows the live client count and current tier position, and they receive an email when they cross 80% of any tier boundary.

No, and this is genuinely a structural advantage of Holdfast over comparable SaaS sold to firms. There is no "dormant" state for a Holdfast vault. Once a client is set up, they are on a check-in cycle. Either they keep checking in — in which case they are by definition an active client the firm rightly pays for — or they stop, which triggers grace, escalation and (if no interaction resumes) delivery, after which the vault enters its 30-day retention window and is then purged per GDPR. The product is self-cleaning at the operational level. A firm doesn't have to audit their list to remove ghost accounts, because ghost accounts can't exist — the mechanism that makes the dead man's switch work is also what keeps the client roster honest.

When the firm's account closes, each connected client receives an email from Holdfast confirming their vault is safe and explaining their new plan status. Vault contents remain fully encrypted and accessible — the firm's departure has no effect on what the client stored. Each client is automatically transitioned to the best plan available for their account: if they hold their own Holdfast subscription independently of the firm, that continues unaffected; otherwise their account reverts to the Free tier. Free-tier clients retain full access to their vault, recipients, and check-in schedule — they simply lose paid-tier features beyond the free limits. Any client can upgrade to a Personal plan at any time to restore those features. We do not silently freeze or delete a client's vault because the firm relationship ended. The Firm DPA documents this transition.

14-day full refund on any paid tier under the UK Consumer Contracts Regulations. Beyond 14 days, monthly cancellation takes effect at the end of the current period; annual subscriptions are not pro-rated unless we materially break service. Lifetime refunds within 14 days; not after, given the perpetual nature of the licence.

On the roadmap, not yet a first-class flow. A Lifetime purchase made on behalf of someone else and transferred at setup is the workable interim mechanism.

Less morbid than the alternative. The alternative is a family tearing through the filing cabinet and email account of someone they've lost, looking for passwords, mortgage references and the password to the iPad with the photographs of the grandchildren on it. Holdfast moves a one-hour conscious task during life into the place of a hundred-hour panicked task during grief. People who have been on the receiving end of a poorly-organised estate become the most committed users.

You shouldn't trust us with the contents — that's why the contents are encrypted under a key we cannot read. The trust we ask for is operational: that we will run check-ins reliably and deliver when we should. That trust is earned by track record, by being a real UK-registered company at a real address with a named director, and by being honest in answers like the ones on this page about what we are and aren't.

Our Terms commit to user notice in the event of a change of control, with sufficient time to export and leave. Any successor is bound by the published Privacy Policy as it stood at the point they took over. The architectural commitment — zero-knowledge encryption with keys we cannot read — is a property of the system, not of who runs it; a successor cannot retroactively gain access to existing vaults.

No. The vault is encrypted under a key we do not have. There is no path by which we can pass vault contents to an AI service. We use AI internally for typical product operations (drafting marketing copy, code review on non-sensitive paths) — the same way every modern company does. We do not use it on user data, because we cannot.

If we discovered a structural flaw in our encryption boundary that we could not fix while keeping the feature live. We would rather end a feature and refund users than ship a workaround that quietly weakens the property the rest of the product depends on. We have not had to make that call. If we ever do, it will be visible.