Although obvious now, who FareHarbor would be for was less clear at the beginning. We started off more boat-focused, and had a lot of conversations around things like how schedules should be structured and the kinds of business relationships companies in the activity industry have with each other.

Switching to FareHarbor was the first time many of our customers used any kind of software for their reservation management. It’s harder to move someone from a binder of bookings to a computer than it might seem. In the anything-goes data model of paper, you can just scribble in the margins if you want to give a deal or adjust your schedule. Databases are a lot less forgiving.

For companies who were using software, most of what we were replacing was pretty archaic in terms of UI, though the systems were developed by teams with decades of industry experience.

The first version came together remarkably quickly, going live for North Shore Catamaran and taking our first online booking about three months after we started. Zach, Matt, and I had worked together on a few other projects and were very effective at Django and spinning up new apps. Decisions we made then about data structures are still core to how FareHarbor works today.

We were so excited about launching that we rigged up a computer to play a five second clip of the Golden Gate Bridge's foghorn in our office whenever an online booking came in. This was an idea that our open-plan office mates were remarkably tolerant of. (And it pretty quickly became too much. Years later we would have monitoring set up to warn if the number of online bookings fell below a certain threshold per minute.)

One of the best things we did was talk to real customers from the start. The b2b sales process makes it hard to avoid, really. My previous startup projects involved a lot of sitting at a whiteboard and dreaming up new features, so it was refreshing to have a potential customer say “I’d use your software if it had this feature, and here’s how I want it to work.”

These conversations shaped the way I saw our users. Many of them didn’t get into what they do to run a business. They had a passion – for sailing, for an extreme sport, for showing people their city – and discovered it was something they could do every day and make money from.

Those in-person experiences gave me empathy for our users in a way that I think is often undervalued in business software.

The day we spent in the reservation booth for a parasail company in Hawaii is a bit of a company folk tale. Four of us, plus the usual staff, all crammed into a room with a ringing phone and a line of eager tourists waiting to get checked in. I had a lot of the fundamentals right, but anything in our UI that made the staff wait or scroll was getting in the way. If you’ve ever watched someone try to use software you made you know how stressful it can be – this turned that up to 11. (The reports of my contributions beyond taking notes are a bit overblown, I only answered the phone once.)

It was clearer than ever that FareHarbor couldn’t be the reason someone had to say, “Sorry, I know you’re upset but my system is being slow today.”

I ended up redesigning the main booking form for authenticated users after that, to load as much as we could as early as possible and make it fit on one screen. It’s a solution that wouldn’t have gotten attention on the “inspiration” sites for designers that were popular at the time, but it ended up being perfect for the use case.

There’s a line in Citizen Kane where Kane says, “I don’t know how to run a newspaper, Mr. Thatcher, I just try everything I can think of.” It stuck with me when I first heard it because I think it captures so well what it’s like to do design for a startup.

We didn’t set out knowing how to design a reservation system, and some parts of the industry felt super overwhelming. Have you ever tried to figure out how tax should be allocated in an affiliate reverse-billing situation? The answer is “everyone does it differently.”

So I’d do a design and we'd build something, then we’d see how it worked and what feedback we got. Sometimes we’d get it pretty much right on the first try – other times, we’d be tinkering to get it just right for years.

Here’s just one example of that: the UI for choosing what to add when booking online, which is maybe one of the most important functions of the whole app. (By the way, these screenshots are embarrassingly old and not even high-resolution, but they do a good job of illustrating how the design process goes.)

FareHarbor was distributed before it was cool. A lot of my photos of the FH crew over the years are a grid of faces on a screen. For the first year or so it was just the five of us, and then we started adding to the team. Now, over a thousand incredible people have worked at FareHarbor in offices all over the world.

Things started getting weird when I no longer knew everyone’s name. Then, I’d visit one of our offices and colleagues would know me from video calls but I wouldn’t know them. Then it got really wild when I visited our Amsterdam office and overheard conversations in other languages, with terms that Nikki and I had made up like Customer Types and Price Sheets sprinkled in.

#0a6ece

Most people interact with the white-labeled booking process, so despite a cameo in an episode of The Real Housewives of Salt Lake City, the FareHarbor name isn’t generally known. We didn’t start a formal marketing design team until about five years in, so I did most of our early branding and design work, with a little outside help.

I also got to shape the language around the brand. Notably, when we were designing the booking overlay that would go on companies’ websites, some of our team would mix up “lightbox” and “iframe.” I ran with it and started calling it the Lightframe, which is now a US trademark.

The best part was what people did with it. You know you’re onto something when folks make fan art about your reservation management and accounting system.