Making dev team decisions, selling Drip, and founder milestones

Executive overview

Growing dev teams hit decision gridlock when no one owns final authority on technology choices. Product decisions and tech decisions need different structures — tech belongs to a designated lead, product to a focused owner with clear vision.

Selling a company at the right window beats holding for a higher price that may never come. Burnout and scaling limits are real signals.

Finding a mastermind of peers who understand your metrics is more valuable than sharing milestones with family or friends who don't.

Making decisions in a dev team

• Designate a tech lead who owns the decision — and the consequences
• Establish guiding principles upfront: battle-tested vs. cutting-edge, documentation quality, team familiarity
• Ask advocates to write up their case against those principles before debating
• Prefer boring, proven technologies; skepticism of shiny new tools grows with experience
• Avoid mimicking large-company architecture — microservices and polyglot stacks are for 500-engineer orgs
• Product decisions (what to build) are a separate skill from engineering; don't delegate them to developers by default

Regrets about selling Drip

• Neither founder regrets the sale; burnout and scaling complexity had become the dominant work
• Strategic acquisition windows are rare — a serious buyer willing to pay a premium doesn't reappear on demand
• Post-acquisition time was unexpectedly positive: senior hires, real resources, and a chance to extend the vision
• Sadness about post-exit brand and pricing changes, but outweighed by what came next
• A three-and-a-half year intense journey felt twice as long — a sign of how much was compressed into it

Web scraping: threat or distraction?

• Determined bad actors can scrape almost anything — native mobile apps don't stop them
• Practical mitigations: paid-only access, limited trials, no data export for trial users, rate limiting, seeded false data for copyright tracing, clear terms of service
• Keeping data continuously updated makes any one-time scrape go stale quickly
• Platform risk and customer acquisition are bigger early-stage problems than scraping

Quitting a full-time job with platform risk

• Key question: if the platform kills your product overnight, how long can savings sustain you?
• A marketable software skill set means the real downside is getting a job — not ruin
• Platform risk mitigation: expand to multiple platforms so no single one is a kill switch
• Revenue rarely drops to zero instantly; there is usually time to adapt or diversify
• The bigger regret for most founders is staying employed too long, not leaving too early

Sharing milestones with family and friends

• Lay people can't interpret SaaS metrics — small numbers sound trivial, large ones sound like wealth
• Abstract milestones for non-founders: "this now covers my living expenses" rather than dollar figures
• Share precise numbers with a mastermind or founder peer group where context is understood
• Celebrating with the right people protects against awkward money dynamics with friends or family
• Recommended resource: Microconf Masterminds matching service for finding peer groups

Mastermind structure and book recommendations

• Ideal size: three people; four is manageable, two is thin
• Mix experience levels that are close but not identical — too far apart and advice loses relevance
• Strong personal rapport and full transparency make masterminds last
• For solo founders, a good mastermind functions as a surrogate co-founder
• Recommended books for founder book clubs: The Mom Test (customer interview discipline), Traction (marketing channels), The Entrepreneur's Guide to Keeping Your Sh* Together* (founder psychology)