The Founding Engineer's Playbook: What You Actually Do in the First 90 Days

I have been a founding engineer three times. Unipe, Taksh Education as CTO, and OpenChain Foundation. Each time the first 90 days looked like a completely different job than the "senior engineer" role a company usually hires for. Here is what actually goes into those days if you want the company to still exist at day 91.

Week 1 and 2: the decisions you make once

• Pick your stack based on hiring pool, not personal preference. If you cannot hire two more engineers to work in your chosen stack within 60 days, you picked wrong.
• Set up CI and staging from day one. It costs a day of your time. Not having them costs a week of your time every month later.
• Write down your decision log in a shared doc. Every "we chose X because Y" is a future onboarding artifact you will thank yourself for.
• Choose observability before it is a crisis. Any error tracker and any log aggregator is infinitely better than none.

Week 3 to 6: shipping the smallest real thing

The founder wants you to build the product. Do not. Build the smallest possible version that puts one real user in the loop. Even if it embarrasses you. Even if it is missing the killer feature. A shipped v0 tells you more about the actual problem than a well-designed v1 sitting in staging.

At Taksh Education this looked like 100 learners on a basic MERN stack with Razorpay for payments. No fancy features. Just a real course, real students, real payment flow. This gave us six weeks of feedback that would have taken six months if we had waited to ship "properly."

Week 7 to 10: hiring your replacement

This is the part no one talks about. If the company grows, you cannot be the only one who understands the codebase. Start hiring at week 7, not week 20. And design the hiring bar to be someone who can operate at your level within the first month, not someone who will need six months of context.

If you have not documented anything by week 10, this hire will fail. Document as you build. Not later.

Week 11 to 13: making the founder replaceable

The founder is the biggest bottleneck in every early-stage startup. Not because they are bad, but because everything routes through them by default. Your job as founding engineer in the last month is to systematically remove the founder from as many technical decisions as possible. Not by taking over, but by putting rails in place that let the team make correct decisions without them.

• A style guide the team can point to instead of asking.
• A deployment process that does not require the founder's approval for routine work.
• A support system for engineering questions that is not the founder's DMs.

The founding engineer's real job is to make themselves and the founder both replaceable by a system. If either of you is still the bottleneck at day 90, the company will not scale past 10 people.

What you do not do

You do not refactor. You do not rewrite the founder's prototype "properly." You do not add architecture that anticipates a scale that has not been earned yet. The most expensive mistake I have seen founding engineers make is optimizing for a scale their company might reach in year 3 while the company is still trying to survive month 4.