Our new dashboard rolled out officially today and all of the 3.0 features will be rolling out over the coming days and weeks. There are a LOT of them!
61 karma · joined March 17, 2013
Our new dashboard rolled out officially today and all of the 3.0 features will be rolling out over the coming days and weeks. There are a LOT of them!
PHP/C/perl-style syntax just feels much nicer/more natural to write and I've never been able to break out of that.
I guess it comes down to personal preference and what you started coding with.
Speed to market/first version using JSON stores is attractive, especially when you're still prototyping your product and won't have an idea of exact data structures until there's been some real world usage.
This is what you need to know: https://www.cooleygo.com/so-you-owe-thousands-in-delaware-fr...
You should owe $400 ish based on issued shares and assets.
This is similar to the Cocktail Party Effect
https://medium.com/jme-venture-capital/meaningful-vc-exits-2...
Also, as 9 out of 10 investments, on average, will fail, the 1 that wins has to be big enough to balance out the losses, plus make a profit for the investors that's much greater than putting their money into public stocks, bonds, banks, etc. That's why each investment has to have the potential to be a billion-dollar-plus company, or it doesn't make sense to make the investment in the first place.
Very different from angels who are a) happy to wait b) happy to get 3-4x on their money.
We're already experiencing this. There are two of us and we need an extra 24 hours in the day to get everything done.
Get a co-founder if at all possible, it'll save your sanity.
Our checkout process requires no existing account, so you click on the buy button, enter your name, email address and billing info, and you create a password at the end, after which you DO have an account. We feel that this is much better UX than most other ticketing sites that send you to registration forms before you can continue the checkout.
We used to receive many, many support requests from people who'd lost the email containing their tickets. We then added order history and the ability to download their tickets by logging into their accounts and this resulted in a massive drop in support emails.
Another key point is that most people realise they've lost the ticket email only a few hours before the event is about to start, so we get very panicky last-minute emails from people freaking out that they're not going to be able to get in. Just giving people the option to log into an account and retrieve their tickets not only dramatically reduces our workload but also provides them with peace of mind.
We're adding 3rd-party login shortly (primarily Facebook) but will keep email/password as an option. However, even with 3rd-party login, we'll still need to confirm the email address as most people are used to email as their delivery method.
Saying all this, most of the advice in the article is valid and we follow many of the points. Our username is the email address and we enforce HTTPS on all pages (with HSTS headers).
It's easy to forget that you can have redundancy in your load balancers, web servers and databases (replication, multiple data centres, etc), but DNS is how you're found by the rest of the Internet.
No DNS resolution = no one reaches your expensive, lovingly-crafted infrastructure.
Any chance this is possible for us as well? This is the only reason we're using PayPal for the majority of transactions at the moment.
Thanks, Ritesh
https://www.ssllabs.com/ssltest/analyze.html?d=theticketfair...