title: "I Almost Built a Startup This Week. The Evidence Said No — In One Afternoon."
published: true
description: "I found a hot market, a funded competitor, and a technical edge. Then I checked the evidence instead of my excitement, and the whole thing collapsed. Here's the checklist that saved me six months."
tags: discuss, startup, career, ai
I nearly threw the next six months of my nights and weekends at a startup idea I was genuinely excited about.
Hot market. A funded competitor proving people cared. A technical angle they didn't have. Every signal a builder waits for, all lit up at once.
I didn't build it. And the only reason is that I made myself answer four questions with evidence before I let myself open an editor. The idea died in about one afternoon — and that was the best possible outcome.
If you're sitting on an idea that feels obviously right, this is the checklist I wish I'd run years earlier.
The setup: everything looked green
I'd been deep in one problem for weeks and had built two small open-source things around it. Then I found a startup doing something adjacent — slick site, 1,000+ GitHub stars, a strong Product Hunt launch, clearly funded.
And my brain did what every builder's brain does:
"The market's validated. A competitor exists. I have an edge. This is my lane."
That exact feeling — validated market, real competitor, personal edge — is the one that separates you from six wasted months. So instead of building, I opened a list of questions and refused to write a line of code until I'd answered them honestly.
Question 1: Does the competitor actually make money?
This is the one everyone skips, because a funded, popular competitor feels like proof the business works.
It isn't.
I went looking for the competitor's revenue, paying customers, contracts — anything. What I actually found: the product is free forever for individuals, enterprise is "custom pricing," and the public evidence stopped at "early proofs of concept." Trials, not confirmed paying customers. Even the funding number I could only find self-reported.
That reframes everything:
| Signal | What it actually proves |
|---|---|
| 1,000+ GitHub stars | People are curious |
| Strong Product Hunt launch | People clicked once |
| "Early POCs" | Someone's trialing it for free |
| Revenue | ...no public evidence |
I had been about to treat a competitor's marketing traction as market validation. Those are different things, and confusing them is how people build businesses nobody pays for.
Question 2: Is my technical "edge" actually mine?
My angle felt novel. So I searched to see if it was.
It wasn't. Even a little.
There was an entire wave of 2026 research on exactly my idea — papers, open-source implementations under permissive licenses, a big lab's system, a paper whose title was basically my pitch.
"I've never seen a startup do X" is not the same as "X is novel." Startups are a lagging indicator of research.
By the time an idea feels like an obvious wedge to a solo engineer, a dozen labs have usually been on it for a year. My edge wasn't an edge. It was a well-known direction I'd rediscovered on a weekend.
Question 3: Does my thing even work?
Before deciding to sell my defense, I finally ran the honest experiment I'd been avoiding. Four setups, measuring two numbers that must always travel together: how many attacks it stopped, and how many legitimate actions still worked.
My tool caught attacks the alternatives missed. Great.
It also blocked 100% of the legitimate actions.
The reason was almost funny, and it doesn't matter that it's in my niche — the shape is universal: my clever filter couldn't tell a legitimate action from a malicious one, because they arrived looking identical. Useful signal, unusable product. I was one weekend of excitement away from shipping something that blocks every real thing a user tries to do. The experiment cost an afternoon. Finding this out from angry users would have cost six months.
Question 4: Is it crowded where I'm weak?
"Everything's crowded" is a lazy no. This was a specific one: the exact approach I'd bet on was being pursued by funded startups, big-lab research teams, and free open-source projects simultaneously — and the hard, defensible part was precisely where a solo engineer competes worst against funded teams with a head start.
Crowded isn't automatically a no. Crowded at the exact layer where you're weakest is a no with reasons.
What the evidence actually recommended
Add it up:
- Market real, but willingness to pay unproven — even for the funded incumbent.
- My "edge" is a known research direction, not a wedge.
- My prototype has real signal but a fatal flaw I can't yet fix.
- The competition is thickest exactly where I'm weakest.
So: don't build the startup. Not "never." Just "not on this evidence, not yet."
But the same afternoon clarified what was worth my time. The benchmark I'd built — the thing that measures how well anyone's defense works — isn't a competitor to anyone. It's the referee. That's an uncontested, useful role, it builds exactly the reputation that leads to paid work, and nobody's fighting me for it.
The part that generalizes (this is why I'm writing it)
You don't need to care about my niche to use this:
- A competitor's popularity is not proof of a business. Find the money, or admit you can't.
- "Nobody's doing this" is not proof of novelty. Check the research — it leads startups by years.
- Run the honest experiment before you fall in love. Measure the failure case, not the demo.
- "Crowded" only matters when it's crowded where you're weak.
None of this is anti-ambition. It's the opposite. The whole reason to check the evidence fast is so you spend your limited nights and weekends on the bet that survives the checking — not the one that merely survived your excitement.
My idea died in an afternoon. It was the most productive afternoon I've had in months.
Have you ever killed an idea early and been glad you did — or shipped one you should've killed? I want the war stories, both directions. 👇
I write about backend engineering, building things, and the honest math behind whether they're worth it. Follow me here if that's your kind of thing. 👋
Top comments (19)
Treating a competitor's stars and PH launch as market validation is exactly the trap I fell into once. Your "marketing traction ≠ revenue" table is the part I wish I had printed. Forcing an afternoon of evidence before opening the editor feels slower in the moment and so much cheaper than six months of nights on a free-forever lookalike.
The stars trap is sticky because the signal feels so concrete — a number going up. But stars measure "developers think this is cool," which is a different population from "someone will pay," and the gap between those two is where the six months of nights disappear.
What finally broke the spell for you — the dead project itself, or something you read? For me it took shipping one before I'd believe the table.
A couple actually. 1 notable one is TUB, an employment matchmaking app, where your CV is only sent to 1 employer max, per available position, we only send 1 CV, which is in our entire finding, the single person that is best qualified for it. Great concept, great tech, dead... Because paypal cant pay out to my country...
Oof, that one stings — because the idea and the tech were both sound. It didn't die from a bad bet, it died from plumbing. And honestly, payment/payout infrastructure kills more good products in certain countries than competition ever does. Nobody warns you that "can I actually get paid" is a feature you have to validate as hard as the product itself.
The TUB concept is genuinely sharp too — one CV, one best-matched candidate per role. That's the opposite of the spray-and-pray job boards everyone hates.
Did you ever look at Stripe / Wise / Paddle as a merchant-of-record workaround, or was the whole payout rail just closed off for your region? Curious whether it was truly dead or just parked.
I did look into Wise, but the overhead of the Forex would kill the business. The one workaround I thought of was given it revolves around partnering with an EOR, that the EOR handles the payments, essentially dog-fooding. I might pick it up again though, but the paypal move promised for this year is probably the biggest thing that'll make it viable. What's good though, is since then, I used the knowledge and system from it, to build Resume Helper: github.com/UnitBuilds-CC/Resume-He... as a way to test the underlying tech and well... I got an interview from using it and hopefully come monday when I submit the 2 take-home assignments, I land the job.
That's why instead of scrapped, I rather look at TUB as shelved. I'll still start it up at some point, but when the time is right. I did write a post on it: dev.to/unitbuilds_cc/shelved-proje...
"Shelved, not scrapped" is exactly the right frame — the tech and the lessons don't expire just because the payment rail wasn't ready. And the EOR-handles-payments / dog-fooding idea is clever; you basically turn your own hiring pipeline into the first customer.
Honestly the best part of this whole reply is that TUB already paid off — it became Resume Helper, which got you an interview. That's the real ROI of a "failed" project: the compounding tech and judgment you carry into the next one. Very few people connect those dots as cleanly as you just did.
Fingers crossed for the take-homes Monday 🤞 go land it. And I'll read the shelved-projects post — that's a genre we need way more of on here.
I have quite a few I still meant to add to the series, but priorities kicked in and I had to shelve writing shelved projects... That being said, I wanna get into it again, finish up my list of shelved and also start a new series on single serving apps I made to solve an immediate problem, but decided to flesh it out, cuz who knows, someone might need it (eg. An entire installer wizard and an MSI crate, so it can do anything Inno Setup can + stuff like Ninite), or Drone, for cross-system testing.
Lets hope it goes well, 2 tasks, 1 is simple, meant as a basic POC, a simple abstract filesystem. The other is quite frankly, massive... Port pgrust to wasmer. Which is definitely not an afternoon task, cuz it involves making edits to a rust fork and compiling from source (on my system about 16 min just to compile), which has been eating at the timeframe. That being said the AFS is done, the pgrust port is functional, just needs more testing to make sure all edge cases are covered.
The "single-serving apps I made to solve an immediate problem" series is the one I'd actually read — the AFS and the pgrust→wasmer port especially, because the 16-min-compile, edit-a-rust-fork reality is the part most write-ups skip.
A dead project with the autopsy written is more useful to the next person than a live one with no notes. When you pick the shelved series back up, are you writing them as "here's what I built" or "here's why I stopped"? The second is rarer and ages better.
Yeah, it's gunna have to wait a min though. the interview went horrifically bad today... I struck blank on simple things, so now I gotta refresh and reset
Sorry, that's a rough one. Blanking on simple things under interview pressure says almost nothing about what you can build. You'd just been handed a pgrust to wasmer port as a take-home. People who can't do the work don't get that far.
A few things that are true even though they won't feel like it today:
Take the reset. The shelved-projects series can wait.
Was it the live coding that went sideways, or the conceptual questions?
Well during technical interview, it went on a single file review, a T2 package loader cache, which being in the middle of the actual package loader and the artifact cache, without the files for those accessible, was a bit of a blind box review.
Now, I'm choking on the pgrust and abstract filesystems. Specifically, I dont know how to walk people though a codebase, then technical questions like 'explain the fork semantics', 'you hardcode PID wrapper to 1, how does that allow concurrency', 'did you look deeper into the Linux VFS'. Keep in mind, I'm self taught in rust. I can write it, I can spot the difference, but I suck at explaining it and elaborating on it. I can find the flaw in the tokio task manager, explain why it was a bug and why my fix works, but 'did you consider other alternative', etc. are questions that I strike blank on. Cuz there's no alternative to doing it right. It's a simple recycle, not an architectural rewrite...
That's a presentation gap, not a knowledge gap — and it's the most fixable thing here. You clearly know the material (you found the tokio task-manager bug and can justify the fix); the interview just wants you to narrate the reasoning out loud, which is a separate, trainable skill.
Two things that fixed exactly this for me:
The "PID wrapper to 1 / fork semantics" questions aren't gotchas; they're invitations to think aloud. Do two or three timed mock runs explaining your own pgrust port to a rubber duck, out loud, tradeoffs included — it transfers fast. You're closer than today felt.
Thank you for that! It's about what I'm working on now, along with diagrams of the systems, so I can walk them through it visually, instead of diving into 100 different files to show and tell
Exactly the right instinct — a diagram turns "let me open 100 files" into "here's the shape, now let's zoom in." Interviewers read a clean box-and-arrow sketch as seniority: it says you hold the system in your head, not just the code. One tip: narrate it as a flow (request enters here → crosses this boundary → the thing you asked about lives here), not a static map. You'll walk them, not lose them. Go get it. 🤝
One question I've started asking myself is: "What evidence would convince me this idea is bad?" If I can't answer that before I start coding, I'm probably building with excitement instead of data. This article is a great reminder that validation isn't just about finding reasons to continue—it's about being willing to stop.
That's a sharper version of the whole article in one sentence, honestly. It's a pre-mortem: if you can't name the evidence that would kill the idea before you start, you're not testing a hypothesis, you're defending a feeling.
The trap I keep falling into is that once I'm excited, I unconsciously set the kill-condition to something that can never happen ("well, someone might pay"). Writing the disqualifying evidence down first, while I'm still neutral, is the only thing that keeps me honest later.
Stealing your question, by the way — "what would convince me this is bad?" is going on a sticky note above my monitor. 👊
That question is the whole article in one line. If you can't name the kill condition before you start, you're not testing an idea, you're defending one.
What makes it work is the timing:
I'd add one rule: write the answer down with a number in it. "Nobody wants it" is easy to argue with later. "Fewer than 3 of 20 people say they'd pay" isn't.
What was the last idea that question actually killed for you?
The filter that works for me is having to describe who opens it on an ordinary Tuesday, and why today rather than next month. Ideas I only want to exist cannot survive that sentence. Ideas somebody is waiting for answer it in one line.
That's a sharper filter than my whole checklist. Mine took an afternoon; yours takes ten seconds, and an honest answer usually settles it.
Running my two ideas through it:
The startup fails in one line. It's the same thing I saw with the competitor: lots of stars, no sign anyone was waiting for it.
I'm stealing "Ideas I only want to exist." 🙌
Do you run that sentence before you build, or only once you've caught yourself getting excited?