My Startup, a Retrospective | Hacker News Reader

My Startup, a Retrospective

rdegges.com

158 pointsrdegges34 comments

Great writeup. I really appreciate when people take the time to do this. And also to risk dealing with the jackass criticism that usually comes from putting yourself out there on the internet.

One thing that was underemphasized: They built in response to actual need, which was great. If you click through to the announcement post [1], he explains that he had spent 4 years doing telephony stuff, and was always bothered by the lack of an API.

Good for them for taking their small proof of need and building small. And then using that to get more proof of need as a way to justify further investment. That's in contrast to a classic startup mistake, which is to jump in and build something you just think other people need.

[1] http://www.rdegges.com/im-working-on-a-startup/

I think that the author is a bit unfair to himself, in the conclusion. He wrote the following:

>"I think the single largest mistake we made was to not invest more time into OpenCNAM as it was growing. Instead of devoting time to other projects, we should have doubled down and focused on developing the product even more, and made it into the best possible product.

At the time, it seemed like a good idea -- but in retrospect, I believe that if we would have really focused on adding more features to the API service, cleaning up the user dashboard, and fixing some UI elements -- we could have won a lot more potential customers over."

While he acknowledges that this is only apparent in hindsight, he does not seem to give himself credit for diversifying his risk portfolio at the early stage, when success was uncertain. It may be that doubling down earlier would have put the business in a better situation now, but that does not mean the expected outcome of doubling down was better than the expected outcome of maintaining parallel projects.

>>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 one or the other extreme and need to fight for balance. I personally try to remind myself of this fact as much as possible :)

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...

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?

Nah, I've actually written quite a bit about Heroku (I authored a book on it). The issue was us having complex problems with Django and our supporting libraries: we needed to have database connection pooling, we had to rip out the tastypie REST framework due to complications with scaling the user model, and a bunch of other stuff.

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 is a great write-up. Due to the title, it took me until 3/4 of the way down to realize that your startup did not fail, but actually is succeeding!

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 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. :)

[0] https://github.com/rdegges/django-skel

I'll toss in my own two cents. Thanks to a discussion with Randall we started working on what eventually became Two Scoops of Django. The 'The Heroku Hacker's Guide' was an inspiration, and his promise to be one of the reviewers gave us the confidence to get started.

I'm delighted OpenCNAM has done so well and I wish him the best in the future. :-)

Woa man, I'm extremely flattered! Thanks so much ^^

I'd like to echo this sentiment. Thanks Randall!

I really like to hear success stories from honest people with a real value-adding product. This isn't just some social mobile app or a marketplace for X, you solved a real pain point for a lot of people. Congratulations on all the success and good luck going forward! Thanks for taking the time to break all of this down for HN.

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 think you need to find proof of paying customers before you scale. Otherwise you can't justify the scaling investment. But then the order you do them in depends on local conditions, and it's usually a stepwise thing where you alternate some of each.

Not sure if someone would pay for something that doesn't scale, but I can see how these two steps might have to be swapped.

Great 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 whatever you ended up using.

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/

Good article. Maybe I missed it, but where did you get the database of number caller ID lookups from originally?

We've had to get it from several places over the years. We went from various sorts of telco contracts, to CNAM aggregator deals, to everything in between.

Right now we get CNAM from the authorative telco sources.

Your post has a lot of points that lead the way for us who are starting. Very helpful and honest. Thank you.

Thanks for the share! Always great to read a post-mortem and glean wisdom and learning lessons!

Great work! Thanks for sharing.

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

Wrong, wrong, wrong.

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.

No one claimed this business wasn't real. I think you are the one that is the fashion victim that wants everything to have the same label. Honestly, you can probably define a startup as a company that hasn't figured out and proven their business model yet — clearly he doesn't meet that criteria.

Below you will find a comment by the OP that suggests he is going to really scale the business by expanding the offering and focusing on it. Probably using the revenue he is generating. Which is awesome — no need for VCs for his business as it was profitable from day 2. For this next tier of growth though, it probably will be a startup, one where he isn't sure whether the investment will pay off or not. If you ask me, that is the essence. Once you've figured that out, it isn't really a startup anymore.

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.

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!

We have since changed strategy, and are now hiring / scaling the team / company :)

You made the strategy you felt good with and that cant be wrong. :)

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.

Reply on news.ycombinator.com