Oskar Bruening Put Precision in the Business of Getting Lost

A horseback lesson is not a T-shirt, although the internet spent years pretending otherwise. The shirt can wait in a cart. The horse has a timetable. The rider may need a helmet, transport and an answer about what happens if it rains. While one customer dithers, another may take the last available place. Then there is the operator, quite possibly standing beside a paddock with one bar of reception and no desire to become a database administrator.

This is the sort of untidy system that has occupied Oskar Bruening since he co-founded Peek with Ruzwana Bashir. Peek began with a consumer proposition: make tours and activities as discoverable and bookable as flights and hotels. Its deeper technical challenge soon appeared behind the counter. Thousands of small operators needed reservations, payments, waivers, inventory, marketing and guest communication, often all at once and preferably before the next group arrived.

Bruening was equipped for complexity. He had studied electrical engineering and computer science at MIT, worked at VMware, built data-loss-prevention technology at Vontu and Symantec, and managed engineering at Pipewise. He was named on patents involving confidential-data detection and policy enforcement. His early career dealt in secrets, rules and edge cases. Travel would give him more edge cases, better scenery and a clientele wearing life jackets.

A company before the day was over

The founding story moves at startup speed. Bashir had been trying to plan a trip to Istanbul and found herself spending roughly 20 hours researching things to do, then telephoning individual businesses to arrange them. Flights and rooms had moved online. The memorable part of the trip remained hidden across brochures, disconnected websites and unanswered calls. After meeting Bruening in New York, the pair decided by the end of that day to start a company together.

Their backgrounds were neatly mismatched. Bashir brought finance, commerce and the original frustration. Bruening brought years of enterprise software and an instinct for the machinery beneath the page. Together they attacked both sides of the transaction. Peek.com gave travelers a place to find and reserve activities. Peek Pro gave operators the tools to take those reservations, manage the day and understand the business that emerged from the data.

It was an important distinction. A marketplace without dependable operator software is a glossy window attached to a chaotic stockroom. Operator software without demand is an efficient desk in an empty shop. Connecting the two created a loop: better tools made more experiences bookable, and more bookings gave operators a reason to modernize. The consumer saw a simple confirmation screen. Bruening's team saw payments, capacity, messages, waivers and a small orchestra of clocks.

A precise eye, trained twice

There is another line on Bruening's education that changes the picture. After MIT, he studied drawing, photography and mixed media at the San Francisco Studio School. The engineer had gone to art school. On a conventional résumé, this might look like a pleasant detour. In his work, it reads more like a second operating system.

Engineering teaches a person to make the invisible explicit: inputs, dependencies, failure states. Art teaches a person to look long enough for the obvious to become strange. Peek required both. A tour booking resembles ordinary commerce only until one watches what actually happens. Time is inventory. Weather is a dependency. A guest's height or weight can be operational data. A waiver is part of checkout. A ferry return cannot be casually separated from the ferry going out. What looks like a button on a screen may be the neat end of a very physical knot.

The hardest question moved from “How can we build it?” to “What is worth building?”A recurring theme in Bruening's product philosophy

In 2017, Bruening wrote about the failure of the familiar retail cart for activities. The useful model, he argued, came from elsewhere in travel. Airlines and online travel agencies already knew how to retain context about dates, party size and destination while suggesting an additional purchase. Peek's answer, Bundles, used rules to offer a compatible second experience inside the booking flow. Early operators testing it reported a 20 to 25 percent rise in average order value.

The important move was not the upsell. It was refusing a lazy analogy. Software people love patterns because patterns save time. Customers have the irritating habit of living outside them. Bruening's method has been to borrow carefully, then return to the operator and see what survives contact with a real business.

The customer is carrying a paddle

That contact has made Bruening unusually specific about customer empathy. A rental operator worries about reception dropping on the beach. A reduced staff needs automation that does not create more work. A group needs equipment assigned without collisions. During the pandemic, Peek added support for distancing, cleaning time, advance waivers, contactless payments and virtual sessions. These were not abstract digital-transformation projects. They were the difference between an operator opening the next morning or remaining closed.

His own appetite for experiences is not corporate decoration. Peek describes him as the explorer who takes side roads simply to see where they lead, preserving fleeting moments on film. His remembered trips include a candlelit conversation with a Buddhist monk in Mongolia, an accidental discovery of Jerome, Arizona, and nights in a tent on the beaches of Jeju Island. The person standardizing a transaction is fond of the unscripted event.

He grew up near Lake Constance in Germany. Later, living in Ohio after San Francisco, he found Lake Erie almost difficult to comprehend. He named it his favorite place in the state and his happy place for kayaking and sailing. There is something fitting in an engineer being humbled by scale, especially one whose professional task is to contain countless local businesses inside a reliable system.

Fewer engineers, heavier decisions

Bruening's view of technology has shifted with the tools. He has observed that work once requiring a team of 50 engineers can increasingly be handled by ten. This does not abolish difficulty. It relocates it. When building becomes cheaper, choosing badly becomes more expensive. The product manager gains leverage, along with an alarming number of ways to spend it.

His description of a good product leader is telling: organized and creative, clear without being authoritarian, humble, empathetic and able to judge from incomplete data. It sounds less like a specification for software and more like a specification for adulthood. There is no single degree for it. Bruening expects companies to put more effort into growing this kind of leader because technical acceleration makes discernment scarce.

He applies similar thinking to management. His blunt advice is to “over-invest in first line managers.” New managers sit at the most sensitive joint in a company. They translate executive intention into an employee's ordinary week, yet are often learning the job while doing it. Bruening recommends training, a safe place to ask questions, access to executives and a culture that joins empathy with accountability. A company, in this view, is another distributed system. The bugs are merely better dressed.

The operating system meets the outside world

Peek's scale now makes the original problem look both smaller and more consequential. By late 2025, the company said its platform had managed more than $7 billion in bookings for thousands of merchants. The $70 million funding round and acquisitions of ACME Ticketing and Connect&Go extended the remit into memberships, donations, RFID systems and onsite visitor tools. Museums and large attractions joined the kayak companies and cooking classes.

The expansion also raises a classic platform question: how much complexity can software absorb before the software becomes the complexity? Bruening's earlier work offers an answer, or at least a discipline. Begin with the oddities of the real transaction. Keep context. Build around the operator's day. Let standards connect a fragmented market, but do not confuse standardization with sameness.

Connectivity has therefore become part of his public work. Hundreds of reservation systems must speak with distributors, and the same activity can appear across many sales channels. Bruening has joined industry forums on common standards and worked with Google's team when Reserve with Google expanded into tours and activities. The appeal is obvious: an operator should not need a bespoke technical negotiation every time a new route to customers appears. The risk is equally obvious: a common pipe is useful only if it carries the peculiar information the experience requires.

This is why his career from security to travel is less of a leap than it first appears. Data-loss prevention asked software to recognize sensitive patterns without drowning people in false alarms. Experience software asks it to recognize operational patterns without flattening the experience. Both require rules, judgment and respect for exceptions. One protects what must not escape. The other organizes where people hope to.

Bruening has spent years making the machinery quieter so that a guest can hear the guide, the paddle entering the water or the peculiar silence of a museum gallery. Precision is useful here, but only in service of something gloriously imprecise: a good day out.