My Startup, a Retrospective
rdegges.com
My Startup, a Retrospective
1–10 of 35 posts
Re: My Startup, a Retrospective
#2This 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!
Re: My Startup, a Retrospective
#3Great 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.
Re: My Startup, a Retrospective
#4Great work! Thanks for sharing.
Re: My Startup, a Retrospective
#5I 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.
Re: My Startup, a Retrospective
#6Great 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.
Re: My Startup, a Retrospective
#7I 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.
Re: My Startup, a Retrospective
#8I 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?
Re: My Startup, a Retrospective
#9>>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 :)
Re: My Startup, a Retrospective
#10>>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.