In May 2012, while Customer.io was still small enough to fit inside a modest private beta, John Allison posted a little piece of Ruby code to the internet. It identified a user, attached a few attributes and sent them to a new event API. There was no orchestra, no launch-film fog, no founder gazing across a warehouse. There was a file that worked. This may be the most faithful opening scene available for Allison's career: the product promise translated into something another developer could run.
The company had begun full-time work the month before. Allison and Colin Nederkoorn, colleagues at the New York startup ChallengePost, had spotted an awkward separation. Web applications knew what their users were doing, while email tools behaved as if everyone were simply a row on a list. Their first product idea leaned toward analytics. Conversations with potential customers pushed them toward action instead: use behavior to decide what message should arrive, and when. Five companies entered private beta at $10 a month. The founding proposition was clear enough to fit in a sentence. Making it dependable would consume years.
Three snapshots of a system growing up
The bars mark distinct milestones, not a shared mathematical scale. Early demand, data volume and message delivery measure different things.
The sensible radical
Allison arrived at the founding moment by way of an engineer's apprenticeship rather than a personal-brand campaign. After earning a computer science and mathematics degree from Ouachita Baptist University in 2004, he moved through programming, contracting and software jobs that included iProv, Acxiom, IBM, Ruckus Wireless, weplay, GoodCrush and Gilt Groupe. At ChallengePost he became head of engineering; Nederkoorn led product. One knew how to turn an idea into a system. The other knew how to ask whether the system ought to exist. Their later division of labor at Customer.io felt less like destiny than a useful continuation.
There is a pleasing economy to Allison's public self-description: “Passionate about technology.” His older profiles add a little more color - world traveler, golfer, Arkansas Razorbacks fan - while former colleagues fill in the working temperament. One called him the rare combination of expert coder and expert communicator, able to explain without speaking down. Another remembered speed, insight and creativity during the compressed build of GoodCrush. The portrait that emerges is not of an engineer guarding an altar of complexity. It is of one making the complicated legible, preferably while everyone is still enjoying the afternoon.
Golf belongs in this story because Allison played on Ouachita's varsity team, but also because the sport offers a useful metaphor that startup profiles have not yet completely worn out. A good shot is a calculation disguised as a swing. The public sees its flight. The player has already accounted for lie, wind, club, distance and the small civil war between confidence and judgment. Customer.io's customers saw a message arrive after a person abandoned onboarding or returned to a product. Allison's team saw the data path that made “after” mean the correct second and “a person” mean the correct person.
“Embracing a distributed architecture ... has led to less time worrying about operations.”John Allison, on Customer.io's 2015 data stack
When one database became three
By 2015, the cheerful little API client had acquired heavy luggage. Customer.io had collected six terabytes of analytical event data representing more than 55 million unique users. The dataset kept growing, and it grew faster each time the company added customers. The original architecture could no longer be managed realistically on a small number of servers. Scale had arrived in its customary outfit: less trumpet blast than increasingly alarming operations calendar.
Allison's answer was a polyglot storage architecture. FoundationDB handled data where distributed transactions and consistency mattered most. Riak took large quantities of immutable data where availability carried greater weight. Elasticsearch indexed information for ad hoc queries. This was not technical variety for its own sake. Each system received the job that suited its guarantees. The elegance lay in refusing to make one tool impersonate three.
The 2015 division of labor
The decision also reveals the moral dimension of infrastructure, which is rarely introduced as such because that would frighten the servers. Customer.io was selling timing and relevance. If its data layer lost integrity, stalled or became too difficult to operate, then the promise to the marketer failed, and the marketer's promise to the recipient failed a moment later. Reliability was not a housekeeping concern. It was the product's manners.
Allison described the result in unfussy terms: less time worrying about operations, better reliability and the ability to expand capacity across the platform. The absence of romance is almost romantic. Founders are often asked for moonshots. Engineers ask whether Tuesday's traffic will fit. Customer.io needed both sorts of imagination, but only one of them had to wake up when a cluster complained.
A company designed to leave the room
Customer.io became fully distributed in 2014, before remote work hardened into a debate with its own vocabulary and branded water bottles. A distributed company forces decisions into writing and turns informal knowledge into shared machinery. That fits Allison's footprint. His code, public technical answers and explanations are small acts of transfer: here is what the system does; here is how another person can use it; here is why this component has this job.
- Allison and Nederkoorn begin full-time work. Five companies join the private beta.
- The growing team becomes fully distributed as Customer.io wrestles with increasing volume.
- Allison details the three-part database architecture behind six terabytes of event data.
- He concludes his operating tenure as CTO and continues as a director and board member.
- Customer.io crosses $100 million in annual recurring revenue.
The most consequential transfer came in August 2020. After eight years overseeing technology choices and managing engineering, Allison left the operating CTO role. Matthew Newhook, previously vice president of engineering, became CTO. Allison remained a founder and director, later described as board member and CTO emeritus. Founder mythology tends to treat the top job as a throne. A durable company treats it as a responsibility that can be handed to another capable person.
That handoff matters because the scale kept moving. Customer.io expanded beyond email into push notifications, SMS, Slack, webhooks and in-app messages. It added a visual workflow builder, mobile software kits and customer-data capabilities. By September 2025, it had passed $100 million in annual recurring revenue, served more than 8,000 companies and delivered 64 billion messages in the preceding twelve months. None of those later milestones belongs to one engineer. They do, however, test the foundations laid when the organization and its data were smaller.
First inning
$10Monthly price paid by each of the five private-beta customers in 2012.
At the handoff
8 yrsAllison's operating run as Customer.io's founding CTO.
Later scale
$100MAnnual recurring revenue crossed by Customer.io in September 2025.
The work after the title
Allison did not vanish into a ceremonial biography. He remained on Customer.io's board. More recently, public materials identify him as CTO of MakeLoveNotPorn, the social platform founded by advertising executive Cindy Gallop. In 2024 he wrote that he had worked with Gallop and her team for several months and publicly supported their crowdfunding campaign and planned educational expansion. The subject changed. The job remained recognizably his: turn an ambitious mission into technology that can bear weight.
The connection is more interesting than a standard second act. Customer.io sought to make automated communication more responsive to real behavior. Gallop's company asks technology to host a community and a cultural argument that mainstream platforms often decline to support. In both cases, the engineer works behind an experience shaped by trust. The database is never merely a database when people have entrusted it with something personal.
Allison's public trail remains refreshingly resistant to varnish. There are old Stack Overflow answers about Rails cookies and joins, a RubyGem with his name on it, cryptographic proofs linking his GitHub and Twitter accounts, a beach photograph and the moustache. Together they describe someone more convincingly than a page of executive adjectives could: technically curious, amused by the world, willing to share a useful piece of code, and apparently unwilling to mistake solemnity for seriousness.
The largest result of his work is easy to state and hard to picture. Billions of messages moved through a platform whose earliest public artifact could be read over coffee. Yet the better measure may be continuity. The company survived its early architecture, outgrew it, reorganized it, changed leaders and kept its founding idea intact: communication should respond to what a person actually does. Allison built the part that was supposed to recede from view. Fourteen years after that small Ruby file, invisibility looks less like anonymity than a job completed properly.