From Idea to Product in 26 Days: The Neonloops Story
A month ago, Neonloops didn’t exist. Today it’s a live platform where people build, test, and deploy AI agent workflows with a visual canvas. Published SDKs on npm and PyPI. Stripe billing. Security audits passed. Real users.
This is the story of how it got there.
The spark
I was building AI agents for other projects and kept running into the same problem: chaining multiple LLM calls together was messy. You’d write a script, hard-code the flow, test it manually, break it, rewrite it. Every project started from scratch.
I wanted something visual. Drag a node, connect it to another, hit run, watch it execute. Like a circuit board for AI. I searched for existing tools — most were either too enterprise, too locked-in to one provider, or too early-stage to actually use.
So I opened my terminal on March 3rd and started building.
Proof of concept (Day 1–3)
The first version was ugly and it did almost nothing. A Next.js app with React Flow, a handful of nodes, and a basic execution engine that could call OpenAI and pass the output to the next node.
But even that rough prototype validated the core idea. When I connected three nodes — a prompt, a transformer, and an output — and watched them execute in sequence with real streaming responses, something clicked. This was useful. Not “cool demo” useful. Actually useful.
By day 3, I had multi-provider support. OpenAI, Anthropic, Google, Mistral, Meta — all working through a single node type. You pick your provider, pick your model, write your prompt. The workflow doesn’t care which LLM powers it. That decision — vendor independence from day one — shaped everything that followed.
It needs a name
The project started as “AgentKit Neo.” Terrible name. On day 4, I was staring at the canvas with its colorful node connections and dark UI, and “Neonloops” came to mind. Loops because workflows loop. Neon because… look at the UI. It fits.
Naming matters more than developers think. The moment it had a real name, it felt like a real product.
From prototype to platform (Week 1–2)
This is where it gets interesting. The prototype proved the idea, but a prototype isn’t a product. The gap between them is enormous — auth, persistence, billing, error handling, security, documentation, edge cases that only show up when real people use real software.
Authentication came first. Google OAuth through Supabase. I needed users to save their workflows, and saving needs accounts.
Persistence was a deliberate choice. I built dual-database support — SQLite for local development, PostgreSQL (Supabase) for production — using Drizzle ORM with dialect-aware schemas. Over-engineered for a side project? Maybe. But I’ve been burned before by database decisions that are painful to change later.
The execution engine grew fast. What started as “call one LLM, pass to the next” became a proper workflow runtime. Conditional branching (if/else nodes), loops (while nodes), data transformation, state management between nodes, human approval gates. Each node type brought its own challenges. The While node was particularly tricky — you need loop detection and max-iteration limits, or someone’s workflow runs forever and your server bill explodes.
Streaming was non-negotiable. Nobody wants to stare at a spinner while an AI thinks. Server-Sent Events let users watch each node execute in real-time, token by token. It made the whole experience feel alive.
The SDK question
Around day 8, I faced a decision that would define Neonloops’s positioning: should this be a no-code tool, or a developer platform?
I chose both. The visual canvas for building and testing. Published SDKs for deploying.
The idea: you build your workflow visually, test it in the preview panel, then deploy it with three lines of code:
import { Neonloops } from '@neonloops/sdk';
const client = new Neonloops({ apiKey: 'your-key' });
const result = await client.workflows.run('workflow-id', {
input: 'Analyze this customer email'
});TypeScript and Python SDKs, published to npm and PyPI. This was the moment Neonloops stopped being a toy and started being infrastructure.
The “boring” phase that matters most
Week 3 was the least exciting and most important phase.
Security audit. I found 18 vulnerabilities in my own code and fixed all of them. SSRF protection on webhook endpoints. Payload signing. Input validation on every API route. AES-256-GCM encryption for stored API keys. Rate limiting per minute and per month, tiered by subscription plan.
Workflow versioning. Users need to pin a version when they deploy. They need to roll back when something breaks. Draft/publish lifecycle so you can iterate without breaking production. This is the kind of feature that’s invisible when it works and catastrophic when it’s missing.
API documentation. An interactive docs page where you can see every endpoint, every parameter, every response shape. Nobody reads docs until they need them, and then they need them desperately.
None of this is flashy. None of it makes a good demo. But it’s the difference between a weekend project and software people can actually depend on.
Making it feel right (Week 4)
The last phase was polish. And I don’t mean “add a gradient.” I mean the hundred small things that make software feel like someone cared.
Card hover animations that lift slightly. Node selection rings that pulse. Save indicators that confirm your work is safe. A draggable inspection panel so you can peek inside any node’s execution. Button press feedback that feels tactile.
I also did a full React refactoring pass. Extracted the config panel into 13 focused modules. Added error boundaries so one broken panel doesn’t crash the whole app. Memoized the canvas rendering. Replaced array index keys with stable IDs. The kind of cleanup that users never see but developers feel in the stability of the app.
Five workflow templates so new users don’t start from a blank canvas. Cookie consent for GDPR. Password reset flow. Mobile responsive landing page.
Then I wrote the audit reports, documented everything, and shipped.
What I used
Just two tools, really. Claude Code in the terminal and VS Code as my editor. Claude wrote most of the implementation. I decided what to build, how to structure it, and whether the output was good enough.
This is the workflow that works for me now: I think in architecture, Claude thinks in code, and I validate the result against a decade of experience building production software. When it writes something wrong — and it does — I catch it because I’ve seen that pattern fail before.
What I’d do differently
Start with the SDK, not the canvas. The visual builder is the sexy part, but the SDK is where the value is. If I started with the SDK and API, I would’ve validated demand faster.
Ship the landing page earlier. I spent the first week building features and the second week building the marketing page. Should’ve been the other way around.
Less node types initially. I shipped 12 node types. Users probably need 5 to start. The rest could’ve waited.
What this means
I’m not special. I’m a software engineer with 10 years of experience who happened to find the right tool at the right time. Claude Code didn’t make me smarter — it made my experience count for more.
The thing that took 26 days would’ve taken me 6 months a year ago. And the quality is the same, maybe better, because I had more time to think about architecture and less time fighting syntax.
Neonloops is live at neonloops.com. It’s a real product that solves a real problem. And I built it alone, in under a month, while working a full-time job.
That still doesn’t feel normal to say out loud.