Foundering founder: the story of my startup year

This is the story of how I spent a year trying to start a startup and failed. Much like the year itself, the story is long and windy (4500 words), but it seems important to share what it was like at the time. That is, with full detail, and without the benefit of hindsight.

For my future self.

Preface: jumping in

I had always assumed I would start a company at some point. It felt like a natural step on my path from a large company (Microsoft) to a scale-up (TransferWise) to early-stage ones (Starship and Veriff). Plus, it seemed to play on my strength of thinking broadly across a business, not narrowly about one function. So the question had never been "should I", it was "when".

"When" arrived in 2020. During a holiday I had started to tinker with some annoying data problems my team was facing at Veriff. At first, I was hacking purely out of curiosity. Did a better solution exist, and could I build it? Over the next couple of months, I got the confidence to leave: I had both an idea for a product and the ability to build it. Since I'd also hit somewhat diminishing returns in my role, I decided to quit and work on my idea full-time.

Chapter 1: Crisp, the AI-training workstation

After my last workday in October 2020, I jumped in. I was going to solve a problem of computer vision teams. Namely, data labeling takes a lot of manual work, project management, and custom tools – and even so, it's a bottleneck in the development cycle. It can take weeks to update training and evaluation datasets. That's absurd. Especially because most of that time is overhead: waiting, meetings, shuffling data, etc.

I wanted to make the development loop faster. My product, called Crisp, put all three parts of the computer vision development cycle – image labeling, model training, and model analysis – into one app. The time it would take to iterate on a model was 60 seconds or about 10,000x faster than the typical one-week cycle.

Here's a demo of an early version (with Estonian voiceover).

While I did reach out to potential users, most of my time went into coding. First, making a prototype; then making it fast and reliable; then adding cool advanced features. For example, pull request #43, merged on Dec 8, 2020, introduced a text-search feature. Kind of like Google Image Search for your own images, you could type in some text, e.g. "red toy car" and based on that find relevant images from your own dataset. It was magical. (This was about a month before OpenAI's CLIP came out and made this feature look easy.)

I wish I remembered better what I was thinking back then. I think I focused on development because it was both easier and more fun than sales. But I wasn't totally oblivious to how things were going. Just one painful lesson from that period: just weeks after releasing the aforementioned text-based search feature, I killed it because it was clearly unnecessary and unused. Obviously, waste is bad in the abstract, but literally deleting weeks' worth of your work makes the concept all too specific.

Around Christmas – about two months after committing full-time – I noticed I was feeling pretty unmotivated, reluctant to start my workdays. Reflecting on that a little I found the reason: it felt like I'd made no progress.

When I tallied the numbers, this is what I got. From twelve hot leads (computer vision teams I personally knew), four had agreed to start a trial. Out of these four, only one actually used the product during the trial. Zero were willing to pay. Clearly, either the problem wasn't significant enough, or my product did not solve it.

So people did not want what I'd made. What had gone wrong? In hindsight, I can think of two reasons:

• I went after small and medium companies, where there wasn't much bureaucracy and the loop was fast enough. Maybe the problem appears only when the company and AI team are large enough.
• The magic moment was hard to reach. A potential client would have to put in days of integration work to test with real data. (And integration is difficult because there's no dominant design of ML platforms.)

But the real reason Crisp did not work was that I gave up. The "pivot or persevere" decision is subtle – you wouldn't want to fight a battle that could never be won. However, in hindsight, I think I had both enough vision and background to continue around this space – but didn't. A co-founder might have kept me going. But in January 2021, I felt alone and tired and disappointed, so I decided to throw out this idea and start from scratch.

Interlude: design

After a few weeks off I began a search for ideas, starting with ways I could reuse parts of Crisp. That was far from ideal. I was now looking for a problem to a solution, whereas Crisp had been a solution organically born out of a personal problem. But I had no better idea and wanted to make use of my unique knowledge.

This is when I ran my first design sprint. It's weird to follow a week-long format meant for teams, alone, but it was surprisingly helpful and new to me. (I've mostly worked on technical products, not UX-driven ones).

