Michelle Lim was the founding software engineer at Warp (originally called Denver), an AI-powered terminal startup, and is now the founder of Flint, which builds autonomous, self-updating websites using AI. Her path from intern at Meta, Slack, and Robinhood to founding engineer and now founder illustrates how early-stage startup experience compounds into founder-level skills.
How Michelle got into software engineering
Started in college through an entrepreneurship club, where she noticed that teams with programmers moved faster, so she taught herself to code.
Took her first CS class in spring of freshman year — late compared to peers — and fell in love with debugging, which reminded her of medical diagnosis (she had originally planned to become a doctor in Singapore).
The pattern-tracing aspect of debugging — connecting symptoms back to root causes in code — mirrored differential diagnosis in medicine, and this became her favorite part of software engineering.
Internship trajectory: Meta → Slack → Robinhood
Meta (Facebook University): A pre-AI program for underrepresented students in CS. Two-week bootcamp building Android apps in Java daily, then team-based project building a receipt-splitting app using OCR and Bluetooth. Won best app in the program and met Mark Zuckerberg.
Slack (via Kleiner Perkins fellowship): Joined when Slack had ~1,200 employees. Everyone had high product ownership and used the product daily. Michelle proposed features directly in Slack channels and got responses from CEO Stewart Butterfield — one accepted (frequently used emoji reactions), one rejected (scheduling messages, which Slack later built).
Robinhood: Worked on the news tab at a ~300-person company, deciding what news to show millions of users. Used a Robinhood version of Kafka for data pipelines, parsed feeds from partners like Bloomberg, tagged content, and balanced relevance ranking with avoiding bias in ML training data. This is where she found her sweet spot: combining deep CS problems with product decisions.
Each internship was roughly an order of magnitude smaller than the last (12,000 → 1,200 → 300), and each time she felt more ownership and clearer line of sight between her work and user impact. This pattern led her to want to join a two-person company next.
Joining Warp as engineer #1
When Michelle joined, Warp had no code written — just mocks and a founder (Zach, former principal engineer at Google and CTO at Time magazine). The product vision was a modern terminal with: anchored input at the bottom, block-based grouping of terminal I/O, collaboration features (multiple avatars), and shared environment variables.
She had safer options: companies with $10M ARR growing fast, and a return offer from Robinhood. She chose Warp because: (1) she kept thinking about the product daily, (2) she saw real business impact potential from better terminal tooling (Slack outages in 2018 showed how much enterprises relied on CLI tools), (3) making terminals more accessible could lower barriers to computer science education, and (4) the rare window to be first engineer on a compelling idea.
She also valued the chance to work directly with a principal Google engineer — essentially a “Zack University” for leveling up quickly.
Negotiating equity as a first hire
Warp presented three offer options in a spreadsheet: increasing salary with decreasing equity. Michelle negotiated hard for maximum equity, willing to accept very low cash compensation.
Her negotiation strategy was atypical: she was transparent about wanting to join and being bought in, rather than creating artificial competition. She argues this works for early-stage startups where founders care deeply about having committed team members, unlike faceless corporate negotiations.
She now uses a similar spreadsheet at Flint that calculates equity value including tax, dilution at each stage, and expected value based on different outcomes and their probabilities.
Asking founders for references
Michelle asked Zach for references from people he had managed before, specifically junior engineers. She recommends this to everyone: at a startup you can’t switch teams or leave a manager easily, so you need to know what working with them is actually like.
Key questions to ask: Would you work with this person again? (Looking for “hell yes,” not just “yes.”) What were career conversations like? How did promotions work? What was it like during tough times?
Zach passed: two engineers he mentored as interns/new grads quickly became director of engineering at Google Sheets. At Warp, he consistently bet on young talent, giving new grads tech lead roles on critical projects.
Even if not for evaluation, reference checks can yield advice on how to work best with the manager (e.g., insisting on weekly 1:1s, proactively asking for feedback in specific ways).
Warp’s tech stack evolution
Started in TypeScript, then scrapped the entire repository 2–3 months in and rewrote everything in Rust.
Reasons: (1) performance — JavaScript couldn’t handle drawing thousands of rectangles (terminal output) with smooth scrolling, (2) speed of development — less time spent stress-testing, (3) marketing — the developer community strongly preferred high-performance terminals built in low-level languages, and Rust’s passionate growing community meant better distribution.
The team read the O’Reilly Rust book daily and iteratively improved their code. Michelle paired daily with Nathan Sobo (creator of Atom editor, founder of Zed), learning Rust idioms and IDE ergonomics.
Product-first vs. code-first engineering
Michelle distinguishes between product-first engineers (motivated by user problems, see technology as a means to user impact) and code-first engineers (excited about performance, libraries, elegance, pushing technical limits — often mapping to infrastructure work).
She argues this is a more useful split than frontend/backend, because it reflects mental models. At Robinhood, she was initially placed in infrastructure (migrating from Amazon Athena to Presto, writing SQL) and felt unmotivated because she couldn’t see user impact. Only when she advocated to join the news tab team did she realize she loved solving user problems using whatever tools were necessary.
At Warp, she hired product engineers by looking for candidates who had worked at product-first companies (Figma, Notion, Slack) and by including a product round in interviews: asking candidates what they’d change about the terminal or a favorite app, evaluating whether they had opinions, spoke from the user’s perspective, and could sequence work around user-visible milestones rather than invisible performance improvements.
Founding engineer vs. product engineer
These are different axes: you can be a founding product engineer, a founding infrastructure engineer, a later-stage product engineer, etc.
Michelle defines a founding engineer as someone in the first ~5 hires within the first few months of a company.
She cautions that many startups now use “product engineer” as a synonym for frontend-only engineering, so candidates should read job descriptions carefully.
Avoiding getting burned in founder exits
A common fear among engineers joining AI startups: the founder gets acquihired by a big company, receives all the monetary benefit, and the team is left with nothing.
Michelle’s friend decided to join OpenAI instead of a startup because of this risk.
Mitigation strategies: (1) do reference checks to assess founder character — are they generous with their people? (2) prefer founders who were founding engineers themselves, because they have lived experience of the risk early employees take and are more likely to offer secondaries, tender offers, and bring the team along in acquisitions, (3) directly ask in interviews: if you raise a new round and take secondaries, will early employees have the opportunity? If the company is acquired, would you bring the team? The quality of the answer matters less than whether they’ve thought about it before.
At Flint, Michelle offers secondaries and tender offers to early employees because she understands the sacrifice from personal experience.
How Flint uses AI tools
AI coding tools are essentially a requirement at Flint for productivity. They use Claude Code inside Cursor (and one engineer uses it inside Vim).
Michelle sees AI as a universal pair programmer — everyone now has a rubber duck available daily.
Flint: autonomous websites
Flint builds websites that are agentic — they perceive their environment, make decisions, and act autonomously.
Phase 1: Respond to the market in real-time. If a competitor launches overnight, your website automatically generates a comparison page, optimizes for conversions, and tracks product differences daily. This replaces what would take five agencies three months. The system hooks into sales calls (e.g., Gong) to identify missing solution pages.
Phase 2: Real-time morphing of pages based on who is visiting. A healthcare executive sees healthcare case studies and compliance content; an AI agent visiting gets content in MCP/tool calls/JSON/Markdown instead of HTML.
The architecture mirrors autonomous vehicles: perception system (data streams from market, sales calls, competitors) → decision-making system (what to build) → control system (implementing pages) → feedback loop (measuring performance in the market).
By putting all tools in one entity, Flint closes the feedback loop that previously required five separate agencies passing information between specialties.
They’re also building an agent-to-agent protocol for the “agentic web” — where AI agents talk to each other to establish credibility and help close deals, rather than users going to Google for links.
Creating on-brand landing pages is a research-level problem: brand consistency down to the pixel matters, especially for SaaS companies selling to Fortune 500 clients. Flint has developed the capability to generate pages that look as if the customer built them themselves. They work with Cognition on events pages and comparison pages (Windsurf vs. Cursor).
Advice for aspiring founding engineers
Stand out by building AI products: Few people have built products using LLMs. Spending weekends building anything that uses completion APIs — even a simple LLM-based search engine — helps you stand out.
Pick the right founder: Do reference checks, assess character, look for founders who were founding engineers themselves.
Volunteer for the unsexy work nobody wants to do: At Warp, Michelle was the face of the company on Hacker News (wrote blog posts, answered every question), created the company Twitter, started a YouTube channel before developer tool companies did YouTube, started Discord, filed every feedback item, managed GitHub — all while maintaining her core engineering work.
Do it excellently: The point isn’t just to do the work, but to prove to the founder that any job you’re given will be done excellently. This is how you earn more responsibility.
This compounds into leadership: Because Michelle did all this, at age 22 she was asked to become head of growth, reporting to the board. Later she led enterprise sales because she recognized that security questionnaires from companies using Warp were actually an enterprise sales opportunity — a hot potato that had been passed around multiple quarters.
This prepares you for founding: The job of a founder and manager is to take the things no one wants to do so everyone else can stay in their zone of genius.
Rapid fire
Favorite programming language: Rust — satisfaction from passing the borrow checker.
Flint’s stack: TypeScript (building websites in the language of the web), though Michelle expects Rust to find its way in.
Movie recommendation:Weapons — appears to be a horror movie but has comedic moments and a nonlinear narrative where each chapter shows a different character’s perspective, almost changing the genre each time, with each character mapping to a different horror movie trope.
