The Beast Test: How a Lisp Programmer Who Hated C++ Built a Startup, Almost Lost Everything, and Sold to Yahoo

The Startup Years

I first heard the word “beast” in Julian’s living room.

It was the fall of 1995, and I had just made up my mind to start my own company. To be precise, I made that decision because I had no other choice. I was a Lisp programmer, and back then you could count the number of companies using Lisp on one hand. The software consultancy I’d been working for was clearly failing, and if I wanted to keep earning a living by writing code, I had two options: learn C++ or become my own boss. My hatred for C++ was stronger than my fear of poverty, so I chose the latter.

Julian was a friend from graduate school. He’d been a CEO, a corporate lawyer, and later became an angel investor. He listened to my plan—build a tool that would let small merchants open online stores—and without much hesitation, he wrote a check for ten thousand dollars. But what he gave us was more than money. He said, “You have to get the people right before you can get the product right.” Then he asked, “What kind of people are you planning to hire?”

Back then, my idea of hiring was still at the level of “as long as they can code.” Julian shook his head and laid down a standard that would later become our creed: “The people you hire must be beasts.”

He explained what “beast” meant: someone who takes their work a little too seriously, someone who crosses the line from “professional” into “obsessed.” A salesperson who refuses to take “no” for an answer. A programmer who’d rather stay up until 4 a.m. than let a bug go to bed. A PR person who cold‑calls New York Times reporters on their cell phones. A designer who feels physical pain when a layout is off by two millimeters.

I was skeptical at first. It sounded like an impossibly high bar. But every single person we later hired proved Julian right.

Our first head of sales was a woman in her early thirties, with short hair, who spoke fast and laughed like she was sharpening a knife. The first time I sat next to her while she cold‑called a prospect, I actually felt sorry for the person on the other end of the line. You could feel them squirming, searching for excuses to hang up, but she always had one more counterpunch. After she hung up, she turned to me and said, “That guy signs on Monday.” I checked the calendar; it was Wednesday. He signed on Monday.

I asked her how she did it. She said, “I just made him understand that if he doesn’t buy from us, he’ll regret it for the rest of his life. I’m helping him.”

Later I started calling her “the steamroller.” Every time she went out to see a client, she came back dragging a long trail of flattened rejections behind her.

Our core team had a programmer we’ll call M. M never wrote comments, not because he was lazy, but because he believed comments go out of date while code never lies. His process was to spend two days running the entire architecture through his head, then sit down and type continuously for twenty hours, fueled only by Coke and pizza. One time we found an incredibly obscure memory leak that nobody in the company could track down. M locked himself in his office. When he came out the next morning, his eyes were bloodshot, and he was holding a scrap of paper with a single line of assembly on it. “It’s at the bottom,” he said. “Fixed.” I later noticed his whiteboard was covered in dense diagrams of memory addresses, like a madman’s graffiti.

Then there was our graphic designer, a woman who’d studied architecture. When she came in for her interview and saw our website prototype, she didn’t say a word. She just pulled out her notebook, sketched three-page layouts, and handed them to me. “Your current design makes me want to throw up.” We hired her on the spot. After that, every time she did a layout, she would tweak button radii, line heights, and spacing until they felt exactly right. Once I walked past her screen and saw her moving an icon by two pixels. She said those two pixels made the whole page “look like it had a neck problem.” I told her users would never notice. She glared at me. “I notice.”

Later I realized the “beast test” is actually easy to apply. Just picture the person in your mind and ask yourself: “Is so‑and‑so a beast?” If the question makes you laugh, they’re not.

In big companies you don’t need—and probably don’t want—employees like that. But in a startup, you can’t survive without them.

Besides the “beast” test, we had three extra filters for programmers: Is this person genuinely smart? Can they actually ship? And, can we stand working with them every day?

The funny thing about the third test is that it didn’t filter out many truly smart people. If someone was smart enough, we could tolerate any level of nerdiness. What we couldn’t tolerate were arrogant, pretentious people who pretended to know everything. But those types usually weren’t genuinely smart anyway, so the third test was mostly just a variation of the first.

I learned this lesson from Robert. Robert was one of the most unpretentious people I’ve ever met, and also one of the highest‑IQ people I’ve ever known. In meetings, if he didn’t understand something, he’d say, “I don’t know,” without hesitation. If someone disagreed with him, he’d say, “Maybe you’re right.” He never felt the need to prove himself.

Later I figured out a rule: you can tell if someone is truly smart by how easily they can say “I don’t know.” The ones who try hardest to fake it usually have the least to offer.