The sprint was set up around the following problem. In online stores, it's hard to discover relevant products among the thousands that are available. Netflix does discovery well, but the typical Shopify store doesn't: to find products you can use either categories, tags, or search. Some store managers do manually curate items into collections ("Spring essentials", "Basic tools for the garage", or whatever) which improves UX but takes a lot of work. I was hoping to make curation much easier – relying in part on the computer vision tools I'd developed before.

So I went through the sprint: mapped the problem, sketched solutions, faked a Google Slides prototype, and did user interviews. It really helped me move fast. The users didn't have the problem I'd imagined, but I found a different one: running campaigns took a lot of work.

I decided to not follow up with this new problem: throughout the sprint, I realized I was pretty indifferent to online store managers' problems. It looks like I was being picky, but I don't think you can succeed for years in solving a problem you don't find interesting and valuable.

Chapter 2: Karu, self-coaching for learning

I had killed the e-commerce idea because I couldn't relate to it, so I reflected on things that did come naturally to me. And I did find something. I'm more excited by effective learning than most others I know: applying deliberate practice, chewing through difficult concepts using flashcards, avoiding passive reading, etc.

Learning effectively isn't difficult – you just need to unlearn some bad methods and acquire new ones. For example, many people read nonfiction linearly from cover to cover, whereas the strategy for maximum understanding (within the same time budget) involves several passes and intentionally focusing on the salient parts of the book.

I could have started sketching a solution right there. But now I was one failed product smarter. With Crisp, I'd wasted time building an elaborate app before ever selling it to users. So this time I decided I'd write zero lines of code until I was sure the problem was real.

To find a specific problem, I started calling people, starting with my friends and their friends – predominantly millennial knowledge workers. This helped me narrow down to a specific, important type of learning: getting better at your job. We talked about career progress, learning specific skills, motivations, online courses, coaching, etc. In this initial phase, I mostly spoke to individual contributors, but also a couple of managers and corporate Learning & Development (L&D) leaders.

There was definitely a pattern: in their own opinion, most people were not learning as much as they would have wanted to. Improvement was accidental; most would have liked to take more active steps. The problem? Lack of time, at least superficially.

Digging deeper, I found the actual issue: it's unclear what to learn. Concretely: if you decided to take one hour every morning to become better at your job, what would you do with that hour? The default solutions of "read a book" or "do an online course" are high-willpower projects with no visible short-term value, which kills motivation. What's more, you beat yourself up over it: you want to be learning, but somehow give up every time you try. That feels bad – are you stupid, then, or lazy? It's easier to not take the time.

For learning to be effective, you need a curriculum: something that tells you what to learn, and in what order. But it can't be several years long like at university or even on a weekly basis (like usually in MOOCs). If you are to spend an hour every morning purposefully rewiring your brain – an exhausting activity! – you need to know exactly what to do with that hour. You need a micro-curriculum. What's more, it should be personally relevant: it's powerfully motivating to learn something at 9 am that helps you do better work at 10 am, the same day.

So, the issue is it's hard to create a curriculum that is:

• immediate: tells you concretely what to do with the next 60 minutes of learning;
• personal: relevant to your work tasks that day and that week;
• challenging: skips things you already know and keeps you right on the edge of your comfort zone;
• effective: uses learning methods that actually work.

Most other problems are downstream from that. "Taking more time for self-development" is a hard sell to your boss. But if you go with "every morning from 9 am to 10 am I will be working on my understanding of Typescript, currently focusing on type inference, and for the next 60 minutes I will be reading and summarising <this tutorial>, and making code snippets to test out ideas"... That's easy to approve.

