Research startup

This post is a way to finally write down something I wish I’d found before starting.

We planned to bootstrap at first. But things changed, VCs started reaching out. Said no to most offers, some said no to us, but one VC really “got it.” and we partnered up with them. I still don’t regret that call.

VC Preggo

What do I mean with “got it”? VCs usually invest in a standard startups formula, let’s call them engineering companies.

In engineering companies, product dev metrics can be more or less clear: pick stack, build MVP, engineering has more or less predictable timelines, iterate on user feedback, fix bugs, watch churn, etc.

It doesn’t mean it’s easy by no means, but the biggest challenge is always finding GTM and PMF.

With that in mind, A lot of VCs have expectations. They’ll push you to market hard, find early users ASAP, keep retention high, and so on. Face delays, they’ll step in—maybe in good faith to help, maybe not if you picked the wrong VCs.

But this doesn’t translate well to research. Research and startups are an oxymoron, or used to be until outliers proved exceptions exist.

In academia, funding is more of a fixed dilution investment. Licensing office takes equity when you ship, but the timeline is not an issue. 1 year, 7 years, the terms stay the same.

But this doesn’t align with what they would expect (again, we were very lucky to find investors whom understood what we want to do and spared no effort in helping us when we were stuck). They give you money to grow fast, speed up the timeline. The problem is, more cash doesn’t always mean faster research. You might try 50 things and fail on all, or nail it in 1-2 tries. This brings up intuition which I’ll talk about later.

If you want to be a research startup, you can’t just work with a traditional B2B VC used to growing traditional SaaS companies. If you tell them “our research hasn’t produced the results we need to productionize yet” they’ll make you regret ever taking their money.

So what do you do? Well, I don’t know what everyone does, but personally, after raising, I didn’t give myself a salary. I worked with my savings as if I was still bootstrapped and grinded for the first 6 months. My goal was to not be put in a situation where I used someone’s money to scale something that wasn’t working, and then lose my independence and have to lower my head and do what I’m told. I’m goofy but I’m straight and narrow on how I run something, and I wanna do it right.

This meant my bets were very constrained. I didn’t want to jizz 100k/mo on experiments. I would often jot notes on tens of papers I read, print out the ones I liked, stick them to the wall facing my bed along with long decision trees. Sometimes, just sometimes, I would throw all of my reasoning out and bet a lot of money on an experiment.

This paid off (miraculously), but different people, different problems, YMMV.

It’s hard to define progress metrics for research labs/startups like the ones we talked about for engineering orgs. Nobody knows if the technical direction you take will be meaningful or if you’ll hit a wall you can’t climb and have to go back to the whiteboard.

So rather than metrics, your goal as a founder-researcher should be to have the energy of a strong PI. You need to give the overarching direction and where everyone needs to be, and have the experience to know what directions might be worth chasing vs what needs to be wound down. This is why you hear “it’s all vibes and intuition.” Trying to have everyone try everything is how you end up filing your B-119 form.

You need to give/collect the ideas you want your researchers to pursue but don’t have time to check yourself. They come back with results and reports, then you decide based on your intuition and their work if it’s still worth investigating or not. This needs a certain type of person though, and some things should raise flags for you.

For example, if you task someone to research something and in the first few hours they come back like “how do we do this?” - you probably fucked up your hiring. Same if you task a researcher and they say it didn’t work, you probably don’t want to ask why and get “I’m not entirely sure” as a response.

The more you do this, the better you understand “did my researcher look into what I wanted?” and “how much do I trust they really tried everything?”

You want strong independent researchers/engineers. Not genies where if you don’t give super specific instructions they fuck off in narnia. If you say “I want trajectory observability stored in a reasonably searchable way with whatever integrates well into what we currently have” you want someone who says “okay cool I’ll let you know when It’s done.” and you get what you expected or close enough, not something completely unhinged from what you have like prompting an LLM without context.

So TLDR, your job is to be the research compass while sniffing out the right paths and keeping your team on them. You have to trust your intuition a lot but also believe in your researchers, pattern-match good vs bad research fits, and not be afraid to pivot quickly when you hit walls. You’re someone who is continuously solving the puzzle at hand by putting the pieces together and where they fit, except each wrong move risks triggering a Lévy flight in your problem space.

Hiring

How do i figure out who i want to work with? This is just how I do things so you will have to find out your preferred way, but I don’t do leetcode interviews. I usually go off referrals or people I find myself. My questions are more to see what they understand, and if they can infer their way to a solid guess on things they don’t know from first principles and their understanding of adjacent concepts

And of course vibes. If I see the potential in someone and I vibe with them, I’ll take a bet on them. But like with research, if it doesn’t work out, it doesn’t work out. I iterate on that shit fast.

Working with Constraints

Parkinson’s Law states that “work expands to fill the time available for its completion”. This principle may extend, ironically enough, to funding in startups. Excessive funding coupled with a slightly fuzzy vision on what needs to be done exactly can lead to inefficiencies, such as pre-training LLMs for problems that could be solved much more efficiently and potentially better through other means.

The putative model we keep seeing in new startups emerging with large funding rounds (10, 20, $30M), epitomized by frontier labs, stems from a conflation of the essence of what frontier labs had with what other startups have. The former is an outlier, even though it may not appear as such on the surface at T0. This is something most VCs probably do not see and likely cannot see. This result is a landscape where everyone believes they need these amounts to tackle problems that require substantial research.

I haven’t fully fleshed out the idea of working with constraints, but we can just do it live.

First and the most obvious would be research independence as I mentioned before, maintaining the ability to pursue high-risk and potentially great directions that wouldn’t align with typical VC timelines if you took too much money, allowing you more creative freedom and less tri-weekly check-ups from your investors.

Forced creativity. I found that the resource constraints can lead to solutions that might not have been pursued otherwise. I started exploring other approaches, which is how I ended up training a multimodal specifically for navigation trajectories (shoutouts to my professor and co worker here). I think I could’ve definitely gone the RL path if I felt that I had more money to spend, just hire a cracked RL researcher and work with them on this for the next 4-6 months - which could’ve actually worked for all I know, but now I have a better solution.

The astute reader might ask “but Lauren, how did you get the data needed for pre-training?” and the answer to that would be “that’s left as an exercise for the reader :^)” which is another point to creative solutions

The point of this is that as impressive as those Series A-D rounds may seem, companies like Adept serve as a cautionary tale. Despite making amazing progress and showing the potential to actually solve the problem they were tackling, they ultimately went under against their will due to external factors from investors, dilution, loss of control, and in other similar startup cases, failure to communicate and report progress to investors honestly.

Your goal should be to focus on small successful experiments and build on them, then release bite-sized product releases that are solid, before returning to research and improving further.

It’s easy for ambitious people to “play CEO/CTO”, acting as if they’re already running a wildly successful version of the company they’re building. Moving up to a management layer and relying on a war chest to plow ahead without keeping themselves on task and doing work that’s really meaningful. For the CEO of a research startup in particular, the value is in what you know about your problem nobody else does, and your deeply honed intuition about what you’ve tried, what you’ll try next, and what you’ll do with all those FLOPs when you’ve earned the dollars to spend them.

Okay that’s all.

Huge thanks to my sister for proof-reading and rephrasing some of my more awkward sentences.