Geoff Schmidt was twenty when he moved into Matt DeBergalis’s basement in Cambridge, Massachusetts. He had left MIT after one term, raised money for a company and met DeBergalis through someone on his team. A mutual friend and an available room did their work. Years later, the two would be running a software company together. The basement deserves a modest place in the history of developer tools.
In July 2025, Schmidt handed Apollo GraphQL’s chief executive job to that same former housemate. DeBergalis had his “complete trust and confidence,” Schmidt wrote. After fourteen years building Meteor Development Group and Apollo together, the partnership was changing its division of labor. Schmidt would stay involved, concentrating on technology and the wider GraphQL ecosystem. The company he had helped build could now be led by someone he had known long before there was a company.
There is a useful clue here to the rest of Schmidt’s career. He keeps returning to the space between people and what they want to make. A developer wants to build an application; first comes a discouraging quantity of infrastructure. Different engineering teams want to contribute to one product; their systems speak different dialects. Schmidt has spent years working on those awkward arrangements. Much of his work concerns making it easier to begin.
A travel guide loses its job
Before Meteor, Schmidt had been an early employee at Asana. He had experienced the effort required to build the underlying machinery for a responsive web application. That experience traveled with him into Y Combinator’s summer 2011 batch, where he, DeBergalis and Nick Martin were working together. Their original idea was a travel recommendation application. The machinery they needed to build it proved more interesting than the itinerary.
Other founders were struggling with the same development problems. Schmidt and his colleagues had already acquired useful experience solving them. A framework could carry that experience from one project to another, sparing each team the ritual of rebuilding its foundations. The travel application gave way to Meteor. Somewhere, a holiday went unplanned; a considerable amount of JavaScript took its place.
Meteor’s early preview arrived in 2012. The proposition was appealingly direct: build rich, responsive applications using JavaScript across the client and server. In July, Meteor Development Group announced $11.2 million in funding led by Andreessen Horowitz, with Matrix Partners participating. Spring creator Rod Johnson joined the board. The investors were backing a team that wanted to make sophisticated application development available beyond the companies able to assemble enormous engineering departments.
The money bought working time. Schmidt described it as certainty that the core team could concentrate on Meteor for years, rather than taking consulting jobs or building a separate application to pay the bills. His reaction to closing the round was pleasantly practical: “It’s a relief to make this announcement and get back to coding.” Fundraising had an obvious attraction. It could eventually be finished.
The pleasure of being understood
When Meteor appeared on Hacker News, the reaction exceeded Schmidt’s expectations. Developers, executives and open-source contributors responded from around the world. By 2014, the team had outgrown its space at Heavybit and moved into offices in San Francisco’s SoMa district. An idea formed among fellow startup founders was becoming a shared project with a much larger constituency.
That response matters to understanding Schmidt. A framework asks people to trust its authors with decisions that will shape their working lives. Enthusiasm on a discussion board can become adoption, contributions and companies built on the code. Meteor’s reception suggested that the frustrations its founders had noticed were widely shared. People wanted the sort of dynamic interfaces they used every day without first having to build a technology company’s worth of infrastructure.
Schmidt later recalled Meteor 1.0 celebrations taking place in roughly 134 cities on the same day. Galaxy, its hosting platform, gave the project a commercial business. Yet success also brought a different class of problem. Larger organizations had more existing systems, more teams and more constraints. A small group starting from scratch could commit to one coherent framework. An established enterprise usually had rather more history to accommodate.
A useful change of mind
By the end of 2015, the team was considering what a new Meteor data layer should look like. Developers wanted to connect to services beyond the MongoDB database associated with the framework. They wanted native mobile experiences as well as web applications. They also wanted tools that could enter an existing codebase a piece at a time. React’s adoption offered a lesson: asking for a small commitment could take an idea further.
Apollo’s first open-source components followed in early 2016. The new project took ideas developed through Meteor and made them available more independently. GraphQL supplied a shared query language. Apollo could work with the systems an organization already possessed, rather than making a fresh start a condition of entry. For a founder accustomed to simplifying development, the question had expanded: how much could be improved without asking everyone to move house?
Schmidt was unusually candid about the architectural revision behind this work. In Meteor’s original design, he had favored letting clients work directly with database queries. He worried that an abstraction would hide useful differences between databases. Experience in larger organizations changed his view. He acknowledged the merits of an approach associated with DerbyJS, an early competitor: an abstract schema could separate an application’s needs from the particulars of its back-end systems.
There is something enjoyable about a technical founder publicly conceding that a rival had a point. Software architecture encourages strong opinions, and conference stages rarely suffer from a shortage of them. Schmidt’s account allows for something more useful: a decision can make sense for one kind of team and become an obstacle for another. The people using the software had supplied a better argument than loyalty to the original design.
“Coalition building, and patience”Geoff Schmidt on lessons from a decade of open source
The organizational chart inside the code
The enterprise problem was partly one of coordination. Back-end teams build separate services; an application needs an experience assembled from their work. A customer opening a screen has little interest in how many departments contributed to it. Engineers, meanwhile, need room to maintain their own systems. A shared graph offers a way to describe how the pieces relate without forcing every team to become the same team.
Federation gave that arrangement a technical form. Separate graphs could be composed into one interface while individual teams retained responsibility for their parts. Schmidt created GraphQL Federation with Martijn Walraven. The partnership belongs in his story because Apollo’s identity can otherwise swallow the engineering work behind it. Alongside his years as CEO, there was a specific architectural contribution, made with a colleague, to how organizations could build and manage a graph.
In his 2019 discussion of Apollo’s business, Schmidt described a progression from early customers seeking technical partnership to organizations needing management tools around their graphs. As teams grew, so did the need to track schemas, review changes and coordinate development. The commercial opportunity grew out of those working requirements. Open-source components and paid organizational tools could serve different stages of the same project.
What $130 million was for
In August 2021, Apollo announced a $130 million Series D led by Insight Ventures, with Andreessen Horowitz and Matrix Partners participating. The company’s valuation exceeded $1.5 billion. Its announcement also reported more than 17 million monthly open-source downloads and more than six billion daily queries. Those figures belong to that moment in Apollo’s history. They show how far the project had traveled from an experimental data layer.
Raised to fund Apollo’s graph technology and developer platform.
Schmidt framed the financing around Apollo’s mission to help application developers help the world. He also spelled out concrete work ahead: faster graph routing, support for more complex graphs, and better security and management tools. Infrastructure needs patient investment because its users notice both its presence and its absence. The useful feature may be invisible until a query slows down or a change breaks someone else’s application.
GraphOS, introduced in 2022, extended the effort to operate and connect supergraphs. Schmidt’s stated ambition reached beyond the boundaries of one organization: developers should be able to combine useful data and capabilities from elsewhere as well. It is a large ambition, but it follows the earlier concern with access. Each project reduces some of the preliminary negotiation between having an idea and being able to build it.
Rooms for other people
Schmidt’s interest in shared infrastructure has also taken a physical form. Outside Apollo, he created Monument, a live/work community for scientists and artists in San Francisco. His public biography described twenty-four units. The detail widens a portrait otherwise dominated by query languages and funding rounds. Making room for other people’s projects can involve buildings as well as software.
It also gives the basement anecdote a pleasing echo. A room helped begin one long collaboration; later, Schmidt made spaces where other collaborations could take place. His stated habit of seeking people beyond his existing circle fits both stories. The parallel is an interpretation, but the choices are concrete: live with someone new, build with longtime partners, and create a place where people doing different kinds of work can meet.
At API World in 2024, Schmidt and Michael Watson addressed combining APIs for the AI era. By July 2025, DeBergalis was taking over as CEO as Apollo concentrated on the demands of agents and enterprise data access. Schmidt remained involved in advancing the technology; Apollo’s leadership page lists him on its board. After years of helping developers spend less time on the preliminary machinery, his own job had been rearranged to give him more time with it.