Joel Griffith from browserless: from GitHub issue to bootstrapped business
Browserless founder Joel Griffith explains how a difficult Puppeteer issue became an eight-year bootstrapped company, why one technical article changed its trajectory, and how browser-using agents created a new wave of demand.
Browserless turns browser automation into infrastructure: customers connect to managed browsers instead of repeatedly solving Chrome’s dependencies, scaling and reliability themselves. Joel Griffith started it as a weekend “beer money” project and reached profitability with the first $200 customer.
Eight years later, a ten-person team serves an expanding market without venture funding. The growth story is less a single launch than a set of compounding habits—solve a painful problem in public, extract several outcomes from each piece of work, hire curious technical people and remain present long enough for the next market wave.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What did being a musician teach Joel about software?
Music gave him an early experience of getting better through deliberate practice and of improvising inside a set of constraints. Programming felt similar: there are rules, but skilled people can combine techniques and color outside them to create something new. Joel still values enough preparation to know the structure without scripting every move so tightly that discovery and useful surprises disappear.
What is Browserless, and why bootstrap it?
Browserless manages the unreliable infrastructure around automated browsers. Joel began it as a small side project, not an attempt to dominate a market, which meant slow years did not threaten a venture-growth target. That patience became an advantage: after surviving changes in Chrome, competitors and COVID, the company was already established when AI agents created much more demand for browser access.
Where did the first customer come from?
Joel struggled to run Puppeteer on a server and found that its most-commented GitHub issues were all variants of the same problem: Ubuntu, Red Hat and Docker users could not install and operate it reliably. He spent weeks developing a working Docker setup, shared the details openly, then offered Browserless to people who preferred not to maintain it. The first customer wanted roughly a thousand concurrent sessions and paid $200 per month—enough to put the bootstrapped service into the black.
What happened after the first payment?
The launch had produced almost nothing for two weeks, and Joel was close to shutting it down when the first Stripe payment arrived. Another customer followed within days. He kept notes while learning to scale the service, then six to twelve months later published a detailed account of what worked and failed. That post reached the top of Hacker News and remained one of Browserless’s best-performing pieces of content.
How does a small team compound its work?
Aim for two or three outcomes from every meaningful task. A bug fix can also become a technical article or video; a physical side project can teach a skill reused elsewhere. Browserless stayed at about ten people, hiring experienced contributors and giving them broad problems rather than tightly specified tickets. Even sales and marketing teammates can update documentation, query product data or fix small issues with modern coding tools.
What kind of content still works in the AI era?
Long-form, technically honest explanations remain the foundation. Engineers want context: the problem, the attempts, the result and what the team learned. That material can be cut into shorter formats and also gives answer engines enough substance to retrieve. Distribution opens the door, but retention is still personal; the customers who stay tend to remember that the company showed up, understood their work and helped when something broke.
What makes a good DevTools salesperson?
Listening, technical curiosity and a bias toward helping. The strongest sales conversations are not high-pressure pitches: the salesperson records the customer’s constraints and returns with a specific answer, sometimes an NGINX snippet or a fix outside the nominal product boundary. Browserless’s product-led motion means prospects often arrive after using the service, so sales can focus on the remaining technical and organizational details rather than explaining an unfamiliar category from scratch.
Why has cold outbound been difficult?
Across thousands of messages, response rates were a fraction of a percent. A new DevTool is valuable when someone has the relevant problem with enough urgency; before that moment, even a researched email has little power. Browserless invests instead in being visible and useful across the places developers learn, so it is remembered when the need appears. Outbound may still be tested, but it has not justified its cost or matched the team’s preferred way of working.
How has AI changed browser automation demand?
Daily signups had roughly doubled as indie developers and small companies equipped agents to use the web. Enterprises remained more cautious because agents are non-deterministic and need strong containment and review, often using them to scaffold work before humans take over. Joel views the present as the GeoCities era of AI: messy, formative and still open to influence. Browserless’s role is to provide guardrails and access while practitioners decide what responsible machine use of the open web should become.