Before there was a database, there was mud. Andrew Ofstad grew up in a log cabin in rural Montana, near a lake that dropped in the fall and spring until a broad, glistening flat appeared. He had two older brothers and three friends down the road. Structured entertainment was scarce. Boredom, that excellent and underfunded art teacher, was plentiful.
The children went out and made things. They shaped sculptures. They built little dams. They messed around until an empty patch of landscape had acquired form, purpose and, presumably, a great deal of mud in places mud had not been invited. Ofstad later told the story as the beginning of an instinct: when nothing has been supplied, make something.
It is tempting to treat childhood anecdotes as decorative prophecy. Most mud forts do not become software companies. Yet the pattern repeats too neatly to ignore. Video games led him from play to wondering how invented worlds worked. Electrical engineering at Duke promised a view beneath the surface. Product design became the practice of giving difficult machinery a humane front door.
One instinct, three materials
The friend who failed to arrive
At Duke, Ofstad found two fellow technology obsessives in Howie Liu and Emmett Nicholas. They programmed, played games and worked as lab partners while many classmates looked toward finance, consulting or medicine. Their interest was less conventional on that campus at that moment: they admired people who started companies and talked vaguely about building one together.
After graduating in 2008, Ofstad joined an Accenture research and development group that built prototypes for large companies. He recommended Liu for a role there. The company hired him. On the morning Liu was meant to start, the desk beside Ofstad remained magnificently unoccupied. Liu called, anxious and apologetic: he had decided to start a company instead.
Ofstad, who had put his credibility behind the referral, joked later that he was about to be fired. Liu went through Y Combinator, sold his company Etacts to Salesforce, and learned how often business software amounted to a database with views, rules and workflows laid over it. Ofstad moved to Google. Their empty desk was merely an appointment postponed.
A map should mostly be a map
Google placed Ofstad in its Associate Product Manager program. His first rotation came during Android's early race with the iPhone, when Facebook and Twitter had not yet built their own Android applications. The Android team did the work, and Ofstad managed those two social apps. Software was tied to phone releases and carrier deadlines. Shipping felt less like the endlessly revisable web and more like sending a CD-ROM out the door.
His second rotation was Maps, a product he loved and a product burdened by its own success. By 2010, imagery, Street View, business information, satellite layers and directions had collected around the map. Multiple talented teams had added legitimate features. Together, they produced a lesson in organizational sediment: every addition made sense locally while the whole became harder to see.
A Seattle team had developed a way to render maps directly in the browser with WebGL. New technology supplied the excuse to begin again. Ofstad and the team limited themselves to a small set of interface components, borrowed the contextual discipline of mobile apps and kept the map dominant. A search box could remain visually modest while expressing an enormous range of intent. The ideal component was, in Ofstad's phrase, “simple yet expressive.”
You have to find the pieces of UI that are simple yet expressive.
This was not minimalism as a taste in empty rooms. It was simplification as systems work. Removing visible controls required a stronger model of what people were actually trying to do. The map could not merely look calm. It had to stay powerful while behaving as though calmness came naturally.
The database beneath the table
While Ofstad was working at Google, he and Liu kept returning to a shared frustration. Business applications were either rigid products that forced teams into somebody else's process, or custom systems that demanded database expertise and programmers. Spreadsheets were flexible and familiar, but they had not been designed to manage every peculiar workflow people entrusted to them.
Their opening was the space between those options. Could a relational database feel as immediate as a spreadsheet? Could the people who understood the work also shape the software? They did not begin with a giant platform. An early prototype ran in browser local storage, with no proper back end, because the first risk was conceptual: could ordinary users understand and enjoy the interaction at all?
Nicholas joined shortly after the work began. The division of labor followed their strengths. Ofstad stayed close to design and front-end engineering. Nicholas concentrated on the back end. Liu worked across the back end, product and design, and the three decided early that he would be CEO. Consensus was preferred; a final decision-maker was named before disagreement could make the question political.
The founding logic
Their first real customer arrived with inconvenient timing, which is how real customers often arrive. ScholarMatch, a San Francisco nonprofit, needed to track students, donors and events. Its alternatives included an expensive Salesforce integration or custom software. The founders showed a half-functional demo. The nonprofit asked when it could start using it. Airtable was not ready, but the job was.
The team learned by showing prototypes, watching confusion and returning to the work. They also read backward. Ofstad studied Alan Kay, Doug Engelbart and J.C.R. Licklider, early computing thinkers who imagined software creation as a broadly available human activity. For a permissions problem, a decades-old paper written for the FBI offered clearer concepts than many contemporary products. Architecture books by Peter Zumthor and Cesar Pelli supplied another model: beauty mattered, but the building still had to stand.
Craft acquires a clock
Airtable's patience produced a coherent foundation, but patience has an evil twin with excellent taste: perfectionism. The founders believed an early iPhone application might turn Airtable into a personal organizing product in the mold of the era's popular consumer software. With only a tiny team, they spent roughly eight months to a year making the app polished and feature-complete.
Ofstad later called that depth of investment a mistake. Some foundational decisions deserved long thought; other features needed less scope and earlier contact with users. The distinction is more useful than the familiar argument between speed and quality. A door hinge and a building foundation may both be made carefully, but only one should delay the house.
Airtable eventually found its most enthusiastic adopters among tinkerers inside organizations: the person who enjoyed shaping a tool and then seeded its use across a team. Film crews, marketers, product groups and others built systems that were specific without being custom-coded. The founders had not predicted every vertical. They had built material that could travel.
Spend a lot of time talking to customers who have use cases that are far removed from yours.
That warning mattered because Airtable used Airtable to build Airtable. It held product roadmaps, editorial calendars and bug tracking. Using one's own product creates insight and a gratifying closed loop. It also creates a hall of mirrors. Ofstad pushed for customer tours and support rotations so the company would encounter work unlike its own.
The company changes hands
By 2022, Ofstad described Airtable as a connected apps platform used by more than 80 percent of the Fortune 100. He spoke of being surprised that people had heard of it, an amusingly durable trace of the builder who still pictured a scrappy company. His formal focus had widened from pixels and front-end code to long-term product bets and the customer voice in major decisions.
In October 2025, he appeared at a live Founder Mode conversation in San Francisco and revisited the browser-only prototype, the tradeoff between speed and craft, leadership and the arrival of AI. Then came the kind of milestone that redraws a company timeline in a single line: on September 4, 2026, Bending Spoons completed its acquisition of Airtable.
Ownership changed. The original question did not. Generative AI can make software appear at conversational speed, but abundance does not abolish product judgment. More things can now be built; somebody must still decide what deserves to exist, how it should behave and whether the person using it feels enlarged or merely supervised.
Ofstad's career offers no grand unified theory, and that is part of its usefulness. It offers a recurring move. Look beneath a complicated product until its essential actions become visible. Choose a few components capable of expressing a great deal. Let users manipulate the thing itself. Then leave the workshop before polish becomes privacy.
The mud flat is still the best image. A blank expanse can be freedom or inconvenience depending on whether someone can imagine the first shape. Ofstad has spent his working life lowering the distance between those two conditions. The machinery matters. But if it has been arranged well, what the user notices is possibility.