21–30 of 35 posts
Django n00bs like me owe a great deal of our learning to Randall. His book, 'The Heroku Hacker's Guide' is an excellent resource for anyone looking to deploy a Django project quickly and cleanly to Heroku. To that end, he also created a fantastic Django template `django-skel`[0] that uses good industry-standard practices. As a newbie, `django-skel` helped me understand code modularity and the importance of organizing…
Good article. Maybe I missed it, but where did you get the database of number caller ID lookups from originally?
Right now we get CNAM from the authorative telco sources.
Django n00bs like me owe a great deal of our learning to Randall. His book, 'The Heroku Hacker's Guide' is an excellent resource for anyone looking to deploy a Django project quickly and cleanly to Heroku. To that end, he also created a fantastic Django template `django-skel`[0] that uses good industry-standard practices. As a newbie, `django-skel` helped me understand code modularity and the importance of organizing…
Woa man, I'm extremely flattered! Thanks so much ^^
Earlier quoted context omitted.
>>there's no indication they had any problems serving their customers at any point "we started having issues keeping up with customer demand" "To keep things running smoothly, I scaled up our Heroku Dynos, but quickly realized that things needed to be rewritten as soon as possible to avoid major problems." What you are saying is possible, by the article suggests they either did have problems serving customers or ther…
Author here: we never had any customer-facing issues, but (and a big shout out to New Relic), NewRelic helped us identify that we were dangerously close to a catastrophe if we kept growth steady. We did the rewrite to avoid problems, and by the time we relaunched our new Flask backend we were struggling to support customer demand. All in all, NewRelic really helped save us here ^^
Earlier quoted context omitted.
Author here: we never had any customer-facing issues, but (and a big shout out to New Relic), NewRelic helped us identify that we were dangerously close to a catastrophe if we kept growth steady. We did the rewrite to avoid problems, and by the time we relaunched our new Flask backend we were struggling to support customer demand. All in all, NewRelic really helped save us here ^^
Could your performance problems be closer related to http://news.rapgenius.com/James-somers-herokus-ugly-secret-a... than the performance of Django or your code?
Heroku has always been great for us!
I'm always a bit surprised about the RapGenius stuff because their problem is not really a Heroku specific issue, IMO. If you're running code on Heroku (which uses random load balancing), you need to have a proper multi-threaded web server to serve requests concurrently.
In our situation, we were able to service many concurrent requests per dyno, and maintained very low response times (10ms or less), in most cases.
This looks like it is probably a great lifestyle business (based on the claimed API requests and pricing) but I'm not sure that I would call it a startup. It sounds like it hasn't even had an employee devoted to it until recently. There isn't anything wrong with that at all but for a "startup" this wouldn't be a great outcome. http://en.wikipedia.org/wiki/Startup_company
We didn't need VC or anything like that to get started, so our expenses were very low. It also did (and does) generate quite a bit of revenue, so I'd say it's definitely outside the 'lifestyle business' category. In the end we had all partners (3 of us), and a full time employee -- so it was fairly big I'd say (all with profitability, etc. from day one). Along the way we could have definitely hired more engineers and…
Earlier quoted context omitted.
We didn't need VC or anything like that to get started, so our expenses were very low. It also did (and does) generate quite a bit of revenue, so I'd say it's definitely outside the 'lifestyle business' category. In the end we had all partners (3 of us), and a full time employee -- so it was fairly big I'd say (all with profitability, etc. from day one). Along the way we could have definitely hired more engineers and…
IMHO, your last paragraph really is the difference between a lifestyle business and a startup. I'm not disrespecting the choice at all, just a different set of goals. Based on the set of customers you have and domain expertise I'm not sure why you aren't throwing everything behind this business. Anyway, good luck!
I know there's no formula for a successful startup, but if you had to pick one, this would be it: Build an MVP, get product validation, scale, find paying customers, make outside hires.
scale before find paying customers?
I know there's no formula for a successful startup, but if you had to pick one, this would be it: Build an MVP, get product validation, scale, find paying customers, make outside hires.
scale before find paying customers?
This looks like it is probably a great lifestyle business (based on the claimed API requests and pricing) but I'm not sure that I would call it a startup. It sounds like it hasn't even had an employee devoted to it until recently. There isn't anything wrong with that at all but for a "startup" this wouldn't be a great outcome. http://en.wikipedia.org/wiki/Startup_company
He searched for a repeatable and scalable business model. He found it. He scaled. He delivered excellent ROI to his investors. That's a startup.
People who think it's not real if it doesn't involve angels and VCs and TechCrunch write-ups and whatnot are fashion victims. Pity them.