Cool idea but your pricing structure seems high. You should consider a one-time lifetime fee, it aligns with your business model.

I would be nervous with the one time fee the developer would give up on maintenance before I kicked the bucket. A monthly fee seems reassuring.

But what happens when your credit cards are cancelled after you die? That's a Catch-22 right there.

Alternative monetization strategy right there: keep paying us or we'll send all your secret documents to your loved ones / enemies :-)

It would be a shame if somehow, you know, being able to delete data became an uber-premium feature :D

I've thought about this. Not a final decision per se (and I haven't coded anything for the scenario) but I imagine I'd maybe have the third party accessing the data pay (up to a cap) to reconcile the account to make it "current" before giving them access - something like that.

It avoids folks signing up, canceling the card and then riding for free.

My 2cents, ditch the monthly plan, price it yearly instead. Monthly plans are for things you will actually use day to day like netflix, yearly are more like "insurance" products which is what this is, I think displaying the yearly option will be a better value proposition for people looking at it.

Second, I don't know what payment you're using, but seriously consider paypal if you're not already, because I'm pretty sure you can setup yearly recurring "subscriptions" on paypal and people are much more likely to keep their paypal funding sources up to date. So you're not going to have to nag them to update credit card info every couple years and they're less likely to have occasion to think "do I really want to pay for this", it'll just be pay automatically.

This also moves the point of cancellation to once a year and not monthly, or one month after.

I appreciate this. Thanks!

I'm using Stripe at the moment.

I would assume they pass your data to your chosen person then close your account so I don't see the problem?

That's an idea for sure. What could be interesting is cases of some credentials/data/whatever being shared among multiple folks. So do you wait until each person has viewed/downloaded then close? Do I (Passbox) notify everyone else if one person gets access then allow them all access? To be continued...

I would suggest a mix of both. The issue with lifetime fees is eventually someone will start to cost you money. I had a friend who sold some lifetime subscriptions to a VPN service, it's just not entirely feasible.

On the other hand, this is what I use BitWarden for, so my wife has access to important accounts and vice-versa. BitWarden does provide free shared passwords for 2 users.

And with lifetime pricing I don't like the idea of just keeping that money if someone churns. Maybe I'm just not enough of a hardened business person haha.

In your case with Bitwarden you're sharing access to your credentials and such with your wife right now, today, right?

With Passbox I'm looking to defer that access for data that makes sense. In my case I'm currently single and no one else has access to my iPhone but if I passed then maybe my mom or best friend should have that - as a hypothetical.

If you're sticking with recurring, you'll still need to keep the data for some time after the payments stop. The PR will be disastrous for you if someone passed away, and therefore the payments stop, and then all of their data is lost (worse: now imagine consequential financial loss from the loss of their data). I don't know whether you could be held liable for that or not.

Coincidentally just addressed that here:

https://news.ycombinator.com/item?id=21344759

That is correct, and yeah I see what you're saying. For example if both me and my wife were to pass away I don't know who would be able to access our things.

> On the other hand, this is what I use BitWarden for, so my wife has access to important accounts and vice-versa. BitWarden does provide free shared passwords for 2 users.

I just set my wife's email as the recovery address for my Gmail, figuring she can reset most of the important stuff from there.

But that's only a solution for "get into my accounts when I'm dead", not "share access to these things right now", and doesn't have the added benefit of a relatively secure password manager. And it ties you to Google, which may not be the wisest decision (but of course you could do something similar with a different service).

One potential benefit of something like a Passbox is that the important accounts would be ideally listed out vs having to guess what they are then reset the password via your gmail etc.

I don't think that's a fair comparison. VPN services have significant ongoing technical costs: bandwidth, servers, labour (upgrades, support, security, incident resolution) etc which you must pay monthly but are never recovered when charging a one-off price.

If you're finding that the users you're sharing your passbox with are requesting your passwords every day, that's probably signal enough to remove them so they automatically use the service less. I'd expect the lifetime marginal cost of an additional user here to be a very small percentage of the revenue for that client.