Of course, this rule doesn’t always work, because environment shapes behavior. MIT’s computer science department, for example, seems to have a tradition of performing as rude know‑it‑alls, apparently inherited from Marvin Minsky, much like the stereotypical airline pilot mannerisms came from Chuck Yeager. Even genuinely smart people can pick up that act there, so you have to cut them some slack.

We were renting a three‑story wooden house near Harvard Square. It used to be a residence; when we moved in, the bathroom still had a claw‑foot bathtub. Several cracks in the walls were stuffed with aluminum foil. I guessed the previous occupant must have been extremely neurotic, using foil as protection against cosmic rays.

The first time a VP from a big company visited, he looked at our office and went silent for about five seconds. I thought, “We’re done. He thinks we’re a bunch of garage hobbyists.” But later I realized that shabby place actually helped us. It made us feel, deep down, that we were outsiders circling the edges, not some established force. And that’s exactly the mindset you need: you don’t need to feel respectable; you need to feel sharp.

And honestly, a residential building is better for coding than an office tower. Have you ever noticed that you write code more efficiently at home than at work? So why not make the office feel like home?

We stayed in that house for over two years. The cheap rent was one thing, but the location was even better—three minutes’ walk to Harvard Square, surrounded by restaurants, cafés, and bookstores. Every night after six, when the office phone went quiet, we’d head to a nearby Thai place or pizzeria, eating and talking about the day’s bugs, customer complaints, and competitor moves. Often an idea would spark mid‑conversation; we’d push our plates aside and run back upstairs to code.

That period is what I miss most from my startup years. After we moved to a proper office building, that rhythm of “walk back after dinner and keep going” never returned.

How I ended up starting a company is, in retrospect, kind of absurd.

I was, at my core, the last person who wanted to be an entrepreneur. I wanted to stay in the pure, intellectually challenging world of software, not deal with customers, sales, invoices, and all that mess. When people don’t want to do something, they develop a kind of “protective incompetence.” The mathematician Paul Erdős was the ultimate example: he acted as if he couldn’t even cut a grapefruit in half, let alone buy one at a store, so others had to handle all his mundane affairs, leaving him free to do math.

I wasn’t as extreme as Erdős, but the logic was the same. I believed “business” was some deep, mystical discipline that required years of systematic study, like medicine. So before I started my company, I actually asked several people who supposedly knew this arcane art if they’d be our president. They all said no. So I had to do it myself.

And then I discovered that business isn’t all that deep. At least not at the startup stage. You don’t need to understand tax law or derivatives pricing. You just need to figure out one thing: how to get people to pay for your product.

The only reason I’d seen business as a mystery was that I was afraid of it. Once I shed that “protective incompetence,” I found business was neither as hard nor as boring as I’d feared. It’s essentially common sense—the kind of common sense people understood long before business schools existed.

To test this idea, I later went through the Forbes 400 list and put an X next to every person with an MBA. The result: only five MBAs in the top fifty. After Warren Buffett, you don’t hit another MBA until number twenty‑two, Phil Knight, CEO of Nike. The list is dominated by technical founders: Gates, Jobs, Ellison, Dell, Bezos, Moore. The rulers of the tech business world come from technology, not business.

So if you ask me whether spending two years on an MBA or learning to code is better for starting a startup, the empirical evidence is clear: code.

We made plenty of mistakes when we started, but one thing we got right from day one: ship the first version fast.

It was spring 1996. Our first version was embarrassingly crude; you could register a store, upload product photos, process credit cards, but the interface looked like a BBS from the early nineties. We put it in front of a few friends, let them try it, and they cursed at it while we took notes.

That was our development method. We didn’t write a hundred‑page spec and hire a team to build to it. We built something that worked, threw it at real users, and listened to what they hated.

During the dot‑com bubble, many companies did the opposite. They called it the “big bang” strategy: spend a year and two million dollars hiring a team to build behind closed doors, and end up with something nobody wanted. Those companies were usually run by business types who treated software development like bridge‑building. They believed you need perfect blueprints before you start.

As a Lisp programmer, I believed in the rapid‑prototyping tradition. I’m not going to claim that’s the only right way to write all software, but it’s absolutely the right way for startups. Because your initial plan is guaranteed to be wrong in some ways, and your only job is to find out where, as early as possible.

Our first target customers were web design consultants. We figured these people built websites for clients all day, so they’d definitely need an e‑commerce tool. They hated us, because our software was too easy to use and we offered hosting, which meant their clients could bypass them entirely. We were essentially training our own competitors.

After that failure, we turned to catalog mail‑order companies. In 1996, online sales should have been a natural extension for them. But the middle managers we talked to saw the internet as a hassle, not an opportunity. They thought it meant more work, more uncertainty, and a threat to their existing offline relationships.

