How We Built a Lean Startup Inside a 200 Person Company
In this technical retrospective (2013), @andygcook shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE 51 points
TOTAL DISCUSSIONS 22 comments
We had done this at a previous company I had started (with others). We were over 200 people at the time (~ 75 developers), and had created a situation where there were serious clashes between the "start-up guys" (who preferred to put ideas out there quickly, warts and all) and the "serious engineering guys" (who didn't like the idea of supporting those things, and preferred no warts to ever be shown to customers). [0]
Our solution was to create a new team, with a new VP to report to, who was aligned with their goals explicitly. The team's focus was to simply find interesting new product spaces, prototype the solutions quickly, and get 1 paying customer. The "start-up guys" were moved to this team, and they hired more like-minded developers. The normal R&D department would take up the prototype as a proof-of-concept once it was worked out that there would be enough customers to justify the longer development of the final product. While it resulted in the creation of the company's latest product, it definitely did not solve the problem it was designed to - but it did increase the understanding of the engineering team as to what would, and wouldn't work when they got to work on the problem. Which, is really what everyone needed (even if it wasn't what they wanted).
[0] - this is an over-simplification, of course
I find the "lean startup" concept to be humorous. it's like pg's y-combinator essays in MBA-ese. Build an MVP and get users to provide feedback, and iterate like crazy. As long as you're starting from MVP, the rest adheres to the principal of "JFDI". if JFDI is unclear to you, and you're looking at a flowchart to understand what JFDI means in context, then you are probably not going to understand it, ever.
For those of us who are in a startup and are intimately familiar with all of the issues surrounding with being in a startup, I don't have much appreciation for people working in an established company to co-op the word startup. You have a lean department, not a lean startup.
There are a lots of articles that explain the concept of lean startup but not as many that talk about how to apply it. Thanks for sharing. This should be helpful for anyone thinking about testing a two-sided network problem.
Thanks for sharing Andy — I'm preparing a talk "Applying Lean Startup to the Enterprise" and will reference your post :)
Great looking Ghost blog too, btw.