I've worked at Google and they take search quality very seriously. In fact, the search quality guys are not allowed to talk to the ads guys to avoid exactly this type of influence.
Sure money matters, and there is an "apparent" conflict. But in reality, the better the search results are, the more likely that users will use the search engine, which leads to more $$$. There is plenty of literature that demonstrates how serving poor search results will actually result in less ad revenue.
So James, being a former Googler, did you find that Google held back on search quality in favour of ad revenue?
A very interesting article indeed. Not much new, though. I am curious, though .. many co-founders with very successful exits make the top 0.05% or 0.01% in terms of networth, but they're new money. They're not part of the 0.01% closed circle. What happens to them, usually? Are they accepted into the 0.01% circle once they've made enough money to afford it, or are they treated like a wealthier bottom half of the top 1%?
And for the wealthy people who have pledged 50%+ of their wealth to charity - where do they fall in all this classification?
Our approach was:
1. Sketch mockups on paper, iterate until happy.
2. Sketch mockups in Photoshop, iterate until happy with every little detail.
3. Send photoshop mockups for slicing - get back HTML/CSS/JS
4. Convert static HTML files to static templates. In our case, it was Django templates. At this stage, we used dummy data so now the site would be served through django, exactly match the Photoshop images and the sliced HTML, data populated through views. That is, the static data is now hardcoded in the code rather than in the HTML.
5. Incrementally replace each view to serve data from DB instead of hardcoded. Data can be added to DB in Django using an interactive shell or using the admin interface. At this stage, we had our models flushed out and relationships between objects cleared up.
6. Add additional functionality such as forms and whatnot to actually accept input through the app.
7. Ajaxify everything to turn the website into a web app.
We didn't use any fancy tools beyond what's mentioned above.
When we raised our seed funding, I used several cap tables - none of which worked for me because they all made certain assumptions and didn't allow for reverse-calculations, which is what I needed. I found that a simple spreadsheet worked best in the end, but I had to review it a few times to make sure I didn't mess up the numbers.
In our case, the investor said: we value your company at X, we're willing to invest Y, and we need ESOP of Z%. From that, I had to reverse engineer the percentage and number of stocks that all involved would get.
The method that worked for me was to convert everything to number of shares and price per share before and after investing, and then calculate percentages based on shares / total shares for each party. This way, it's easy to calculate how many shares the investor gets based on the valuation (which determines pre-money share value), and final percentages based on total number shares after all is said and done.
A few things make a generic spreadsheet hard to create, and you should keep in mind:
- Is the investor paying based on % or share value?
- Are the ESOP stocks issues before or after the investment? (you get ripped off if it's before)
- Are you issuing new stocks or giving up a percentage of existing ones?
We host our servers with IAI (http://www.internetworking-atlantic.com/) and run our own private cloud using proxmox and OpenVZ. The VMs are CentOS 6 and the host drives are all encrypted.
Thanks for the links Daniel. Very helpful! BTW, we're in headquartered in Nova Scotia, and as per your link, we have stricter privacy laws than the rest of Canada. It even goes as far as provincial departments not cooperating with other provinces because their privacy laws are incompatible.
Additionally, at least in Canada, privacy-cautious organizations don't look too favorably on services that store data in US, in part due to the patriot act. We even have US clients who liked the fact their data would be stored in Canada ;O)
We tried them but had to change to a different vendor because the Blackberries didn't recognize their certificates and they had no plans to rectify that. We don't have much BB traffic, but didn't want to exclude BB users just because we wanted to be cheap.
I actually found the comments informative to gain better insight as to why people use different setups. I had assumed that same as what you said, which turned out to be less often true than I thought.
There is an option for SLA with a paid Google Apps account. Last I checked it was $50/year, but comes with much larger inbox (25G at Google vs. 10G max at Rackspace). Also better integration and push notifications on mobile for Google, if you care about that.
I've used rackspace hosted email before, both the regular and the exchange versions. It works nicely and the users were very happy. It gets expensive though if you want push notifications on the blackberry, even without the exchange.
Google Apps has the advantage that it comes with docs and gmail - not just a standard email :O)
At TitanFile we run our own server for all application-related stuff, and use a third party for email hosting. Reasons:
1) We need to comply with Canadian privacy laws, so need Canadian VPS - and those are way more expensive than in US.
2) To be PCI compliant, you need access to server logs. You can get that with Rackspace but pay a premium.
3) I've managed an in-house data centre before on my own, so I know what I'm doing for the most part.
If you factor all of the above, it's actually cheaper to manage your own servers, even if you outsource the sysadmin stuff to a competent contractor at about $100/h. The catch is there is an overhead initially to provide redundancy that diminishes only when you can utilize that extra capacity.
The overall market is estimated to be at 10's of billions of dollars in size. No one is even close to being a market leader, although companies like box.net, dropbox, and sharefile have some established customer base. But there is plenty of opportunity for new players to enter and disrupt the market, and investors don't want to miss out on that.
Investors already in this space may see investing in other guys like an insurance policy to maximize the chances of one of their portfolio companies making it big. But there are other investors who missed the boat on earlier opportunities and are looking for ways to enter this market through the newcomers.
From the perspective of a cofounder in this space - there are many interesting problems that no one has solved yet and there is a lot of potential to innovate, disrupt, and make a difference. At least that's what's driving my passion.
Stay away from .co at all cost. We tried registered irealty.co when it came out since .com and many others TLDs didn't have irealty, and we really wanted that name. We've put the .co in the logo to emphasize that it's not .com, but people kept telling us that our logo has a typo - it's missing the m the at the end. We ended up ditching irealty all together after that.
As a general rule, shorter URLs are more memorable, better for SEO, and better for social sharing.
Memorable: 7 letters or less is best, 9 is still manageable, and anything more than 9 calls for misspelling, too long to type, etc. I personally believe that a 2-word 12 characters name is better than a 5 letter weirdo name or random characters, but I haven't seen a study to support that.
SEO: the URL shown in google SERPs plays in a role in clickthrough rate. A shorter domain name means more of the URL will be shown, as many services limits the maximum number of characters shown.
Social sharing: same as above, short and meaningful domain names are more likely to get clicks and be shared again than a URL that passed through bit.ly and friends. Doesn't apply as much to twitter, but think email, facebook, linkedin.
Can you share the relevant snippets from your puppet setup? I'm currently looking at using puppet with nagios/monit to manage the 50+ servers that recently became my responsibility.
I'm most productive 10pm to 1am. So many people suggest working early, but not everyone can be productive in the early morning. And when you have kids who wake up at 6 or 7am, doing it in the evening after they went to bed is about your only option.
I'm in the same boat as you and totally agree with you that it is necessary to separate design from implementation and assign these tasks to different people in order to maintain or boost productivity. We've done the same in my startup and it's working great. Further, we feed off each other's progress and try to stay in sync, which keeps us motivating and grinding.