← BACK TO PORTFOLIO
Live

Kaushift

LinkedIn shows you the polished win — Kaushift shows you the messy crash nobody posts about

HTMLCSSJSNext.jsGoogle AuthSupabaseVercel

The Problem

Startup culture is obsessed with success stories. Founders post about funding rounds, launches, and milestones, but when a startup dies, the real reasons rarely get written down. Most failures end in a quiet LinkedIn post or silence. That leaves first-time founders repeating the same mistakes, like building before validating, running out of runway, or breaking down as a team, because honest data on why startups fail is scattered, sugarcoated, or missing.

The Idea

Kaushift is a community where founders share honest post-mortems of startups that failed. The goal is to make failure searchable, specific, and learnable. Instead of vague advice like 'fail fast', a reader can see exactly what broke, when, and why. I also built Kaushift as my public build-in-public project, putting my name on it as its founder while the people who post stay anonymous. Personally, I wanted to turn the mistakes and failures I've experienced while building into something that could help others build smarter.

What I Built

Kaushift lets verified founders publish structured post-mortems anonymously and lets readers discuss them in a community feed, with posts organized by what went wrong so patterns are easy to spot. The platform is currently under development.

How It Works

A founder signs in with Google, verifies their business by uploading a GSTIN document, and publishes a post-mortem through a structured form covering what the startup was, how long it ran, what went wrong, and the main failure cause. The post appears under an anonymous identity in the community feed, where readers can upvote it and discuss it in the comments. Readers can browse by failure cause to see patterns across many startups instead of reading one story at a time. The app is built with Next.js, uses Supabase for the database, Google authentication for sign-in, and is deployed on Vercel.

Key Decisions

Three decisions shaped the project. First, a community instead of a blog. A blog is one voice, but a discussion lets readers add their own experience to every post-mortem, which makes each one more useful. Second, structure instead of free writing. Asking every founder the same core questions makes posts comparable and keeps them honest instead of turning into vents. Third, shipping a lean V1. I focused on publishing and discussing post-mortems first and left everything else for later, so the project could launch and start getting real feedback. I chose this stack to keep Kaushift simple to build, easy to maintain, and quick to deploy as an MVP.

Challenges

The biggest problem wasn't technical, it was human: why would a founder whose business just failed share it publicly? Failure carries shame, and a post-mortem with a real name attached can hurt reputation, future fundraising, and relationships. But anonymous posts alone bring a different problem, because anyone can claim to have run a startup and invent a story. I needed both honesty and credibility. My solution is verified anonymity. To post, a founder verifies their business by uploading their GSTIN document to our server. It is used only to confirm the business is real and is never shown publicly. On the app itself, the founder stays completely anonymous. Readers know every post-mortem comes from a verified founder, and founders know their identity isn't exposed. That trade is what makes people willing to write honestly.

The Data Angle

Because every post-mortem is tagged with a failure cause, Kaushift naturally produces a dataset. Causes like no market need, running out of cash, team conflict, and bad timing can be counted and compared across posts. As the community grows, this turns individual stories into patterns: which causes are most common, and which show up at which stage.

What I Learned

Building Kaushift in public taught me to cut scope faster and care more about the first-time user experience. It also showed me that the hard part of a community product isn't the code, it's getting people to contribute and figuring out why someone would be willing to share their failure in the first place.

What's Next

Next steps are growing the first set of post-mortems, improving how posts are discovered and filtered, and turning the failure-cause data into published insights.