We did sign a few adventurous ones, including Frederick’s of Hollywood, a lingerie catalog company. They became an important early client and gave us valuable experience, like how to handle traffic spikes when a promotional email went out and multiplied our traffic tenfold in hours.

But the group that truly kept us afloat was small independent merchants we hadn’t expected at all. Many of them had never owned a store before; the internet gave them a nearly zero‑cost starting point. Some had brick‑and‑mortar shops looking to expand online; others sold exclusively on the web. These people had zero tolerance for complexity. They didn’t need powerful features; they needed dead‑simple usability.

So we pivoted. We stopped worrying about what consultants and catalog companies wanted and poured all our energy into making our software easier to use.

I learned an extremely valuable lesson: making technology easy to use is always worth the effort. Programmers are so used to computers they have no idea how terrifying software looks to normal people. Stephen Hawking’s editor once told him that every equation he added would halve his book sales. Reducing the barrier to entry means climbing that curve in the opposite direction. A 10% improvement in usability doesn’t increase sales by 10%. It might double them.

How did we figure out what customers wanted? We went to trade shows. Not to acquire customers—the cost per lead there was terrible—but to observe. We didn’t do canned demos. We walked up to our booth, asked strangers to build a live store on the spot, sat beside them, watched where they clicked, where they got stuck, where they frowned, and then asked: “What would you have wanted that step to look like?”

Once, a middle‑aged woman kept clicking wrong while setting up product categories. I was about to explain, but she suddenly looked up and said, “Could you let me drag and drop categories like I’m organizing my closet?” We went back and spent two weeks building drag‑and‑drop. It became one of our most popular features.

When we had only seventy users, we were already hearing gold from them. Those seventy people found us on their own; they were smart, curious, early adopters. And they’d paid. A paying user’s feedback is worth more than a hundred free trial users combined.

That year, we changed the product almost every month: architecture, interface, workflows. Sometimes we’d release a change and an old user would write in angry: “I was used to the old way, why’d you change it?” So we’d change it back. Going back and forth with users might sound inefficient, but by the end of that year, we understood online commerce better than any competitor.

Our competitors were busy burning cash on ads. They called it “getting big fast.” The logic was: grab the market first, lock in all the users, and competitors have no way in. But I don’t think first‑mover advantage is that overwhelming in most industries.

Google is the perfect counterexample. When Google showed up in 1998, the search engine market already looked mature: Yahoo, Lycos, Excite, Infoseek, Altavista, Inktomi, all with millions in brand spending. Showing up in 1998, by conventional wisdom, was too late.

But Google’s founders knew one thing: in search, brand is almost worthless. Just build a better product, and users will find their way to you, gradually. Google never ran ads; they were like drug dealers selling the stuff but never touching it themselves. If those competitors had spent their millions on improving their software instead of branding, things would have turned out differently.

We did the same. From 1996 to 1998, we spent almost nothing on advertising. Growth came entirely through word of mouth. Slow, but steady. And the slowness gave us plenty of time to watch users and adjust direction. By the end of 1998, we’d left all our competitors behind, not by raising more money, but by understanding the business better.

One time a user called to complain that an order he’d placed last night had disappeared. I was about to blame a system delay when I realized it was a genuine bug: the order had gone into the database but wasn’t linked to his account. Sweat broke out. I apologized over the phone while frantically writing a script to fix the data, then told him, “It’s fixed now, refresh the page.” He paused for two seconds and said, “Were you just fixing code?”

I said, “Yeah.”

He said, “Is everyone at your company like that?”

I said, “Pretty much.”

He became one of our most loyal evangelists. He referred at least twenty clients to us. That’s the advantage of a small company: your customer support is your CTO, your salesperson is your architect, and there’s no layer between you and your users. You can’t buy that kind of directness in a big company, no matter how much you spend.

In the fall of 1998, someone wanted to buy us.

Everything was going smoothly. The buyer was a decent‑sized internet company, and the price was good. We founders were already daydreaming about how to split the money and where to vacation. To smooth the acquisition process, we spent our cash pretty aggressively, figuring a big check was coming soon, so why bother saving?

Then disaster struck.

During contract review, our lawyer discovered that one of our team members—call him D—had signed an agreement years earlier while in graduate school with a large corporation. That agreement said any intellectual property D generated during his studies belonged to the corporation. The problem was that D had later joined our project using code he’d written in his spare time, and a core piece of our software architecture was something D had first thought about during his graduate years.

Legally, that meant a substantial portion of our entire product might belong to someone else.

The acquirer immediately put the deal on hold. “Come back when you’ve cleared the title,” they said.