> If you're finding that the users you're sharing your passbox with are requesting your passwords every day

This is an interesting scenario I've thought about. Thanks for sharing!

It could be the case that once the "death trigger" happens there's a countdown for the requesting user to download the data and then I (Passbox) locks everything down or deletes the original data or something. To be determined...

Given cloud pricing structures and some basic actuarial tables, it shouldn't be too hard to put a reasonable limit on your resource costs. The real question is whether the cloud will last, or if you'll need to migrate everything off of AWS and onto something incompatible some time in the next 40 years.

Thank you for checking it out and for your feedback!

An initial thought I had was to look at it as being akin to an insurance policy of sorts and that's what sort of led me down the recurring revenue path. Definitely will consider one-time fees for the future! Thanks again!

Those types of insurance polices payout on an event, so a monthly premium makes sense as nobody can afford to pay it upfront.

I'd say your service is the internet version of someone creating their will, and leaving it with a friend or family member, which are all one-off costs.

Definitely. It'll be interesting for me to balance my recurring costs while matching with consumer ideals. To be continued...

Hi.

While I like the general idea, I do have mixed feelings storing so much valuable data online, on servers of a company I don't know, that operates in the US.

What prevents a 3letter agency from instructing you to:

1- give access to one of you trusted contact accounts

2- disable sending notifications to the account holders email

3- 3letter agency clicks on request data

4- data gets released ( as it will not get denied if the account holder does not receive a notification)

Thanks for this!

1 - Even with access to the trusted contact's account a passphrase/access key (specific to the main account and not stored by the service) is required

2 - Interesting scenario but still requires the above-mentioned access key

3 - Same as above two points even after being approved

4 - Won't get released without the key

> 1 - Even with access to the trusted contact's account a passphrase/access key (specific to the main account and not stored by the service) is required

I understand that your service is encrypting the data before saving it (vs that happening completely on the client and only encrypted data being sent to you), so there's nothing stopping you from logging it to a plain text file (even accidentally). Given that these passwords will likely hold the keys to that person's identity, that's a huge amount of trust that they need to have in you, your technical abilities and future decisions.

100% agreed with you here - no denying it - and no different from any service that we use where it's up to our trust that they will do the right thing. That said, I can for sure revisit my encryption strategy.

Overall that's one uphill challenge I've seen emerge as I've chatted with folks about the product: inspiring trust.

sounds reasonable, a couple more questions:

do i provide the trusted contact the access key or how does that work?

When is it generated?

What if add a new trusted contact or remove one how does that change things?

Bring on the questions! I don’t mind one bit. Feel free to tweet or email me if needed too (email at the bottom of the landing page)!

What’s funny is earlier versions of the landing page had way more detail for what you’re asking about and I got chided for it during user testing reviews haha.

Every user generates their own key (which can make it more friendly) and would need to provide it to their contacts on their own. It’s required to be set before you add any data.

Modifying users doesn’t change anything for me. Any new contact would need to be sent the same key or you can change it! Old users wouldn’t be able to request access regardless of knowing your (maybe old) key.

Hey! One of my best friends died in a motorcycle accident -- he was a developer as well (got me in the field!).

After his passing, no one knew how to get on his server and/or his domain registrar's account so as a result, someone else snatched up his personal site as soon as it expired, and pretended to be him for several years.

I really love hearing about projects like yours cause I'd definitely want to avoid stuff like that!

Wow. This hits way too close to home. Thanks for sharing!

How do I know you're still going to be in business when I die?

If this actually goes anywhere I personally wouldn't shut the company down silently. I'd have contact information for everyone involved to help them prep for its sunsetting.

What happens if you die in a server-related explosion?

That's a pretty easy way to shut down this service with no notice. Absurdist, sure. But that is the stakes with this kind of service.

Your feature list for Freemium includes both "Fixed 1-Day Access Wait Period" and "Set Your Own Access Wait Period."

I have _no_ idea what you're talking about. :)

(Read: Thanks a ton!)