Still respecting my zero-lines-of-code commitment, and still trying to see if the problem was imaginary, I needed to make my first sale. A good user interview doesn't look much different from a sales call, and I was able to close on some of them. About three weeks after I'd started, the first two users agreed to sign up at 100€ a month, paid from the company's L&D budget, with a 7-day free trial.

Now I needed a product. But remember: I wasn't allowed to write code. So I did things that don't scale: combining Notion, Typeform, and Google Meet I started solving the problem as best I could.

The first product was mostly coaching. In a 30-minute onboarding session, we mapped out the learning goal and potential topics to learn and scheduled 60 minutes of learning into the user's calendar for every workday morning. At the start of the hour, I would help them choose specific to-do items for that hour. For the next 50 minutes or so the learner was working on those items. In the last five minutes, we'd do a quick review and adjust the course if necessary.

This "product" was definitely not scalable, but it gave me an extremely tight feedback loop: I could make changes on the fly and see their effect immediately. Over time, I developed sort of a playbook for those sessions and made the Notion pages interactive. In parallel, I signed up several more users; at the peak (about six weeks after starting) there were six paying, daily active users.

It was going pretty well! To take a step back: there were real daily users; there was revenue; there were the beginnings of a product. The elephant in the room, though, was scalability: I could have probably served 25 users at most if I spent all of my time on calls. But I wasn't too worried: for me, optimization and automation are the easy parts.

So I formulated a scalability KPI: how many minutes did the user spend learning for every minute spent by a coach. The baseline was 1:1, and a back-of-the-napkin calculation showed the business would start to make sense at about 50:1. To get there, I made many changes across several weeks. One-on-ones became shorter, less frequent, on-demand. In parallel, I added support rails to make the learners more independent: automated self-coaching; templates for reviews; content to explain good learning methods; etc.

The KPI was improving and users were learning. But I noticed a suspicious pattern formed: it seemed that users were showing up less often for their scheduled individual sessions. The power-user curve was looking worse. To some extent this was to be expected: by reducing human coaching, I was removing some of the value users were getting out of the product. But for self-coaching to work, the software would need to stand on its own with minimal coaching.

Apparently, it didn't. User activity kept dropping; value was leaking. To dig deeper, we interviewed all current and churned users about what they found most valuable about our product. The result was less than encouraging: people used this product mainly because they believed specifically in me, and my ability to help them learn. While flattering, this was the furthest I could get from scale: we had been simply selling my time at a heavy discount.

By the way, you'll notice I switched from "I" to "we" – about halfway through the learning product, I joined forces with Laur Läänemets, a friend who was about to leave his job. Laur's user focus and ability to relentlessly but kindly get through to any person were the perfect complement to my technical and abstract inclinations.

We spent another couple of weeks looking for pivots. We considered selling it directly to students or trying to go through universities, but after dozens of interviews, neither path seemed like a good idea. So by the end of May 2021, we were two full-time founders fresh out of a product – and decided to take a month off before coming back with fresh minds full of motivation.

Chapter 3: synthetic cheese and labs in the cloud

In July 2021 we went back into action. After brainstorming and self-reflecting we ended up with several interesting directions, the first of which was climate change. Specifically, we wanted to increase carbon offsetting and capture.

After about two weeks' investigation, it seemed that... we couldn't. There is enough supply, but demand for voluntary carbon credits was small and growing slowly (see Exhibit 2 in the linked report). Becoming the 257th middleman that allows you to calculate and buy offsets didn't seem to add value either. The best approach we could think of was to simply create a better product in some category, and also make it carbon-neutral. Kind of like Tesla is building overall better cars, not worse cars that are carbon-neutral. But the top-down approach of searching for better products to make didn't feel productive, so we moved on.

(By the way, we were probably wrong about the demand-side. KlimaDAO, launched in October 2021, seems to be successfully creating demand for voluntary carbon credits. It has flaws, of course, and it's an early-stage crypto project, but it's encouraging to see progress in the demand direction.)