We were stunned. The company account was nearly empty; we’d assumed the acquisition would close any day, and now we were running on fumes. We had to raise more money, but with that giant cloud of intellectual property uncertainty hanging over us, investors wouldn’t touch us. Their most frequent question was: “If that corporation sues you, can you survive?” We had no answer.

Our angel investors—and by then I’d learned that “angel” is only a metaphor—saw us trapped and started playing hardball. They offered additional funding, but with draconian terms: valuation near zero, and they’d take majority control of the board. We founders, huddled and debated all night. In the end, we said no. We told the investors: fine, we’ll give you a quick training session on how to manage the servers yourselves, and then we’re out.

This was pure bluff. We had no money to leave; our servers were collocated, and we were two months behind on rent. But we actually drafted resignation letters, printed them, and left them on the table. The investors, probably not expecting us to push back that hard, hesitated for a few days and finally caved. We closed a round at a reasonable valuation and kept the lights on.

Meanwhile, we exhausted every channel to contact that large corporation and get a formal statement that they didn’t own our software. The process was agonizingly slow. They were a big company with a legal department that moved at its own pace, completely oblivious to our burning platform. We pulled every connection we had, even managed to reach a VP’s personal email through a friend of a friend, and sent a desperate letter.

Six weeks later, they finally sent the clearance letter. I read those pages three times, then collapsed in my chair laughing for a long time. The acquirer reopened negotiations once they heard the news, but by then Yahoo had also expressed interest. After two months of back‑and‑forth, Yahoo acquired us at a far higher price than the original offer.

Happy ending. But that experience probably shaved a few years off my life.

Even now, thinking about it gives me chills. So if you’re starting a company, before you cross the finish line—actually, from day one—you must clear the intellectual property history of every founder. Any early internship contract, scholarship agreement, or even a university’s internal policy could become a bomb later.

In my first months at Yahoo, my biggest realization was: big companies really are as slow as they say.

But I also discovered something that astonished me. Yahoo’s co‑founder, David Filo, had the official title “Chief Yahoo,” but his unofficial nickname was “Cheap Yahoo.” Shortly after we joined, we got an email from Filo. He’d been reviewing our server directory structure and noticed we were storing a lot of data on expensive RAID disks. His email was two lines: “Do we really need to store all this data on such costly drives? Can we switch to cheaper ones?”

I was stunned. Yahoo’s market cap was already in the billions, and Filo was worrying about a few gigabytes of disk space. Later I mentioned this to others, and everyone said that was classic Filo: he flew economy, stayed in budget hotels, and kept a folding chair from the supermarket in his office.

That made me rethink frugality. When you raise a few million from VCs, you can easily feel rich. But you have to remember: that money isn’t revenue. It’s the investors’ principal, parked with you on the bet that you’ll generate ten or a hundred times the return. Until you do, you’re still broke.

So we kept our graduate‑student style. Desks from flea markets, chairs discarded by a nearby university with missing armrests. When the printer ran out of ink, we refilled it ourselves, getting our hands black. We took the subway to client meetings; if they sent a car, we felt uncomfortable.

That ethos shaped our culture. Once a prospect visited our office, looked around, and hesitated: “Your workspace…” I cut in: “Pretty shabby, right? But we save money, so we live longer. And if we live longer, we can support your product longer.” He was convinced and signed on the spot.

We made plenty of mistakes in fundraising too. One lesson I’d emphasize: don’t wait until your last round is almost burned before starting the next one. VCs are much slower than you think. They can drag on for three months, six months, endless partner meetings and due diligence. If you’re negotiating while watching your bank balance trickle to zero, you have zero leverage.

We talked to many VCs, but most of our rounds ultimately came from angels. The simple reason: we were afraid VCs would force a “newscaster” on us.

“Newscaster” was our private nickname for a certain type. These were men in their forties or fifties, suits, hair gelled, deep confident voices, every sentence sounding like a press release. Ask them a specific technical question, and they’d bounce back a sentence full of MBA jargon. Their skill wasn’t understanding the business; it was convincing investors they did.

During the bubble, many VCs required portfolio companies to parachute in one of these people as CEO, with the rationale: “You need mature, experienced business leadership.” The classic case was Apple. Steve Jobs was kicked out of the company he founded by exactly that type of mature experienced business leader, who then nearly destroyed it.

Google later broke that unwritten rule. When they went public, they refused to speak Wall Street’s language. Wall Street initially didn’t buy it, then the stock shot up, and the financiers beat their chests in regret. When money’s on the line, Wall Street learns new languages faster than anyone.

