Evaluating Startup Ideas Like an Engineer

I’ve been evaluating a handful of venture ideas for the Egyptian market — a real estate platform, a healthcare interoperability layer, and a couple of others that didn’t survive the first round of scrutiny. What made the survivors different wasn’t inspiration. It was that they held up under the same structured pass I’d give a system design before committing engineering time to it.

The framework

Three axes, scored independently before combining:

• Market — Is the problem real and underserved, specifically in Egypt, or is this a solution imported from a market with different constraints? A gap that shows up in conversations with actual people beats a gap inferred from a spreadsheet.
• Feasibility — Can a small team actually build and operate this, given realistic constraints on capital, regulation, and time? A great idea that requires a bank’s compliance department is a different project than it looks like on paper.
• Personal fit — Do I have, or can I credibly build, the domain knowledge and network this needs? An engineer’s instinct is to treat every problem as solvable with enough system design. Some problems are mostly regulatory or relationship-based, and no amount of clever architecture fixes that.

Why this matters more than “is it a good idea”

“Good idea” is almost never the failure mode. Most ideas that don’t work aren’t bad — they’re mismatched to the team evaluating them, or the market isn’t ready, or the regulatory path is longer than the runway. Scoring across three independent axes surfaces that mismatch early, before it’s expensive.

It’s the same discipline as writing a spec before implementation: the framework doesn’t make the decision for you, but it forces the reasoning into the open where it can actually be checked.