At around the same time, Laur spoke to Kaisa, a young food science founder working on dairy made with precision-fermented casein, and we delved into it together with her – a biotech idea. (This idea is simultaneously in categories: plant-based alternatives, synthetic biology, food-tech, etc.)

This seemed exciting! But wait... How did we stumble from software into biotech? I think the soil was fertile from our recent dive into carbon emissions (which dairy contributes a lot to), and Laur's family – with a respectable history of farming – has a thousand-head dairy farm in Estonia, which gave us a close-up view into how cow's milk is produced today.

What's more, vegan cheese was actually a personal problem I'd thought about before! In my striving-vegan-but-really-vegetarian diet, I've tried many vegan cheese replacements. My gastronomic take is that current vegan cheeses are simply not in the "cheese" product category. The nutritional value, taste, texture, smell, price – every important feature of food – is different and clearly worse.

The technical reason is that casein (the main class of proteins in milk) is absolutely critical to making cheese. Casein is 80% of the protein in cheese; it's a critical part of turning liquid milk into solid cheese; it defines the texture of cheese. Plant proteins have the wrong texture and often taste bad, so most vegan cheeses are made with almost zero protein and ~25% fat, compared to cow cheeses of ~25% protein and ~25% fat. The missing piece is non-animal casein.

Anyway, I had noticed this problem before but not taken it seriously – I had zero background in biology, food science, and manufacturing in general. But the solution is straightforward: you can engineer cells to manufacture any protein you desire. The technology is already in broad use for making pharmaceuticals, and casein has been made in the lab tens of years ago. What's more, we're confident the market is there: a vegan dairy product that is close to cow's-milk cheese would fly off the shelves.

After determining that good vegan cheese isn't ruled out by the laws of physics, we started looking into its economics. We knew it would be hard to sell a replacement product for 10x or 100x the price – we'd need to get to price parity, or close enough. We made spreadsheets. We talked to food experts and SynBio experts. We changed our estimates by orders of magnitude, several times. But in the end, it looked like cheese with synthetic casein could eventually cost as little as cow's milk cheese (which, by the way, is absurdly cheap given the cost of its inputs).

So, we knew good vegan cheese can exist, the price can eventually come down, and there is plenty of demand if we are able to get there. With the destination clear, we now had to think about the trajectory. After many more calls with people in the industry, it turns out the path to a biological manufacturing process at scale is pretty straightforward.

Here's my simplistic view of scaling: you need to scale into bigger pots of stuff while still keeping the process efficient. First, you try to make a manufacturing process work in a lab – say, in 10mL flasks. Then you go to a larger volume (say, 1L), and make sure your process still works there – that is, the yield is still good enough, which means your unit economics are still good enough. You iterate on the process until it does. Then another step up, and another, until your process works at an industrial scale – in reactors that hold tens of tons of liquid.

Of course, that's easier said than done. Scaling biology apparently isn't as straightforward as scaling software, for two reasons. First, organisms are complex systems that are not perfectly understood, so changes in conditions (pH, temperature, oxygen levels, feed, etc) can reduce yields by orders of magnitude without obvious explanations why that happened. And second, while it is easy to keep a one-liter reactor at stable conditions, it's much harder to do that in a room-sized reactor. Due to uneven mixing, you'll have pockets with suboptimal conditions, and guess what – the strain you engineered is much less efficient in some of these pockets, killing your yield.

In addition to scaling, there is regulation. The European Union has regulations around novel foods, and the estimated time to bring a compliant product to market is 2-3 years. While there are markets with friendlier food regulation (literally any other place on Earth), food is a relatively local industry, and it seemed a stretch to start selling products in Singapore, Israel, or the US while based out of Estonia.

The trajectory we ended up sketching was the following. In the best case, we'd need a minimum of two years to develop the manufacturing process to the scale where we could produce tens of kilograms, not just grams. After that – not in parallel – it would take another two years to pass regulation. So it would take us four years before we could sell even a single gram of cheese. (This was our optimistic take; industry veterans seemed to assume about 10-20 years for something like that.)

