The Idea Was Never the Bottleneck

Why a physician with no engineering background is building software from scratch, and why the barrier that stopped you just fell.

Opinions are my own and do not represent my employer.

Why am I building Porch?

Part of it is a test.

I want to know if I can take an idea from nothing to a finished thing, alone, and ship it. Prove I can think it through. Prove I can build it without a team standing behind me.

For most of my life the honest answer would have been no. Not because the ideas were weak. Because the distance between an idea and a working product was too far to cross without a team, a budget, and a skill I did not have.

That distance just collapsed. Porch is where I am testing what happens when it does. It is a proving ground, and it exists because of a bigger leap I already took.

What people get wrong about building

The assumption is that ideas are the scarce thing. They are not.

My buddy Dale and I spent years spitballing ideas. Some were big. Some were almost embarrassingly simple. We called most of them impossible.

They were not impossible. They were unaffordable.

We once priced out a prototype for one of our bigger ideas. Not the product. Just enough to prove it worked. The quote came back at $10,000, and that was the end of it. The idea was sound. The number was the wall.

Every one of them hit that same wall. To build it, you needed an engineer. You either hired the guild or you joined it. A domain expert with a clear idea and no code was stuck at the doorway, holding a thing that only existed in his head.

Ideas did not die because they were bad. They died in the gap between conception and a thing that runs. The graveyard is full of good ideas owned by people who could not afford to build them. You probably have three of your own buried there right now.

The real cost was never the salary

People think the price of building was the engineer’s paycheck. That was the smallest part.

The real cost was translation. The person who understood the problem was almost never the person who could build the solution. So the idea got handed across a gap, explained and specced and rebuilt by someone who had never lived the problem. Every handoff leaked, and the result matched the spec while missing the point entirely.

That is the translation tax. It is why so much software built for experts feels designed by someone who watched a video of the job instead of doing it.

Collapse the distance between the person who knows and the person who builds, and the tax goes to zero. Not because the tools are magic. Because there is no longer a handoff to leak.

What actually changed

AI did not hand me a new idea. It removed the cost of executing the ones I already had.

That is the whole shift. Not invention. Affordability.

A person who understands a workflow can now build the workflow. Conceptualize it. Build it. Fix what breaks. Add the feature that was missing at 11pm on a Tuesday. Shape it until it fits the way you actually live, not the way a product manager guessed you might.

The self-serve pattern that let ordinary people file their own taxes without an accountant is now pointed at software itself. The specialist you used to hire is a tool you operate.

And the ideas did not shrink to fit the tools. They got bigger. The $10,000 that stopped us cold is now a rounding error against what one person can build in a weekend.

What Porch actually is

Porch is a family logistics app for iPhone. It runs the quiet coordination a household lives on: where everyone is, what is on the calendar, what is about to slip through a crack. The design goal is that the right thing surfaces on your home screen without anyone opening an app or being nagged. It is widget-first, because the best family tool is the one nobody has to remember to check. It launches in 2026.

Porch Alpha in the hands of 4 test families

I am building it alone. No co-founder. No engineering team. No outside shop. Concept, design, build, and launch route through one person directing a stack of AI tools. That is the test: whether a domain expert with none of the usual startup scaffolding can run every function of a startup and ship something defensible instead of disposable.

The reason it has to be me is the part that would never survive a handoff. Porch is privacy-first, and not as a bullet point on a landing page. As architecture. Email is parsed on the device. Raw content never touches a server. Location is overwrite-only, so there is no history to leak or sell. No analytics trackers. No ad networks. No third-party watching my family or yours.

That standard did not come from a startup playbook. It came from medicine. The test I run on every product decision is one question: would this be acceptable if the data belonged to a patient? If the answer is no, it does not ship. I spent a career treating data protection as non-negotiable, and Porch is what happens when that standard gets carried, intact, into consumer software, where it almost never survives contact with a growth team.

So this is not “a doctor made an app.” It is the operating standard of a field where privacy is sacred, ported whole into the software my own kids will use.

