What I learned from working with my first client
@RandallBrown's retrospective from 2011 captures the critical transition from initial concept to the first dollar of customer revenue.
Core Principles for Independent Builders:
Early traction rarely comes from passive launches; it requires direct manual outreach, personal network activation, and high-touch customer support.
Narrowing down the target audience to a specific niche allows solo founders to out-position generic horizontal competitors.
Underpricing out of fear of rejection is common; founders who set premium pricing often discover higher customer satisfaction and lower churn.
Community Debate Themes:
Discussions analyzed Show HN launch mechanics, cold DM outreach conversion rates, and the psychology of validating customer demand before writing code.
CATEGORY Zero to One →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE ★ 30 points
TOTAL DISCUSSIONS 3 comments
"Then I added a little padding time because everything always takes longer than expected."
If you are implementing something which is almost exactly like something you personally have implemented before, then your estimate will be almost exact because you should have tracked how much time you spent on the original ... and assuming that too was a re-implementation of something you'd already done the R&D on. IOW, this is at least your third time.
If you are implementing something for which you have references that are very close to what you are building (but you didn't build it) and you already understand them, then you can make a reasonable estimate of the time to implement. In this case the OP's advice works .... add some padding. The more granular your breakdown of the problem, the better you estimate will be.
But when there is R&D on the problem, you are not talking about 'padding', but 'factors'. If you are doing something that is new to you, but you think you have (or can find) decent references, then you can estimate based on how you hope it will go (based on your breakdown of the problem), and multiply by 2.
If you can't find references, then factors of 3 or 4 beyond your ideal development scenario will be more realistic.
It's worth noting that if you are in the last scenario, then you probably weren't a good choice for the project. Also, 'agile' pricing would be better, but either fixed pricing or giving clients some idea of what to budget is more typical.
Like many things, knowing what you're worth (how much you should charge) and estimating project time take practice. The more you do it, the better you get (hopefully).
Took me a while to learn that one, but it's so true.