CS Alum Dave Baggett on Computing, Game Development and Building Startups

Dave Baggett (B.S. '92, computer science; B.A. '92, linguistics) has spent more than three decades working at the intersection of software, entertainment and security. From helping create the original “Crash Bandicoot” to co-founding ITA Software and later leading Inky, Baggett’s career spans several eras of technology development. Now overseeing security products at Kaseya, he continues to focus on how artificial intelligence can support operational tasks.

In a Q&A, Baggett discussed his early interest in computing, the circumstances that led him into game development and what he learned while growing companies in competitive markets.

What first interested you in computer science, and how did your time at UMD shape your direction early on?

I got interested in computing when I was about seven years old. This was the mid-70s, when personal computers weren’t common. My father, an electrical engineer, built a Heathkit computer from parts. It took about six months, but we ended up with a 64-kilobyte Z80 machine that was ahead of its time from a computing standpoint.

I became obsessed with typing in programs from magazines and understanding how programming worked. In high school, I worked for Trusted Information Systems in Glenwood, Maryland, an early computer security company. By the time I applied to college, it was pretty clear I would major in computer science. UMD was a great fit for me, and I got a world-class education. I later added linguistics as a major and combined the two when I went to the AI Lab at MIT to do computational linguistics.

How did you enter game development and end up working on “Crash Bandicoot”?

Complete happenstance. I had always written games for fun, but never anything commercially viable. The first student I met when I joined the Ph.D. program at MIT was Andy Gavin, who, along with Jason Rubin, had been making games since middle school. They had just released “Rings of Power” for the Sega Genesis.

We became close friends, and eventually Andy and Jason got a deal with Universal Interactive to make a game with a “triple-A” (top tier game) budget. I decided to leave MIT with a master’s and become their first developer employee. We didn’t know it was going to be Crash. We internally called it “Willy the Wombat.” We wanted a character-based action game that brought the tight gameplay of Mario and “Donkey Kong Country” into 3D.

We worked on it for about two and a half years. After we had a first playable version, Sony approached Universal and wanted to publish it as a pack-in for the PlayStation. That’s how it became Crash Bandicoot.

How did building a major game franchise shape your understanding of large-scale software development?

People think games are simple because they feel natural to play, but that hides the complexity. Even basic physics is of course simulated. Games then were simpler than they are now, but still complicated and constrained by hardware. We often wrote handwritten assembly code. Modern triple-A games are among the most complex software systems, with hundreds of people working on them.

On the first Crash, Andy and I did almost everything ourselves. Tasks that are now specialized roles were just items we had to figure out. Camera control was one example. Neither our approach nor the one in Mario 64 was perfect, and it took years for the industry to refine it.

The skills transferred well to other areas. At ITA Software, we wrote millions of lines of code for flight search. The domain was different, but the techniques were similar.

What made you leave game development and pursue other projects?

Two things. One was the opportunity at ITA. My MIT office mate, Carl de Marcken, had co-founded the company, and when I saw the prototype, it was clear it would change how people plan travel. Travel is a large part of the economy, and it seemed like a strong opportunity.

The other reason was the workload. On Crash, we worked seven days a week, usually from 10 a.m. to 2 a.m. After years of that, it felt unsustainable. Moving into ITA offered both opportunity and a more reasonable pace.

What companies have you helped develop?

I’ve been involved in three startups. Naughty Dog was the first, which was later sold to Sony. ITA was the second, and Google acquired it in 2011. Most recently, we sold Inky, an email security company, to Kaseya. At Inky we primarily sold our service to managed service providers (MSPs), and Kaseya serves MSPs with a broader security suite. Now I run the whole security portfolio for them.

What were the most significant hurdles you faced while growing these companies?

The hardest problem is product-market fit, which means whether anyone will pay you for what you’ve built. Successful startups you read about like Google often got it right on the first try, but that’s actually extremely rare. Usually, you try something, fail, talk to customers and try again until you either run out of money or find something people want.

Once you have product-market fit, challenges like scaling a team or learning to sell are still hard, but more manageable. A major issue now is that big tech can quickly copy new ideas and absorb them into their platforms, which makes early traction and defensibility much harder for startups.

How did going through acquisitions shape your views on long-term planning and the life cycle of a tech company?

One question founders ask is whether you should build a startup expecting a major tech company to buy it. I don’t think that’s a reliable path now. Big tech can often copy your product more easily than acquiring you, especially if it’s tied to mobile platforms they already monopolize.

So it’s now important to get to revenue and cash-flow positive as soon as possible. Then if you never get acquired, the business still has value. Acquisitions still happen, but more often through private equity, which focuses on cash flow rather than strategic technology.

What are you focused on now, and how are those projects influenced by what you learned earlier in your career?

At Kaseya, we’re exploring how to use generative AI to automate work for MSP partners. In email security, if something gets through, a human analyst usually investigates. We’re exploring whether AI can take on parts of that work. Generative AI is powerful but expensive, so using it efficiently is an engineering challenge. It will affect many areas of software, including security tools.

Any advice for current or future student entrepreneurs?

The number one thing is to get advice from people who have done this before. The Mokhtarzada Hatchery is my favorite example. Only a small part of building a software startup is writing the software. A large part is understanding product-market fit, customer agreements and raising money. Those things are difficult to learn from books. It’s better to have someone you can ask directly.

—Story by Samuel Malede Zewdu, CS Communications