Founding AI Engineer
Founding-engineer roles go to whoever can turn a founder's vague problem into running software the fastest - not to the best resume.
How to read this page - source, method & limits
Where this comes from
A self-reported, first-person account of one real role, authored by the person who held it. There are no automated data sources, scores, or predictions on this page - every statement is a human claim. Each role is checked by an “honesty lint” before it ships: it must name the part of its success you cannot copy (the unfair advantage) alongside the part you can, plus at least one fake wall and one concrete first step.
How it's meant to be used
Intended: as one honest worked example of how a hard-looking role was reached, to copy the replicable lever and the first move. Not intended: as a checklist, a guarantee, or a claim that this is the only way in. It is a sample size of one.
Assumptions & limitations
Written in hindsight, so it can over-credit what happened to work and under-count luck and timing. It's also survivorship-biased - you're reading the paths that worked. Treat the prerequisites as “what mattered here,” not “what is required everywhere.”
If an AI coach discusses this role
A local coach can talk through this page using a hidden brief. It is instructed to separate the replicable lever from the unfair advantage and to never promise the role or any outcome. Verify anything time-sensitive (deadlines, named programs, contacts) yourself - those drift.
What it really is
Being the early technical person for a healthcare startup: AWS-based document processing, workflow automation, and the scaffolding an AI-enabled operation runs on.
What you actually needed
- Can ship a backend that processes real documents end to end
- Comfortable being the only engineer with no playbook and no senior to ask
- Trusted personally by the founder
Fake walls (looked required, weren't)
- A healthcare background, an AWS certification, or having built this exact thing before
The proof-of-work
Document-processing systems on AWS that actually ran inside a regulated domain - working infrastructure, not a prototype.
The move
Entered through the Stanford Impact Founder Fellowship via a founder relationship (with Zach Dyce), then earned the seat by building.
⚖️ The unfair advantage (named honestly)
Access to Stanford's GSB founder network and a fellowship that pairs builders with founders - a warm door most engineers never even see.
The replicable lever underneath it
The replicable lever is being the person a founder already trusts to build. You manufacture that trust by helping a founder on one small piece first, free, wherever founders gather: accelerators, hackathons, open-source, Discords.
The climb
- 1
If you're you can code but have no startup access
help one founder with a small, real technical task for free
→ leaves behind: a founder who vouches for you
- 2
If you're one founder trusts you
take on a whole feature or system and ship it under real constraints
→ leaves behind: running software a company depends on
- 3
If you're you've shipped for a startup
join the next one early enough to be its founding engineer
→ leaves behind: the founding-engineer seat
🌱 Do this week
Find one early-stage founder drowning in a technical task and offer to build a single piece of it this weekend, for free.
Ask the coach
Dig into how this role actually gets reached: the proof-of-work, the move, and what to do if you don't have the unfair advantage.
I'll answer honestly about how this role gets reached. I will not promise an outcome, and I'll always separate the part you can copy from the part you can't. Tap a question or ask your own:
Runs on your own machine. No outcome is promised; this is guidance, not a guarantee.
No outcome is promised. This is the lever and the move, told honestly - the rest is the work.