So we kept the newscasters out. Our core strategy was winning on technical understanding, and all important decisions were technical. A non‑coding outsider in the CEO seat would only slow us down. The results proved us right.

For those three years, my life had almost only one dimension.

Every day was code, customers, meetings, servers. Sleep at two or three in the morning, wake at eight or nine. Weekends were no different. My only recreation was running; in the evenings, I’d step out of the office, run five kilometers along the Charles River, not for pleasure but because otherwise my body would give out. Come back, shower, sit in front of the computer again.

Before bed, maybe fifteen minutes of reading. Sometimes I’d fall asleep mid‑page, the book dropping on my chest and jolting me awake.

Every couple of weeks, I’d carve out a few hours to browse a used bookstore or have dinner at a friend’s house. That was about the extent of my contact with the outside world. In three years, I had one girlfriend for about two months; I just didn’t have the energy to sustain a normal relationship. I visited my parents twice, each time for less than three days before rushing back.

If you ask me whether I was happy during that time, the answer has layers.

I was happy when I was with my colleagues, because they were my best friends; we’d stay up all night debating problems, solving hard things together, cursing competitors. Those moments had a deeply intimate camaraderie. But that was maybe 10% of the total time.

The remaining 90%—the best I can say is that some things are more amusing in retrospect than they were in the moment. Like the time the power went out in Cambridge for six hours, and we programmers, bored out of our minds, tried to run a gasoline generator inside the office. We dragged it from the basement up to the second floor, ran an exhaust pipe out the window, and nearly asphyxiated the entire building. The landlord called to yell at us; we apologized while laughing. That kind of stupidity: I’d never do it again.

But I don’t think the amount of crap you have to deal with in a startup is greater than in an ordinary job. It might even be less. The difference is it’s compressed into a few years. The setbacks, anxiety, and despair you encounter in one week might be a normal year’s worth. But the ecstatic “we nailed it” that you get within a week is also something a normal person wouldn’t experience in a year.

So what a startup really buys you is time. You’re trading four years of hell for forty years of freedom. If you’re the type who’d rather endure four years of hell than spend forty years accumulating slowly in mediocrity, then it’s worth it.

Finally, many people ask me: “How do I know if I’m cut out for it?”

My answer: more people are cut out for it than realize it.

The first signal: when you look at existing technology, you can’t help thinking, “Don’t these people realize they should be doing x, y, and z?” If that thought keeps coming back, you already have the most fundamental thing. You’re not following a trend; you genuinely see a gap.

The second signal: you’re afraid of “business,” but that fear comes from never having tried it, not from having tried and failed. I’ve known so many brilliant programmers who are ten times smarter than the average startup founder but held back because they “don’t understand business.” What they don’t realize is that the technical founders on the Forbes list didn’t understand it either, at first.

The third signal, the most honest one: do you really want to solve your money problem once and for all? If your inner voice says “I’d rather take it slow, get annual raises, live comfortably,” then startups aren’t for you. But if the phrase “forty years of salary” makes you clench your chest, then you should try.

On age, I think the sweet spot is 23 to 38. Before 23, it’s hard for people to take you seriously; customers worry you’ll flake out, VCs treat you as a fundraising mascot. And you need to have worked at an established company first, even if it’s a terrible one, to see firsthand how business works. The worst year of my adult life was at a software company. They made every mistake imaginable: endless meetings, shared code ownership, salespeople running the company, overpriced products, bloated codebases, QA doing all the bug‑finding, releases once a year, developers three floors away from users.

But precisely because that year was so miserable, I learned all the negative lessons. They’re more valuable than positive ones; replicating others’ success is hard, but avoiding their mistakes is comparatively easy.

The 38 upper limit is flexible. I picked it because I think beyond that age, you might not have the physical and mental stamina for the nonstop grind. And by then many people have families and mortgages, making failure much more expensive. Of course there are exceptions; if you think you can do it, go ahead.

Looking back, what I’m most grateful for isn’t the money we eventually made. It’s that at the youngest, most energetic time of my life, I got to work with the best people on something genuinely hard.

That feeling stays with you forever.

If you’re reading this and thinking, “I don’t care about your age cutoffs, I’m starting a company tomorrow,” then you’re probably the kind of person who breaks the rules. Go for it.

It’s not as mysterious as it seems. You don’t need a world‑changing “genius idea.” You just need to find an area where the status quo is embarrassingly bad, build a replacement that sucks a little less, let your first users fall in love with you, listen to them, spend your money where it matters, and hold on through the nights you can’t see the light.

If even I—someone who just wanted to hide in the world of code, backed into this path by sheer necessity, a Lisp programmer who hated C++ more than poverty—if even I could make it, then what’s your excuse?