TL;DR: We had customers willing to pay lots of money to customize our product. We could build the solutions. But we couldn't build them fast enough and didn't want to customize them for a single customer. This is the problem n.codes was built to solve.
The Best Problem to Have
When you hit product-market fit, everything changes overnight.
Your inbound becomes a roar. Customers show up at your door not asking "does this solve my problem?" but "why isn't it solving my problem yet?"
For my last company, this moment was surreal. We'd spent years grinding to get here. The first 18 months post-PMF? The most intense of my life. And honestly, it still is.
The good news: we had real customers with real problems. Fortune 500 companies, willing to spend serious money. We weren't guessing at product-market fit—we were living it.
The bad news: they wanted things we didn't have yet. And they wanted them now.
The Bottleneck Nobody Talks About
Here's what happens after product-market fit:
Your customers—the smart ones, the serious ones—start asking for customizations. Not because our product is broken, but because their problems are specific.
We'd get requests like:
- "We need a custom dashboard that organizes your existing charts for our executive team."
- "Can you export this data in a specific format for our accounting system?"
- "We need bulk actions to archive 1000s of records at once."
The kicker? These weren't complicated. They were just different arrangements of the same building blocks.
And yet, we had to backlog them for months.
Not because the work was hard. But because our engineering bandwidth—even doubled with AI dev tools—couldn't keep up with the volume.
We 10x'ed our throughput. They asked for 15x more. If you do a good job, customers want more.
This is the feature request bottleneck, and every SaaS founder hits it.
The Hidden Problem
Here's the brutal truth nobody tells you:
The backend could already do most of what they requested.
Our APIs had the capability. Our data layer was flexible. The constraint wasn't capability—it was UI.
We were so bottlenecked that even simple requests had to sit in the backlog for quarters. Meanwhile:
- Support got crushed fielding "when will you build this?" questions
- Engineers got burned out context-switching between urgent requests and roadmap work
- We left money on the table (customers would have paid more for faster delivery)
The Realization
One day, it hit me: We were the constraint. Not the product.
We can ship these features. We had smart engineers. We had the leverage to hire more. But even if we 10x'ed again, there would still be a backlog.
The problem wasn't speed. It was scale.
What if we didn't have to be the bottleneck?
What if users could safely and securely generate the features they needed within the app, without waiting for us to prioritize them?
What if instead of "feature request → backlog queue → engineering sprint → deployment," it was "user need → one prompt → instant solution"?
The Vision: Agentic UI
n.codes is that solution.
It's an open-source framework that lets users build their own features with just a prompt in your app. Think of it like having a forward-deployed engineer for every user.
Here's how it works:
- Your app's capability map is generated from your backend APIs and components. The system learns what's possible. But never touches the database. Leverages existing APIs.
- User writes a prompt: "I need a dashboard that shows my top 10 accounts by revenue, with a bulk archive action."
- The agent builds it: Custom UI, styled to match your app, using the capabilities it knows are available.
No arbitrary code execution. No security theater. Just users getting what they need, instantly. All generated features live in a sandbox for that user (or shared with their team), are fully audited, and are permission-aware.
Why This Matters
For users, it's obvious: they don't wait. They get what they ask for.
But for founders and CTOs, the upside is bigger:
- You're no longer the constraint. Your roadmap can focus on core product improvements instead of death-by-a-thousand-customization-requests.
- Your engineers ship more impact per sprint. They're building platforms instead of one-off features.
- You unlock premium tiers naturally. "Custom feature generation" becomes a real product differentiator.
- Your API design matters more. If users can build on top of your APIs, having clean, well-documented APIs becomes a moat.
- Your customers become stakeholders in the product vision. They're not waiting for you to care about their edge case—they're solving it themselves.
The Problem With Most "No-Code" Solutions
Before we get too excited: no-code is a graveyard of false starts.
Most fail because they're either:
- Too constrained: "Build anything" sounds great until you hit the limits of their drag-and-drop builder and need something 5% outside the box.
- Too generic: "Use our no-code tool" assumes you want to learn another tool. What you actually want is to stay in your app.
- Too fragile: One edge case and the whole thing breaks. No one wants fragile, custom-built UIs in production.
n.codes is built for the 90% case: CRUD operations, analytics dashboards, bulk workflows. The bread-and-butter features that comprise most feature requests.
It's not trying to replace engineers. It's trying to replace the backlog.
Why Now?
LLMs finally make this tractable. Not because they're "smart enough to build anything," but because they're good enough at:
- Understanding API specifications
- Reading component libraries
- Following design systems
A year ago, this would have been magic thinking. Today, it's just engineering.
What's Next
I'm building n.codes in public. Today it's an open-source framework. Tomorrow, it could be the standard way users get unstuck waiting for features.
For the Curious
Try the interactive demo
Star the repo on GitHub
Contribute and build in public
This is still early. I'm shipping the foundation. But if you've ever sat in a prioritization meeting and thought, "This feature should take 2 days, why does it take 2 quarters?"—this is built for you.
P.S. If you're building SaaS and you hit the feature request bottleneck, it's not a bad sign. It means you've shipped something people actually want. The question is: will you stay the bottleneck, or will you build systems that scale?