Got a startup idea? Validate it with the Startup Toolkit
thestartuptoolkit.com
thestartuptoolkit.com
Writing down the beliefs your startup is based on is crucial... it keeps you focused on risks instead of features, makes communication w/ team & investors easier, and stops you from ignoring the evidence. Yet most people don't do it (and almost no one consistently updates them).
I thought Steve Blank's customer development worksheets were a good start, but it's hard to update quickly and doesn't provide an overview. The canvas you see on the app is a modification of the Business Model Generation canvas, which I re-vamped to better suit startups.
Hope it's handy.
I've been keeping a list of tools & frameworks that seem helpful to startups, and I hope to bring them together and have founders pick & choose the structure they think will be most beneficial to their situation. The accounting is a good addition. It's still unclear where I can add the most value, but, as you mention, there are lots of promising possibilities.
Nice work otherwise.
Until I read this:
We'll try our best to preserve your data, but no guarantees. Your canvas is secured by obscurity, which is to say it's not very secure at all. Anyone with your canvas' URL may view and edit it. If and when we add a paywall, we'll make sure you can export any existing data.
Honestly, how hard would it be to just fix this first?
I think you're really on the right track to something good. But until you fix this, I'll just use my own text editor to save my thoughts on my own hard drive.
Security certainly wouldn't have been difficult to fix, but it would have added a few days and locked me a little bit further into a canvas design that may-or-may-not be correct. So I started with the big risk first, and the other stuff with fall into place fairly soon.
I thought it was a breath of fresh air. The unique ID is clearly very random and long enough to be unguessable. Even if the user and document hashes are not picked in a cryptographically secure way it's still going to be much more secure than the average alpha web 2.0 app that's hacked together with some generic login&auth component.
I think you should be upset at products that do auth but do it insecurely, not those who make a conscious decision that a simple solution is good enough. Just look at the websites that don't hash passwords, that don't restrict login cookies to the domain of the app, that don't have SSL logins, and so on. There are a million points where it can go wrong, and even today it's pretty difficult to asses whether your application is secure.
Think about it for a second. The security system the authors have chosen is almost impossible to mess up. Given how the hash looks I'm almost entirely sure they used some kind of crypto library to generate it. (If their magic ids looked like the output of randrange(100000, 900000) it would've been obvious). There is no other point of failure. If the hashes are random and unguessable, you're done! For a free product, I'd say that's pretty good!
What you want is security, but what you ask for is a login page.
You can also type in a more memorable URL (like etherpad, trend emerging) but that, of course, makes it much more guessable.
Sorry if I didn't make it clear enough, but all I want is:
1. the ability to add, change, or delete my any of my data at any time
2. the ability to share my data with exactly whom I want, no more, no less
OP guarantees neither (and, refreshingly, admits it). In fact, "We'll try our best to preserve your data, but no guarantees" and "not very secure at all" were his words, not mine. I was responding to his disclaimer, not my interpretation of his site's security.
[FWIW, I use ramamia by hner's jasonlbaptiste and markbao, which has a great and appropriate implementation of unique id. But then again, I'm less concerned about the security of my family reunion plan than of my business plan.]
When you delete data perhaps only a is_deleted flag gets toggled in a database, and copies of your work may reside in backups for months or even years. When you want to share your data you want to be reasonably certain the app is secure, but there is no way for you to determine if this is the case. I'm saying that a very simple system with very obvious security implications may be preferable to a complex system. It's easy to get Open Auth wrong, it's easy to get logins wrong, and so on.
Many apps will give you that login form and the share and delete buttons but chances are you would shudder at the thought of using the app if you knew what the backend looks like.
About those remarks on the page. The first one, "We'll try our best to preserve your data", is the best you can hope for in any situation, and the second remark that the website isn't very secure at all is also truthful given that it doesn't even use SSL.
So to reiterate, login forms on an app may make you feel more secure, but it won't bring you any closer to what you want.
If that's the best my customers could hope for, then I'd be broke.
I absolutely guarantee the integrity of my customers' data. To anyone who doesn't, I ask, "Why not?"
Maintaining data integrity during worst case scenarios is difficult, even when you have the budget and expertise for it. Especially if you offer real guarantees to your customers you should know that it's completely unreasonable to expect the same from a proof of concept web 2.0 app.
Still no TOS or anything saying that you ARE not giving up ownership of the data your enter.
Thanks!
[EDIT: Alexander Osterwalder, not Steve Blank...]
If you look at startup case studies, the worrying constant is how obvious most of their failures are. We lose track of our basic business assumptions and end up charging down dead-ends or building products nobody wants.
By explicitly stating our assumptions in an easily consumable way, it keeps you aware of what you're trying to prove and helps you avoid those "obvious" mistakes.
If you already have an idea that you think is a fact, and you are going to build it, regardless of what the world says, then you needn't write anything down. That's what most failed projects do/did.
The canvas is meant to help when you see your ideas as hypotheses. You document them, and then you go try to find out if they're true or not (by talking to customers, building MVPs, watching mailing lists, whatever). If everything is true, you move on to scaling the business. If some of your initial beliefs turn out to be false, which is probable, then you have a place to go back and document your new learning, and hopefully see how that change will impact the rest of your assumptions.
Novel idea!