What happens between agreeing to try and actually starting?

An online business could have customers ready to buy and still face an awkward task: connect its product to a system that could accept payment. Stripe approached that task through the person implementing it. The developer was not necessarily the company's ultimate economic buyer, but was often the person who could make a payment integration happen or leave it unfinished. Understanding that position made the adoption problem more specific than a general claim that online payments should become easier for everyone.

Paul Graham's 2013 essay describes an early practice he observed among the Collison brothers at Y Combinator. When another founder agreed to try Stripe, they offered to set it up on the person's laptop immediately. Graham called this the Collison installation. It is an investor's account of a concrete customer-acquisition practice, not evidence that every early customer was acquired that way. Its value is the distinction it makes visible: a positive conversation was not yet a working integration, and the founders treated the space between them as work they could do.

Contemporary Wired reporting in 2012 described Stripe's approach to payment acceptance and its initial expansion into Canada. The report included a Canadian beta customer's frustration with the difficulty smaller businesses faced arranging card acceptance. That is evidence of a particular user's experience, not a survey of all merchants. It nevertheless gives the product's appeal a practical setting. The company was offering an easier entry into an existing financial system, rather than inventing the desire to sell goods or services online.

Stripe's own technical retrospective helps explain the limits of the famous idea that payments could be reduced to a few lines of code. The company described an early model built around collecting payment details and creating a charge. It also explicitly distinguished an impressive first successful transaction from a complete production integration. The demonstration made progress visible quickly. A real business still had to handle what happened before and after that moment, including how its application responded to the result. Simplicity at the starting point was not a claim that every operational requirement had disappeared.

The interests around that first transaction were connected. The developer wanted a clear implementation path. The merchant wanted dependable payment acceptance. The customer wanted a purchase to complete without unnecessary interruption. Financial institutions and payment networks still had requirements that an attractive interface could not repeal. The teaching interpretation is that a platform can create value by absorbing or organizing complexity for a particular participant, while remaining responsible for its place in the wider system. Removing work from the developer's screen does not remove the work from existence.

The hands-on installation also offered a way to observe friction. A founder helping a willing user begin can see which step is confusing, which prerequisite is missing, and whether the promised benefit appears quickly enough. That is a different learning opportunity from asking whether the product sounds useful. It does not mean an organization should provide unlimited free implementation forever. The challenge is to learn which obstacles are temporary support needs, which can be designed out, and which reveal a customer whose underlying requirements are not a good match.

Stripe's later expansion should not be read backward as proof that a concise interface guaranteed success. The narrow episode concerns the conversion of interest into initial use, supported by infrastructure capable of carrying the transaction. The practical question for another founder is what happens immediately after someone says yes. If progress stalls at that point, more awareness may not be the first remedy. Watching a real user cross the threshold can reveal whether the obstacle lies in confidence, coordination, implementation, or the product itself. That evidence is more useful than a growing list of people who intend to try it someday.

For a discussion tailored to your team, explore a workshop with Julien.