Nine Lessons from a $3 Million Mistake
January 19, 2026
We think of startup failure as a sudden event: a moment when the money runs out, the team quits, the servers go dark. But most companies die slowly. They die from a hundred small decisions that each felt reasonable at the time, compounding quietly in the background while everyone keeps shipping.
That's how Kortex died.
In July 2023, we started building a "second brain" AI notetaking app for content creators. Two years, a dozen employees, and roughly $3 million in salaries, infrastructure, and operating costs later, we killed it. We weren't out of money. We were bootstrapped, had reached $60K MRR, and my cofounder Dan Koe kept the lights on through sheer will. We killed it because we had built ourselves into a corner so tight that adding a Google sign-in button felt like a six-month project.
Eventually, my cofounder Ari and I secretly rebuilt the entire product from scratch during a trip to Japan. That rebuild led us to scrap Kortex entirely and start Eden.
What follows are nine lessons from two years of expensive mistakes. I'm aware that survivorship bias makes it easy to construct clean narratives from messy reality. These lessons come from one specific experience at one specific company. Take what's useful; discard the rest.
1. The real failure was product, not engineering.
The most dangerous belief in early-stage startups is that execution can substitute for validation. We believed Kortex had a real differentiator: a notetaking tool built specifically for content creators. Not a generic second brain, but a workflow designed around how people like Dan's audience actually research, organize ideas, and produce content. Notion was for everyone. We were going to be for someone.
We never tested that sufficiently.
We assumed content creators needed a dedicated writing tool and went heads-down building for two years. We didn't talk to users nearly enough. We never seriously asked the one question that would have changed everything: What would make you switch from Notion? If we had, we would have discovered how high that bar actually was, and that most of our target users had already built workflows in existing tools that were good enough.
The signals were there. Sixty thousand dollars in monthly recurring revenue isn't nothing, but growth was flat and churn was high. We rationalized both as execution problems. The app was too slow. We weren't shipping fast enough. So we kept building. The real issue was that users didn't have a strong enough reason to stay. No amount of engineering fixes that.
When there's no product clarity at the top, everything below it becomes noise. At some point, when teammates were asked what we were building, they'd say "Notion but with AI." We'd marketed Kortex as revolutionary and were essentially rebuilding Obsidian for the web and latching a chat interface onto it. When leadership can't articulate a clear direction, engineers build features that don't fit together, designers make inconsistent choices, and the product becomes a Frankenstein of half-executed ideas. That's exactly what happened.
Before you write a line of code, you need to be able to answer one question: why would someone switch from what they're already using? Not "why might they switch." Why would they. If you can't answer that clearly, no tech stack, no team structure, no GTM strategy will save you.
2. Don't build for scale before you have demand.
Building infrastructure feels like progress. It's tangible, shippable, demonstrable. But if you haven't found product-market fit, you're procrastinating with code.
We built custom usage-based billing infrastructure before we had enough users to need it. We wrote Terraform scripts and self-hosted on EC2 when a managed platform would have been fine for years. We organized the team with a frontend lead, backend lead, and infrastructure lead: a structure designed for a company ten times our size. Every one of these decisions optimized for a future we hadn't earned yet.
There is a simple law here: build for the constraints you have, not the ones you aspire to. The order matters enormously. Build fast and scrappy to figure out what people want. Then, when your servers are actually on fire because you have too many users, start building for scale.
We inverted this, and it cost us.
3. The wheels have been invented.
For every infrastructure problem we faced (authentication, sync, billing, hosting), a third-party solution already existed. We refused to use it. We told ourselves we'd lose control. That it wouldn't scale. That outsourcing was somehow cheating.
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. When we eventually rebuilt the app from scratch, third-party auth took one week to configure. It just worked across all platforms and all social logins. We never had to touch it again.
Vercel uses Orb for billing. OpenAI uses third-party auth. Companies far larger than us happily abstract away hard problems so they can focus on the thing that actually differentiates them.
A good heuristic: if a third-party solution exists and will cost less than an engineering salary over time, use it. The only exception is when the problem is your product, the thing that makes you different from everything else. But be ruthlessly honest about what actually differentiates you. For us, sync and auth were never the product. They just needed to work. We should have outsourced them from day one and spent that time figuring out what actually made Kortex worth using.
I learned this principle from Vitalii Dodonov, cofounder and CTO of Stan, when he invited us to their Toronto office in November 2024. He walked us through how they'd built a billion-dollar company with ten people. When he explained that "all wheels have been invented," I realized we'd been spending years reinventing them. That conversation planted the seed that eventually led to the rebuild in Japan.
4. Structure determines speed, and speed is all you have.
A startup's only real advantage over large competitors is velocity. When you organize like a large company, you surrender the one thing you have.
We compartmentalized by tech domain. Frontend lead. Backend lead. Infrastructure lead. It felt professional. It was a disaster.
When nobody owns a feature end-to-end, a simple change requires three people to coordinate. You're "blocked by frontend" or "waiting on infra." You've imported all the bureaucracy of a big company without the resources to justify it.
Our stack reflected the same dysfunction. React and TypeScript on the frontend. Django on the backend. Custom self-hosted auth and EC2 instances. Frontend engineers never touched Django. Backend engineers never touched React. Each person worked on seven different features at once and had clear ownership over none of them.
Compartmentalization also changes what people optimize for. When you own only a slice, you're incentivized to make your slice clean (good architecture, elegant abstractions) and you become resistant to change because change means rework. But it doesn't matter how clean your code is if it shouldn't exist at all.
At Eden, everyone is full-stack. People own entire features end-to-end. When one person owns a feature, the iteration cycle shrinks from weeks to hours.
If you get 2% better every cycle, and your cycle runs every few hours rather than every few weeks, the compounding effects over a year are extraordinary. At Kortex, our structure led to two-week deployment cycles. At our worst, we went a full month without releasing an update. At Eden, we ship to production nearly every day.
5. Commitment matters more than hours.
Going from zero to one takes everything you have. This isn't a motivational claim. It's a constraint.
We hired over a dozen people who are no longer with us: interns, part-time contractors, people splitting time with other jobs. Almost none worked out. Not because they were part-time. Because they weren't truly invested. When someone treats your startup like a side project, it shows. Missed deadlines. Poor decisions. Unreliable output. One person's blocked ticket becomes everyone's bottleneck.
Every time someone left after a few months, we lost institutional knowledge, wasted weeks onboarding a replacement, and broke momentum. We hired too fast and made tough calls too slowly. Those delays cost us hundreds of thousands of dollars.
The counterexample is instructive. Ari joined in November 2023 as a part-time developer while working a full-time job elsewhere. Despite being "part-time," he put in more hours than our full-time engineers. 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; she's still in school. Her commitment and output exceed most full-timers I've worked with.
The pattern is clear: what predicts performance isn't the hours on a contract. It's whether someone is genuinely invested in the outcome. Grit compounds. With determination, skills can be learned. Without it, even talented people leave when things get hard. And things always get hard.
6. Your standards are what you ship, not what you say.
You can have all the style guides, code reviews, and QA processes you want. Your actual standards are revealed by what you release into the world.
We talked about quality constantly. 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, the constantly changing requirements, and the fragmented ownership made it impossible to ship high-quality work as a team. With every mediocre update, we chipped away at the product and at morale simultaneously.
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. His frustration wasn't just about direction. It was about watching the gap between what we said we stood for and what we actually shipped grow wider every month.
This might sound like it contradicts the lesson about speed. It doesn't. We shipped slowly and poorly. Fragmented ownership meant nobody had the full context, so everything was half-finished by design. Speed and quality aren't opposed when the scope is right. When one person owns a small, complete surface area, they can move fast and still be proud of what goes out. Our problem was never moving too quickly. It was moving in too many directions at once, with nobody empowered to hold the line on any of them.
Quality compounds the same way speed does. When you ship something you're proud of, the team raises its bar. When you ship something mediocre, you've just set a new floor. We kept setting new floors.
7. Test against reality, not opinions.
Debate is cheap. The fastest way to test a hypothesis is to build it.
In May 2025, Ari and I took what was supposed to be a vacation to Japan. We were both exhausted. Kortex development had stalled. Instead of delivering on promises to our users, we'd been spending our time on maintenance, bug fixes, and recovering from data loss, the accumulated cost of every mistake described above.
I'd been raising the idea of a rebuild for months. I was certain we could rebuild the product in a tenth of the time if we made better design choices and abstracted away the right problems. Every time I raised it, the idea was dismissed without testing it.
So we tested it. 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. One file to define schema and permissions as a single source of truth.
We'd discussed this approach before, and it got shot down every time. Building it proved what talking never could. The tech could be rebuilt, better, in three weeks.
But the rebuild answered only the technical question. The bigger realization came from the distance itself. Stepping away from the daily grind gave us the space to finally admit what we'd been avoiding: the product needed to change too. That clarity didn't come from the code we wrote in Japan. It came from being far enough from the trenches to see the full picture. It's what eventually led us to scrap Kortex and start something new.
8. Sunk cost will kill you slowly. Learn to let go.
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.
Every time rebuilding came up, it got shot down with the same phrases:
"We've already invested so much."
"It would throw away months of work."
"Let's just push through. We're almost there."
Every month we kept going, the cost of walking away grew, which made walking away feel less rational, even as staying was clearly failing. That's the trap. It took physically leaving the country to break the spell. When you're in the trenches, you can't see how deep the hole has gotten.
After Japan, we came back and showed what we'd built. Some people were upset, and some left. I don't want to minimize that. People had invested years of their careers into Kortex. They'd turned down other opportunities, relocated, worked nights and weekends. Users had paid for the product and built real workflows around it. When we scrapped what they'd all poured themselves into, it wasn't just a technical decision. It was personal. We owed those people more than a surprise pivot, and how we handled that transition is something I still think about.
Two months later, we launched Eden. Black Friday weekend brought in $250K in four days, four times what Kortex had done the year before. I want to be transparent: Dan has a large existing audience, and that launch was partly a marketing event driven by his platform. Early revenue is not the same as proven product-market fit from organic demand. We know that, and we're working to earn it.
But the numbers suggest letting go was the right call. If I could do it over, I'd scrap earlier, before people have invested months of their identity into something that might need to die.
9. Hold strong opinions loosely.
Our biggest mistakes came from overconfidence. Not arrogance, but overconfidence. There's a difference. Arrogance knows it might be wrong and doesn't care. Overconfidence doesn't know it might be wrong at all.
We were certain that organizing by specialty was the professional way to run a team. We were certain that building our own sync engine would be a competitive advantage. We were certain we'd find product-market fit if we just kept shipping features. Every one of those convictions cost us months and hundreds of thousands of dollars. Every one felt completely reasonable at the time.
The best leaders I've observed are decisive without being dogmatic. They commit fully to a direction while remaining genuinely open to evidence that they're wrong. We committed fully and forgot the second part.
There is a principle here worth stating plainly: conviction is a starting point, not a destination. You need strong opinions to move fast. But you need loose grip on those opinions to correct course when reality disagrees. We gripped too hard, for too long, on too many things.
The money 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 I were starting over tomorrow
Week 1: Pick a specific type of user and understand their workflow. Watch them work. Ask what's painful. Don't mention a product. Just listen. If I can't find a problem that's real, specific, and underserved by existing tools, I stop here.
Week 2: Only after confirming the problem is real, build the ugliest possible version that addresses it. Third-party auth, third-party sync, hosted everything. The only custom code is the thing that makes the product different.
Week 3: Get it in front of real users. Charge money from day one. If people won't pay $10 a month for it, no amount of engineering will fix that.
Ongoing: One full-stack engineer owns each feature end-to-end. No tech stack splits, no coordination overhead. Ship daily. Kill anything that doesn't move the needle within two weeks. Talk to users every single week.
Early-stage startups live or die by two things: whether you're building something people want, and how fast you can figure that out. Everything else (team structure, tech choices, hiring decisions) either accelerates or slows your ability to answer that question.
At Eden, we're trying to do the opposite of everything we did at Kortex. Small team. Full-stack engineers. Third-party tools for everything that isn't core product. A culture where scrapping work is normal. We ship to production every day.
Whether that's enough remains to be seen. We're still early. I'm certain there are lessons ahead that will make this list look incomplete.
These nine lessons cost us two years and a lot of pain. I hope some of them save you from paying the same tuition.