How and when to go full-time on your bootstrapped product

Executive overview

Working a day job alongside a side project means at least one of the three — job, family, or product — will suffer. The question isn't whether to make the leap, but how to time it safely.

Both Rob Walling and Dave Rodenbaugh delayed going full-time until their product revenue hit roughly 80% of their consulting income. Dave waited over a decade; Rob took the plunge earlier but with lower recurring revenue.

The real barrier isn't financial — it's psychological: the safety threshold is wherever your own financial trauma sets it.

The consulting trap and the 80% rule

• Dave held onto consulting for 11 years despite growing product revenue — the income felt too safe to abandon
• Rob quit consulting once products hit ~$8–9K/month, far below his $20–25K consulting rate; lifestyle was still lean enough to absorb the gap
• Both converged on the same benchmark: ~80% of consulting income before pulling the trigger
• WordPress plugin renewal rates of 26–33% made Dave's early products unsustainable; switching to SaaS fixed the recurring revenue problem
• Dave's father's job loss in his 50s created financial trauma that set a high safety bar — knowing your own psychology matters as much as the numbers

Balancing three things at once

• Three simultaneous demands — job, family, side project — guarantees at least one suffers
• The paying job almost always wins; family or product absorbs the sacrifice
• Neglecting your relationship is not sustainable: it resolves as either a hard reset or something worse
• With a demanding full-time job, the side project can only be kept in sustenance mode — no hyper-growth
• An undemanding full-time job (15 productive hours out of 40) can free up real side-project time, but that arrangement rarely lasts
• Reducing to part-time consulting (e.g. dropping to 20 hours) is an underused middle path worth proposing to clients
• Burnout is a question of when, not if, when running at full capacity across all three

Nights, weekends, and the grind reality

• Rob's pattern: full-time consulting days, 7pm–midnight on products, every night
• Adding kids compresses the window further — kid asleep at 7, then work until midnight on five hours of sleep
• The mental shift after quitting consulting: all that late-night work now happens during the day, evenings become free — a genuine reset
• Grinding through this phase works for short sprints; the body and relationship demand rest between them

Unlearning the employee mindset after going independent

• The biggest surprise for both: how long it takes to stop treating self-employment like a job with fixed hours
• Dave took ~4 months to feel okay taking Friday mornings off with his wife
• Rob spent months calculating how to "make up" vacation hours — then couldn't stop feeling guilty at coffee shops even while thinking about the business
• The hourly billing mental model (one hour = money) is deeply ingrained and doesn't disappear automatically
• Productivity has windows; protecting and using those windows — then stopping — is the sustainable pattern

The arrival fallacy and purpose after independence

• Initial relief and happiness after going full-time fades within 6–12 months
• Humans re-set their happiness baseline; the next mountain becomes visible immediately
• Dan Pink's autonomy–mastery–purpose framework: once you've automated a business and achieved mastery, purpose disappears and boredom follows
• Having something to jump to before selling matters — Dave's reason to hold recapture is the absence of a next purpose
• Life-changing exit thresholds matter: $1–2M is not "never work again" money; $20–30M changes the calculus on "what would I do next?"

Acquiring vs. building from scratch

• Acquiring a product with existing revenue skips 12+ months of nights-and-weekends pre-launch grind
• Rob's first acquisition (DotNetInvoice, $11K in 2006) had inflated revenue figures — wild west era — but still saved a year of building
• Dave's successful products were all acquisitions; his from-scratch build (SupportVine) failed after $50K, partly from not validating demand first
• Acquiring gives a level-up advantage: product-market fit is already proven, some traction exists, and you can see the gaps to fix
• Most developers resist this because they want to build their own code — a preference worth examining honestly