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.
My Startup, a Retrospective
11–20 of 35 posts
Re: My Startup, a Retrospective
#12This 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
Depends. "Billions" of API requests off 5 Heroku dynos could represent an awful lot of profit if enough of them are being paid for at .25-.4 cents a request. And the 75% response rate to his emails is extremely impressive.
It seems scalable and repeatable enough as it is, to the point where I'm not sure what VC money and an enterprise sales team would add.
Re: My Startup, a Retrospective
#13>>A few weeks after our 'real' launch, we started having issues keeping up with customer demand. The Django site and API service I had built were hacked together quickly, and were not scaling properly Since they ended up starting their re-write just weeks after launch- This is a great example of how the opposite of over-engineering is not adequately planning for success. Startup teams tend to naturally learn towards…
But he only did the rewrite after the first version proved there was a demand for the product. Sounds better than spending a few weeks (he did 20h!) on V1, only to find out there is no demand for it.
I agree: there's no indication they had any problems serving their customers at any point, nor that they got crushed by hosting costs. I'd contend the "optimisation balance" was just about perfect.
Re: My Startup, a Retrospective
#14Your post has a lot of points that lead the way for us who are starting. Very helpful and honest. Thank you.
Re: My Startup, a Retrospective
#15Earlier quoted context omitted.
But he only did the rewrite after the first version proved there was a demand for the product. Sounds better than spending a few weeks (he did 20h!) on V1, only to find out there is no demand for it.
I agree: there's no indication they had any problems serving their customers at any point, nor that they got crushed by hosting costs. I'd contend the "optimisation balance" was just about perfect.
>>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 there was major risk of that happening...
Re: My Startup, a Retrospective
#16Earlier quoted context omitted.
I agree: there's no indication they had any problems serving their customers at any point, nor that they got crushed by hosting costs. I'd contend the "optimisation balance" was just about perfect.
>>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 ^^
Re: My Startup, a Retrospective
#17This 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 grown the team, but we decided to treat it as a passive business after we got some big successes and didn't think hiring / etc. would be necessary (at least for a while).
If I could go back in time and re-do that, I think the company would be much larger now (and more successful) had we scaled our engineering team early on with the money we got, and tried to shoot for quicker growth.
Re: My Startup, a Retrospective
#18Good article. Maybe I missed it, but where did you get the database of number caller ID lookups from originally?
Re: My Startup, a Retrospective
#19Django 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 your code in more ways than one.
To top it all, Randall is a thoroughly nice guy to chat with. I'm glad OpenCNAM is growing and I wish it continues to grow for a long, long time to come. :)
Re: My Startup, a Retrospective
#20Great article, the explanation of rearchitecting the app left me hungry for more! I currently work on a Django project and I'm pushing tastypie to its limit as well. Working on switching to django-rest-framework. At a high level, what does your flask service architecture look like? I dug through your blog but couldn't find much. I'm particularly curious how you handled migrating from a django database and schema to w…
At a high level, the rewrite included the following services:
- opencnam-accounts (user accounts, and billing API) - opencnam-www (the public facing site and web portal) - opencnam-api (the developer API service)
We're currently splitting the backend up into several other components as well, so in the end-game things will look more like this:
- opencnam-www - opencnam-api - opencnam-auth (or possibly use Stormpath) - opencnam-billing - opencnam-email (handling drip email, etc.) - opencnam-logs (all logging information, metrics) - opencnam-delivery (telco CNAM retrieval stuff) - opencnam-storage (our CNAM storage product, still in development)
Each of the services basically gets their own Heroku app, their own NewRelic monitoring, and their own resources (cache, database (if necessary), etc.).
I can't even begin to say how helpful having multiple small apps actually is. Our codebase shrunk in size (total lines of code), became WAY more maintainable, way simpler, and way nicer in general.
As a side effect, it's also a lot easier to do teamwork type stuff, since you can have one person work on one service for a while, etc. Makes keeping things running smoothly really easy.
I wrote a bit about this in some other blog posts a while ago:
- http://www.rdegges.com/service-oriented-side-effects/ - http://www.rdegges.com/service-oriented-problems/