The Founding Engineer Mindset: What I Learned Starting Chimpanzee Solutions
I started Chimpanzee Solutions in March 2025. Seven months later, the technical decisions that feel obvious now would have horrified my senior IC self. Here's what changed.
Done > Perfect
As a senior IC, I optimized for elegance. Reusable components. Abstracted logic. Future-proofing.
As a founder, I optimize for shipping. My rule now: the first version of anything gets copy-pasted code, inline styles, and no tests. If it survives three months, I refactor. Most features don't.
// Then: generic, reusable, abstract
// Now: specific, copy-pasted, shipping tomorrow
The 90/10 Rule of Tech Choice
Senior IC me: "Let's evaluate six solutions, benchmark them, and write a decision doc."
Founder me: "What do I already know that solves the problem in 2 hours?"
The only questions that matter now:
| Question | Purpose |
|---|---|
| Will this scale to 50 customers? | If yes, stop worrying |
| Can I debug this at 2am? | If no, pick something else |
| Does this lock me in irreversibly? | If yes, think twice |
| Will I still like this in 6 months? | Gut check |
| Everything else is noise. |
What I Stopped Caring About
Tech stack purity. We have a React frontend, a Node BFF, and a Python data pipeline. The Python people don't know Node. The Node people don't know Python. Nobody cares because the product works.
Test coverage numbers. We have 0% coverage on prototype features and 80% on payment logic. The ratio roughly matches "how bad would this hurt if broken?"
Preview environments for every PR. We use a single staging branch. On conflict, whoever merges last fixes it. This has caused exactly one issue in 7 months. The time saved pays for it.
What I Started Caring About
The critical path. Every week, I ask: "What's the one thing that kills the business if it breaks?" Then I over-invest in observability for that thing. Everything else gets logging and hope.
Customer-specific config. One client needs overnight batch jobs. Another needs real-time sync. Building for both upfront would have taken 6 weeks. Instead, we built the simplest version, added config flags, and let customers grow into features they actually use.
Database migrations that can run online. Zero-downtime migrations are non-negotiable. ALTER TABLE in production at 2pm on a Tuesday? Fine. Taking the site down for 10 minutes? Not fine.
The Shifts That Surprised Me
| Senior IC | Founder | Why |
|---|---|---|
| "What's the best way?" | "What's the fastest way that doesn't break?" | Customers pay for features, not architecture |
| "I'll write tests first" | "I'll test manually first, automate when it hurts twice" | Most code gets thrown away |
| "This dependency is outdated" | "Does it still work?" | Risk > freshness |
| "Let's document this" | "Will anyone ever read this?" | Most docs are lies after 2 weeks |
The Hire-or-Build Decision
Senior IC: "Build it. We control our destiny."
Founder: "Can I buy it for less than $500/month and not think about it again?"
What we buy: Auth (Clerk), Email (Resend), Monitoring (Sentry), Queue (Upstash). Total: ~$200/month. Worth every penny.
What we build: Anything customer-facing that creates a unique experience. Our secret sauce is proprietary.
The Bottom Line
The founding engineer's job isn't writing perfect code. It's keeping the lights on while moving fast enough to find product-market fit before the money runs out.
I still write type-safe TypeScript. I still use proper git commits. But I also ship on Fridays now. I used to judge that. Now I do it.
Your standards don't disappear. They just learn to queue. The perfect refactor waits until after the customer is happy. And the customer is happy when they get something that works, not when they hear about your elegant architecture.