Buffer's first paying customer arrived four days after a seven-week build

The story

On 16 February 2011, Joel Gascoigne published the first Building Buffer post: Idea to Paying Customers in 7 Weeks: How We Did It. Two and a half months after launch he said Buffer had over 500 users, many of them active, and was generating revenue through paid monthly plans at a conversion rate of around 4 percent of people upgrading. Those figures are his snapshot from that week, not an audited cohort table and not a later ARR number. The essay is about validation order: stop coding, test interest, test willingness to pay, then build the smallest real product under a public deadline.

The product idea was deliberately thin. He wanted the scheduling feature of Twitter clients as its own application: a queue of tweets so he would not dump five at once while reading in the morning. Existing apps had not taken the suggestion. He believed a single feature could be delightful if it was the whole product. He also admitted the lean-startup mistake in the other direction. He had started coding Buffer before testing whether anyone wanted it. When he noticed, he stopped. Version one, he told himself, had to be more minimal than he thought, repeating Eric Ries's line that an MVP is probably much more minimum than you think.

The smallest test was two pages, not an app. One explained the idea. He tweeted the link and asked what people thought. A few people left email and useful feedback on Twitter and in mail. He treated that as first validated learning: people would consider using it. The next test was whether they would tolerate paying. He inserted a pricing page between the two, one extra click before the email capture, which both measured plan clicks and asked for slightly more intent. People still came through. A small number clicked paid plans. Only then did he start building a functioning product. The click was not a credit-card charge. It was a pricing-page signal.

Build time is the seven-week clock, and it is not the four-day clock. Hacker News had a November Startup Sprint: ship something by month end. He first told people it would take a week, then used the sprint as a cutoff, evenings and weekends, and still left out a guided signup he thought was vital because November ended. Buffer went live on 30 November 2010. He got feedback from that community and was prepared, from a previous product, for slow uptake and lots of course correction. He expected to be embarrassed by the rough version. The patience he wanted was a mindset, not a forecast of four days.

What happened next is the sentence this story exists to keep unmixed. Despite preparing for a long journey, he wrote that he had a first paying customer within four days of launching the rough product. That, for him, was the signal that the solution had enough value to be a business, not merely that emails had been collected. After that customer he refused the developer habit of piling on features. He shifted toward marketing and more customer development, keeping a balance once the product was good enough. When the signal is there, he wrote, shout about it. He later brought someone on for community and marketing, built internal views of the data, changed pricing, and started cohort analysis, which he promised for another post.

A 10 July 2020 Buffer essay, Reflecting on 10 Years of Building Buffer, restates the same launch in his voice without turning this row into a guest-post growth story. He launched on 30 November 2010 because of the November Startup Sprint and learned that you will always want one more feature. He had the first paying customer within four days of launch. After that customer he again describes the shift from building to marketing and customer development, and he says that is what led him to bring on a co-founder. This catalog already has a Leo Widrich row about later content scale. This entry stays on Gascoigne's landing-page tests, the seven-week build, and the four-day paid conversion of a live product.

The 2011 post's 500-plus users and about 4 percent upgrading are still not the same as four days. Users can be free. Conversion is a ratio he attached to paid monthly plans in February 2011, two and a half months in. Do not read 4 percent back onto the first week, and do not read four days onto the landing-page email experiment. The landing page never charged. The four-day customer paid after the product existed. If another Gascoigne page somewhere says three days, this pair of Buffer URLs both say four. This draft does not average them and does not import later million-user company statistics as if they were the validation story.

What he left out of the first version matters because it shows the sprint was a real constraint. Guided signup felt vital and still shipped later. He had already learned, on a prior product, not to skip asking whether the problem existed. Buffer's first emails were for questions, not only for a launch list. The two-page site looked like a product flow even though the product did not exist yet, which is why it could test signup behavior. That trick is specific. It is not a claim that every idea should skip a prototype. It is his account of recovering from starting to code too soon.

Press coverage, personal user work, and admin activity feeds in the 2011 closing section are aftermath, not the MVP test. They show a founder who treated four days as permission to talk about the product rather than as proof the roadmap was finished. He asked readers whether they had taken longer to validate an idea. The useful editorial move is to answer with his clocks: two-page interest, pricing-page intent, seven weeks of nights, 30 November go-live, four days to a payer, then a February snapshot of 500-plus users and about 4 percent paid.

Independently verified: false. There is no processor export in these posts. The $5 first-internet-money line that appears in later Buffer history writing is not in the 2011 essay fetched as the original here, so this record does not promote it as a 2011 figure. What Gascoigne signed in February 2011 is seven weeks, four days, 500-plus users, and around 4 percent upgrading. Keep those as founder-reported, and keep them apart from co-founder content programs that belong on another card.