← Writing · Essay · 7 min · 23 April 2026
Ship first, then optimize. The 2.5-month lesson from Aitopia.
The architecture was clean. The deadlines were met. The trust never came back. A short, specific account of how I spent 2.5 months building the right thing and the wrong product.
I joined Aitopia in November 2025 as Founding Engineer for the mobile product. The Chrome extension had over a million users. The mobile app did not exist. The plan was to ship iOS and Android in months, not years.
I spent the first 2.5 months building the wrong thing.
Not technically wrong. The design system was clean. The architecture was sound. The 16-file modular API layer is something I would build again. But the team wanted a Monica clone, and I was designing a product from scratch. The two were not the same thing, and I did not notice for ten weeks.
What I was doing
Designing every component from scratch in Figma with a friend on the design side. Building a custom design token system. Writing comprehensive architecture documentation. Reverse-engineering an undocumented API. Documenting the AES encryption protocol I had decoded from the Chrome extension.
All of this was real work. Some of it became the foundation that let me ship the rest of the app fast later. None of it was what the team wanted to see in week three.
What the team wanted to see
A working chat screen that looked like Monica. That was it. They had told me the goal on day one. I heard “AI Agent Marketplace mobile app” and built the long version. They meant “the screen I can show our investors that looks like the competitor.”
I showed only the chat screen and the settings screen in every demo for ten weeks. I thought I was being modest. They thought I was stalling.
The break
Late January 2026, the CEO told me directly: we are not going to continue with you. The app does not look like Monica. We want exactly the Monica clone.
I asked: if the UI is what you want, can I deliver only the UI?
He said yes.
I delivered the UI in one and a half days. The CEO was surprised at the speed. I was surprised that I had not done it ten weeks earlier.
What happened next
Three or four days after the UI delivery, I had a working iOS and Android app with auth, chat, streaming, model selection, and the full API integration. 331 commits. 253,488 net lines of code. 586 passing tests. By the timeline they wanted. The architecture I had been building was part of what made it possible to move that fast at the end.
But the trust was gone. Even with a working app, even with every remaining deadline met, the team no longer treated me like a member of it. I left by choice on 12 February 2026.
What I would do differently
On day one, ask: what does success look like in two weeks. What does success look like in four weeks. What is the smallest thing I can show on Friday.
Show something half-finished every week. Hold a single hour-long demo each Friday at the same time. Not for accountability theater. For shared reality.
Treat scope expansion as a milestone-with-money conversation, not a private engineering decision.
And ship before optimizing. Always. Even when you can see the larger system that should be built. Even when you know the throwaway code will hurt later. Trust is the thing you cannot rebuild after a missed expectation, no matter how clean your code is.
The harder lesson
There is a version of this story where I blame the team. They did not provide API documentation. They did not give clear feedback for ten weeks. When they did, it came as a sudden ultimatum, not a conversation. Those things were true.
There is also a version where I do better. The version where I ask “what does success look like” on day one. The version where I show a working chat screen in week one even if the design system is half-finished underneath. That version exists, and it is on me that it did not happen.
The architecture I built does not care which version actually happened. It works the same either way. The relationship cared a lot.
I keep this essay short on purpose. Most ship-first lessons fail not because the lesson is hard to understand, but because nobody actually reads “ship first, then optimize” in week one and changes their behavior. So the only useful version of this lesson is the specific shape of how I got it wrong. Read it once. Ship the next thing on Friday.
Filed under Lessons · Founding engineer · Aitopia
Have a senior engagement starting?
If you want a senior engineer who will define week-two success on day one and ship something half-finished on Friday, that is the shape of work I do.