Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Jeff Lawson
Is this you? Claim Profile »
4 months ago
in Looking For The Yawn on A VC
Hi Scott,
I'll happily pipe in, I'm the one spending the $$$ :)
You're correct, we haven't spent fortunes on enterprise hardware we need to recoup. Instead, we've invested significant time writing better software, building a reliable telecom infrastructure on top of commodity AWS resources. Our costs are highly variable, and we pass the variable cost structure on to our customers.
So our fundraising is to hire the best and brightest folks to help us take Twilio to the next level. Sales and marketing are high on our list, as well as hiring great engineers to help us expand Twilio's capabilities.
So if you're looking for a job and you fit one of those descriptions... email jobs@twilio.com :)
-jeff
I'll happily pipe in, I'm the one spending the $$$ :)
You're correct, we haven't spent fortunes on enterprise hardware we need to recoup. Instead, we've invested significant time writing better software, building a reliable telecom infrastructure on top of commodity AWS resources. Our costs are highly variable, and we pass the variable cost structure on to our customers.
So our fundraising is to hire the best and brightest folks to help us take Twilio to the next level. Sales and marketing are high on our list, as well as hiring great engineers to help us expand Twilio's capabilities.
So if you're looking for a job and you fit one of those descriptions... email jobs@twilio.com :)
-jeff
1 reply
9 months ago
in The first 6 steps to homegrowing basic startup metrics on Futuristic Play by @Andrew_Chen
Good ideas Andrew. WRT your mysql table, I've found that storing raw data (for later analysis) can potentially become an application bottleneck, as that table will grow large and probably be abused in ad-hoc reporting. That's why we're using Amazon's SimpleDB to throw lots of data at. We can pull it back down later into optimized table formats, or write reports direcly from their API, but we'll never worry about the growth and scale of that database, and we'll be free to over-log, instead of losing data.
1 reply
Andrew Chen
yeah, I think it just depends on what phase of the business you're at. Early on, I think that you want to optimize for easy investigation of ideas, which is why I prefer SQL. If the tables get large, you can always just rename the table and start writing into a new one (believe it or not this works fine and we did it with multi-million row tables). Later on, I agree that some of the more exotic technologies can work - but you want to make sure you're not prematurely optimizing.
"building a reliable telecom infrastructure on top of commodity AWS resources." and "Our costs are highly variable, and we pass the variable cost structure on to our customers."
edit: good luck jeff and team!