

My Startup, a Retrospective - rdegges
http://www.rdegges.com/my-startup-a-retrospective/

======
wpietri
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/](http://www.rdegges.com/im-working-on-a-startup/)

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

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

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

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

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

~~~
rdegges
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 ^^

~~~
rbsn
Could your performance problems be closer related to
[http://news.rapgenius.com/James-somers-herokus-ugly-
secret-a...](http://news.rapgenius.com/James-somers-herokus-ugly-secret-
annotated) than the performance of Django or your code?

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

------
carbocation
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!

------
DjangoReinhardt
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](https://github.com/rdegges/django-skel)

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

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

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

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

~~~
aaronblohowiak
scale before find paying customers?

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

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

~~~
rdegges
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-side-effects/) \-
[http://www.rdegges.com/service-oriented-
problems/](http://www.rdegges.com/service-oriented-problems/)

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

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

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

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

------
glenntnorton
Great work! Thanks for sharing.

------
spullara
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](http://en.wikipedia.org/wiki/Startup_company)

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

~~~
spullara
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!

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

