Ten Lessons from a $3 Million Mistake
January 19, 2026
In July 2023, we started Kortex—a "second brain" AI notetaking app. Two years and $3 million later, we killed it. Now we're building Eden, the cloud storage drive for creatives.
Kortex didn't fail because we ran out of money. We were bootstrapped, reached $60K MRR, and our Cofounder Dan Koe kept the lights on through sheer will. We killed Kortex because we had built ourselves into a corner so tight that adding a Google sign-in button felt like a six-month project.
Here are the startup lessons I learned from two years of mistakes as a first-time founder. These learnings are nuanced and should be taken with a grain of salt. I can only speak to pre-product-market-fit startups; your mileage may vary.
1. Test against reality, not opinions.
The fastest way to test a hypothesis is to build it. Debating an idea endlessly won't get you anywhere.
In May 2025, my cofounder Ari and I took what was supposed to be a vacation to Japan. We were both exhausted. Kortex development was stuck at a standstill. Instead of delivering on promises to our users, we spent our time on maintenance, bug fixes, and recovering data loss—the result of trying to build everything ourselves.
I had brought up the idea of rebuilding our entire app for months. I was certain we could rebuild the product in a tenth of the time it had taken us, if we just made some better design choices and abstracted away certain problems. Every time, we dismissed the idea without testing it.
Since we were in Japan, Ari and I had an excuse to not work on the main app for a few weeks. It was the perfect opportunity to test our hypothesis. Instead of sightseeing, we spent three weeks secretly rebuilding the entire app. New stack with end-to-end type safety, third-party auth that just worked, a sync engine we didn't have to maintain, and one file to define schema and permissions as a single source of truth.
We'd discussed this approach before, and it always got shot down in committee. Building it proved what talking never could. The entire app could be rebuilt, better, in three weeks.
2. Scrap your work often.
Getting too attached to your work leads to getting stuck at local maxima. You optimize for what you have instead of questioning whether you should have something different entirely.
After Japan, we came back and revealed what we'd built. Some people were upset, and some left. It felt like betrayal to those who had invested years into the old system, but the alternative was impending death.
Two months later, we launched our new company, Eden. Black Friday weekend brought in $250K in four days—4x what Kortex did the year prior. We can ship features in days that used to take months. Everyone owns projects end-to-end, and nobody is blocked by other parts of the stack anymore.
Rebuilding from scratch seemed like a poor decision, but it was the necessary step back so we could take ten steps forwards. Had we scrapped our work sooner, our company would be much further along than it is now.
At Eden, our most important team principle is to embrace scrapping your work. We don't care about being right, we care about finding the right answer.
3. Unclear vision at the top poisons everything below.
When leadership can't articulate a clear direction, it trickles down to every level. Engineers build features that don't fit together. Designers make inconsistent choices. Everyone rows in different directions, and the product becomes a Frankenstein of half-executed ideas.
At some point, when teammates were asked what we were building, they'd say "Notion but with AI." That's when I knew we had a problem. We'd marketed Kortex as revolutionary, but we were essentially rebuilding Obsidian for the web and latching an AI chat onto it. The product didn't match our vision because we'd never gotten clear on what the vision actually was.
One of our best engineers left when we pivoted. In our final conversation, he listed frustrations that had built up over time. Unclear vision. Missed timelines. Half-finished features. Low standards. Every point was valid. I had failed him as a leader.
Having a mission statement isn't enough. Your team needs to feel it in their bones—they need to be able to explain it to their friends and feel proud. We never got there with Kortex. If your own team is confused about what you're building, your users will be too.
4. Premature scaling is a form of procrastination.
Building infrastructure feels like progress because it's tangible and you can point to it. But if you haven't found product-market fit, you're just procrastinating with code.
We built our own rich text editor extensions, a self-hosted authentication system, our own offline sync engine, our own usage-based billing infrastructure, and our own hosting setup with Terraform scripts. These problems are non-trivial. Entire companies exist just to solve each one of them.
We told ourselves we were "owning our IP" and "building for scale." In reality, we were avoiding the harder question of whether people actually wanted what we were building.
The order should be reversed. Build fast and scrappy to figure out what people want first. Then, when your servers are on fire because you have too much user demand, start building for scale.
5. Structure determines speed, and speed is all you have.
We organized our team like a big tech company. Frontend lead, backend lead, infrastructure lead. Tasks were clearly defined, but the structure was completely wrong.
When you compartmentalize by tech stack, nobody owns any feature end-to-end. A simple change requires three people to coordinate, and suddenly you're "blocked by frontend" or "waiting on infra." We imported all the bureaucracy of a large company without the resources to match.
Our tech stack reflected the same mindset. React and Typescript on the frontend, Django on the backend, custom self-hosted auth and EC2 instances. Our frontend devs never worked in Django, and our backend engineers never touched React. Each person worked on seven different features at once, yet no one had clear ownership over any of them.
At a startup, everyone should be full stack. The tech should be lean. People should own entire projects end-to-end. When one person owns a feature, the iteration cycle shrinks from weeks to hours. When a feature has dependencies on three different people who aren't always available, even small changes stall.
Compartmentalizing also changes what people optimize for. When an engineer only owns a slice, they're incentivized to make their slice clean—good architecture, elegant abstractions. They become resistant to change because change means rework. But it doesn't matter how clean your code is if it shouldn't exist in the first place.
When each person owns a project end-to-end, they're directly user-facing. They have the full context. There's no more "I'll leave it to product to figure out the requirements" only to get frustrated when they change. The engineer is product. At Kortex, our structure led to two-week deployment cycles. At our worst, we went an entire month without releasing an update. At Eden, we ship to prod nearly every day.
Sam Altman said that startups should aim to "build the fastest-iterating company the world has ever seen." If you get 2% better every cycle, and your cycle is every few hours rather than every few weeks, the compound effects over a year are staggering.
A startup's greatest advantage is speed. By structuring ourselves like a big tech company, we threw away the one thing that made us competitive.
6. Sunk cost fallacy leads to a slow death.
The sunk cost fallacy is as much an emotional force as an economic one. People build things, and scrapping them feels like scrapping their contribution, their identity, their time. So you keep going, and the hole gets deeper.
Halfway through, we knew the tech stack was wrong. We discussed rebuilding several times, and each time it was brought up, the idea was shot down.
"We've already invested so much."
"It would throw away months of work."
"Let's just push through, we're almost there."
Our self-hosted authentication system, Keycloak, cost us hundreds of thousands of dollars in engineering hours. Configuring it, maintaining it, debugging it, rebuilding it when things broke. In our new setup, third-party auth took about a week to configure. It just worked across all platforms, all social logins, and we never had to touch it again.
We made the same mistake with offline sync. We thought building our own solution on top of RxDB would take a month. Three months in, we knew it was the wrong call, but we kept going. Meanwhile, features users actually wanted—mobile app, more powerful AI features, support for more file types—sat untouched. Instead of shipping, we were knee-deep in debugging data loss from sync conflicts.
What finally broke the spell was Japan. Stepping away from the day-to-day, changing environments entirely, gave me and Ari the space to zoom out. When you're in the trenches, you can't see how deep the hole has gotten. Distance helps.
Now at Eden, we happily scrap work. Every team member is accustomed to having a project rewritten or abandoned a few weeks in. That's normal, and we celebrate it. Before product-market fit, the goal is to iterate toward something people genuinely want. Going too far down the wrong path won't get you there. Test against reality early. Talk to users. If they don't care, reconsider whether you should be building it at all.
7. There's no such thing as a part-time early employee.
Building a real product from zero to one takes everything you have. Early stage startups are not a lifestyle business. When someone is only half in—splitting attention, treating it like a side project—it shows. Missed deadlines. Poor design choices. Unreliable output. And it creates more work for everyone else because one person's blocked ticket becomes another person's bottleneck.
We hired over a dozen people who are no longer with us. Interns, part-time contractors, people splitting time with other jobs. Almost none of them worked out.
We also learned that grit matters more than talent. With determination, skills can be learned. Without it, even talented people will leave when things get hard. And things always get hard.
High turnover killed us too. Every time someone left after a few months, we lost institutional knowledge, wasted weeks onboarding their replacement, and disrupted momentum. The adage is right—hire slowly, fire quickly. We did the opposite. We hired too fast and made tough decisions way too slowly. Those delays cost us hundreds of thousands of dollars.
There are rare exceptions to the part-time rule. Ari joined in November 2023 as a part-time developer while working another full-time job. But despite being "part-time," he put in more hours than our full-time engineers—while holding down his other job. That's why he became CTO at Kortex, and later, Cofounder and CTO at Eden.
Our current design lead at Eden is technically part-time because she's still in school. But her commitment, proactiveness, and output exceed what you'd expect from most full-timers. In practice, neither of them was ever actually part-time. That's why it works.
Naval Ravikant says all returns in life come from compound interest—in wealth, relationships, and work. The same applies to teams. You need people who are all in and in it for the long haul. Otherwise, you never get the compounding. Time together gets cut short before any real momentum builds.
8. Standards are set by what you ship, not what you say.
Your actual standards are revealed by what you release into the world. Every time you ship something you're not proud of, you're telling your team that mediocrity is acceptable.
We talked about quality constantly. We had style guides and code reviews and QA processes. Then we'd ship buggy features anyway because we were "behind schedule."
After two years of this, people grew disillusioned. Everyone had high internal standards, but the lack of focus, poor design choices, and constantly changing requirements led to an inability to ship high quality work as a team. With every mediocre update we released, we also chipped away at our internal morale.
While it's important to ship fast, as your user base grows, it also becomes increasingly important to test and polish new features before they're released.
9. The wheels have been invented.
There's no prize for building your own sync engine. Users don't care how their notes sync. They care that their notes are there when they need them. Every hour spent maintaining infrastructure you built yourself is an hour not spent finding product-market fit.
For two years, we insisted on building everything ourselves—custom auth, custom sync, custom billing. We thought using third-party services was somehow cheating, or that we'd lose control, or that it wouldn't scale.
Meanwhile, Vercel uses Orb for billing and OpenAI uses third-party auth. Companies far larger than us happily abstract away hard problems so they can focus on their actual product.
I first learned this principle from Vitalii Dodonov, Cofounder and CTO at Stan. In November 2024, he invited us to their Toronto office and shared their principles for building a billion-dollar company with ten people. When he explained that "all wheels have been invented," I realized we were doing the exact opposite. That conversation planted the seed that eventually led to the rebuild in Japan.
A good heuristic for when to outsource to a third party solution is if outsourcing will cost less than a dev salary over time. If so, and if the solution is not related to your core product, it's probably worth outsourcing.
Don't spend your time rebuilding wheels that have already been invented. Focus on core product value instead.
10. Hold strong opinions loosely.
Our biggest mistakes came from overconfidence. We were confident in our tech stack, confident in our team structure, confident we knew how to scale. Confidence feels good, but it's also a signal to stop learning.
The best leaders I know hold strong opinions loosely. They're decisive without being dogmatic, committing fully to a direction while remaining open to evidence that they're wrong. We committed fully and forgot the second part.
The $3 million we spent on Kortex was tuition. We learned what not to do, and that knowledge is now baked into everything we build. The real failure would have been learning nothing.
If there's one thread through all of this, it's that early-stage startups live or die by iteration speed. Everything else—team structure, tech choices, hiring decisions—either accelerates or slows your ability to test ideas against reality.
We slowed ourselves down at every turn. We built infrastructure instead of product. We organized like a big company. We held onto bad decisions because of sunk cost. We hired people who weren't all in.
At Eden, we do the opposite. Small team, full-stack engineers, third-party tools for everything that isn't core product, and a culture where scrapping work is normal. We ship to prod every day. When something isn't working, we kill it and try something else.
These lessons cost us two years and $3 million. If you're a first-time founder, I hope they help you avoid making the same mistakes we did.