The long time to market was discouraging. And even though it was balanced by the powerful mission, we weren't the only hope. There are several companies making good progress towards vegan dairy, and we didn't have a clear answer for what we would do better. Reluctantly, we gave up on synthetic cheese.

The good news was, we'd discovered a clear problem in biotech: lab work takes forever. For strain engineering, i.e. making changes to an organism's DNA so it does more of what you want, the development cycle is pretty well-defined. First, you figure out what DNA change to make (Design). Second, you make cells with that modified DNA (Build). And third, you run experiments to see if it had the desired effect (Test). The problem is, these cycles are loooooooong.

During the previous idea, we'd started working closely with Petri-Jaan, an energetic and commercially-minded professor at Taltech. In his lab, the actual cycle time was about 6 months. The best, well-funded, and automated commercial labs like Ginkgo's can probably do a cycle in a few weeks. The absolute lower bound is the time it takes your organism to grow – a couple of days.

We imagined a sort of "cloud lab" where, instead of spending years and millions on setting up your own lab you'd ship your samples to a centralized highly-automated lab that runs experiments for you, and sends data back. Like AWS but for bio-labs. Writing this I realize it sounds a bit like a sitcom startup idea, but the problem is real – and some startups are tackling it. And our background in automation and some experience with hardware was an advantage.

To see if the idea would fly, we embarked on another set of user interviews. We tried to talk to as many biotechs in Europe as we could reach. There turned out to be surprisingly few. As far as I can tell, there are plenty of biotech companies working on pharmaceutical applications, but few working on much more price-sensitive industrial and food products.

The response to those interviews was overwhelmingly clear: no need for this sort of outsourced lab. Why? They already had good enough facilities, at least at the lab scale. That's because most biotech companies in Europe are born out of universities with existing labs, where they can usually use labs on good terms. Facilities for scaling upwards from 100L vessels would have been much more interesting than our planned small-scale vessel lab, but the capital needed to do that would be infeasible for a VC-funded startup.

We took the hint. A cloud lab in Europe targeting food and industrial products did not seem necessary in September 2021. For the next several weeks we investigated a bunch more directions: cell metabolic modeling software, lab automation, oleochemical production, and others. But in the end, we couldn't convince ourselves to commit to any of those.

Epilogue

The end wasn't a well-defined point. There was no finish line, no deity to say that my founding journey was over. The end began in October when I reflected on the attempts I've described above. Each had been serious; each had failed.

For each of those failures, you could tell one of two stories. The first is one of lack of grit and persistence – two important qualities for founders. If I had only stuck to it and maybe found a different angle, I could have succeeded. And I agree. No startup sails smoothly from Day 1 to eventual massive scale. If you give up every time the going gets hard, you can't build something great.

There's also a second story. One of fast iteration and killing your darlings. There is little value in persisting on a path that goes nowhere, so ideas should be put to the test – which I did. If the result is negative, you should move on – which I did. And this story also has merit, because the opportunity cost is real. If not foregone money, at least foregone impact: there are hundreds of companies where I could contribute to some other important vision of the future.

There's no way of knowing the counterfactual – what would have happened had I continued on the same path instead of moving on to the next idea. But the thing that helped me make peace with the decision to stop working on each idea, and eventually stop working on my own ideas, for now, was a sort of meta-suspicion. Maybe my thinking process around founding was mistaken.

Perhaps I didn't believe enough in the ideas; wasn't emotionally invested in those futures. Maybe I tried too hard to generate ideas and ended up with artificial top-down ones. Probably I should have spent more time learning and exploring and tinkering instead of immediately trying to force a startup out of it. I may have been afraid to launch publicly. Probably all the above and more.

As I said, the end began by reflecting on my attempts. At one point I realized I don't believe the next attempt would succeed. That was the end of the end...

...for now.