Make the right thing the easy thing

Here is the part that is not new for me at all.

For 15 years I have designed clinical workflows around a single principle: make the right action the easy action. Strip the friction off the correct path until doing the right thing is the path of least resistance. Trust-in-ease.

Porch is that same principle, pointed at my family instead of a clinic. Reduce the friction on the thing that should happen until it happens on its own. The clinical instinct and the builder instinct turn out to be the same instinct. One of them finally has tools that reach my kitchen table.

“But you still need real engineers”

True. There is a category of software where the cost of being wrong is catastrophic. Systems that move money. Systems that hold millions of users. Regulated clinical software where a defect reaches a patient. That work still demands deep engineering and real teams, and pretending otherwise is how people get hurt.

That boundary is real. It is also moving.

The set of things one informed person can build alone has expanded by orders of magnitude, and it already contains almost every impossible-but-simple idea that used to die on Dale’s whiteboard. The line keeps sliding in the builder’s favor every quarter. Your idea is almost certainly on the buildable side of it. Most people just have not checked lately.

What the tools still can’t do

The tools execute. They do not decide.

They will not give you the idea. They will not give you taste. They will not tell you what is worth building, or what “the right thing” even is.

They also lie by omission. A passing build is a claim, not proof. File presence is not completeness. The tool hands you something that compiles clean and looks finished, and it is still your job to know whether it does the thing. Early in Porch I audited a set of features the build reported as done. Directories existed. Tabs existed. Tests passed. Almost none of it was actually built. Nothing errored. Everything was wrong.

That is the lesson that separates building from typing. The verification discipline is the work. The orchestrator decides. The tool explains. Confuse those two roles and you will build fast, build convincingly, and build the wrong thing. That is learnable. It is not a wall. It is a skill, and you already have the harder half of it if you understand your own domain.

Without and with

Without these tools, an idea dies in the gap:

• it needs a co-founder who can code

• it needs capital to hire the build out

• it needs you to spend two years becoming an engineer before you even start

With these tools, the domain expert builds directly:

• the person who understands the problem writes the solution

• the fix ships the day the bug appears

• the product bends to the user instead of the user bending to the product

The gatekeeper step is gone. What is left is judgment and iteration, which is the part you were always better at than any engineer you would have hired.

What disappears. What remains.

What disappears:

• the engineer as gatekeeper

• “someday, when I have a team”

• “I’m not technical” as a reason not to start

What remains:

• judgment about what is worth building

• taste

• deep understanding of the actual workflow

• the person who knows what “the right thing” is

This is the line between Builder and Legacy. Legacy waits for someone to build the tool, then complains when it does not fit. Builder builds the tool to fit.

The credential that matters now is not the ability to write code. It is knowing exactly what should exist, and being unwilling to wait for permission to make it real. You have that credential. You have had it the whole time.

Why I wrote a book about the leap

The courage to build Porch did not come from a tutorial. It came from a decision I made first.

I left traditional healthcare. I walked away from the legacy track and joined a startup, on the bet that the future of medicine gets built, not defended. That leap is what my book is about: leaving the safe, industrialized version of a career for something bigger and unfinished. It is in final edits now, out in 2026.

That decision is what made Porch thinkable. Once you have already left the building, building your own thing stops feeling impossible. Porch is the proving ground. If I can ship this alone, I can build the far larger thing I actually have in mind, and it is not a family app.

So the sequence is the whole point. The leap comes first, and it buys the nerve. The build comes second, and the tools make it cheap. What you do with the thing you have proven you can build comes third, and that is where the stakes get real.

If you have carried an idea for years because building it was someone else’s job, that job is yours now. Take the leap. The build will follow.

---

The bottleneck was never the idea. It was the cost of building it, and that cost just fell to near zero for anyone willing to learn the new tools.

You are closer than you think. Closer than I was when I started.

So the question is not whether you could build it. It is this: which idea are you going to stop calling impossible, and start this week?