“It looked beautiful. It broke immediately.”
That’s the line we keep coming back to when talking about our first few months working on Anjin.
We launched fast. Lovable gave us a framework to prototype quickly - clickable UIs, modular flows, and just enough magic to make it feel like a real product. But the moment we leaned on it - when we tried to scale up for real-world usage - it broke.
And honestly? That break was the best thing that could’ve happened.
Prototypes Don’t Scale - But They Teach You Everything
The first cracks showed up where you’d expect: state mismatches, multiplayer conflicts, UI layers that smoothed over real issues. Then things got more interesting - like discovering that admin login data was stored in a cookie. Anyone with a little curiosity (and a browser console) could get in.
Nothing catastrophic happened. But it was a sharp reminder: fast is good, but secure is non-negotiable.
Here’s a taste of what we ran into:
- Conflicts when multiple devs worked on overlapping state
- Frontend assumptions that didn’t hold up with live agent data
- Sensitive access left quietly exposed under the hood
Lovable wasn’t the problem. It did exactly what it was designed to do: help us move quickly. And that speed gave us clarity. It showed us where things failed - and where we needed to rebuild for the long game.
From Breakable to Built-to-Last
After that initial phase, we took a breath and went deeper. We didn’t just patch. We rebuilt - with a sharper lens on security, scalability, and how users actually interact with the product.
The core principles we leaned into:
- Sensitive operations? Server-side, always.
- Roles and permissions? Strictly enforced.
- Agent state? Never assumed, always explicit.
We also built internal tools to support the way we work - things like secure dashboards, execution controls, usage tracking, and safeguards for how agent tokens live and die.
Want the full breakdown of our stack? Happy to share. But we’d rather talk about it directly - because the “how” depends a lot on the “why.”
When Things Break, You Learn What Matters
If we hadn’t built it “wrong” the first time, we wouldn’t have seen what needed to be right.
One of the best parts of working in the open is that your assumptions get tested - fast. Users don’t follow the paths you design. Systems behave in strange ways under stress. And sometimes the best way to understand your product is to watch it not work.
We broke things. We fixed them. And we’re still learning every day.
Side Note: Dev Mode, Branding, and What We Call Things
You might’ve seen the recent news about Lovable and the “Dev Mode” cease and desist from Figma. We’re not involved, but it did spark a conversation internally about naming, culture, and how fast things move in the AI world.
Words travel. So do ideas. And even a simple label can carry weight you didn’t intend. Worth keeping in mind - especially when you’re building in public.
What’s Next for Anjin
- BigQuery is helping us tune product direction - more on that in Inside Anjin #02.
- We’re giving away 200 lifetime licenses - for the curious, the critical, and the chaos-tolerant.
- We're attending monthly AI dinners - real conversations with founders, researchers, and builders. Expect sparks from those to show up in future posts.
- We're sketching something weird - Dinner with AI, a metaphor-meets-experiment imagining a dinner party where each guest is an agent. It’s already getting strange - in the best way.
Final Thought: Hacking the Train Map
One of our team saved £90 by taking a weird train route instead of the direct one.
That’s kind of our approach to building: don’t just take the default path. Explore alternatives. Find the smarter, stranger route. Lovable helped us board the train. But now we’re laying our own track - one that’s designed to hold.
Want to dig into the stack, architecture, or agent behavior?
Join our community to ask questions, share feedback, and be part of the conversation. We’re building in the open - and we’re here for the long haul.
