Ten weeks, one platform, and what happened to my vibe coding along the way.
By Kiran Kodithala · Founder & CEO, N2N Services / LightLeapAI · August 2026
Two weeks ago we launched Meridian, an agent-native platform that lets an institution build the enterprise applications it would otherwise rent from a legacy vendor, from a single plain-language prompt.
Ten weeks earlier, this repo didn't exist.
Two days later, on August 27 — my birthday — we ran a public webinar with a live prompt-to-app demo. My colleague Tom framed the whole thing better than I could have:
"For years, organizations have had to make a choice: buy software that almost does what they need, spend heavily on customizing, or wait months, sometimes years, for someone else to build what they actually want. We believe that is about to change… I don't want you to leave here simply thinking Meridian is impressive. I want you to leave asking yourself one question. What would I build if I finally could?"
— Tom, Meridian webinar, August 27, 2026
I want to tell you what happened in those ten weeks — not the sanitized launch narrative, but the honest one. Because somewhere in there, my vibe coding — the way I've been building with AI for the past year — quietly became something else. I don't have a clean name for it yet. But I know it's different, and I think a lot of people are about to feel the same shift.
The three things that actually evolved weren't features. They were the product vision, the architecture, and what "enterprise-grade" came to mean to us in an AI-native world. Let me tell you the story that way.
I. The vision: from "a better student system" to "a platform that builds platforms"
The first commit lands on June 18, 2026. Its subject line already carries both halves of the strategic bet: a demo of one concrete application, and the foundation of a platform play. On day zero both had to be there or neither would be believable — the application is the wedge, the platform is the actual product.
For the first ten days I still described what we were building as "an AI-native student platform." That was wrong, and I knew it was getting wronger every week. Because what the engine was actually doing — a metadata-driven runtime over a generic two-table store, one physical Postgres database per tenant, four AI surfaces authoring against a governed audit log — had nothing student-shaped about it. A student platform was one of the shapes the engine could take. So could a matter-management system for a law firm. So could a case-management system for a nonprofit. So could a service catalog for an IT department.
By the time we shipped the root Omnify generator at the end of June, the pitch had quietly turned inside out. A prospect would type "I run a small law firm, I need a matter-management system with client billing and time tracking" and — thirty seconds later — there'd be a governed tenant sitting on its own database with the right personas, the right objects, the right roles, and a working sign-in. That is not a student-systems product. That is a platform whose first application happened to be one.
Here's how I know that framing is true and not a slide. Ten weeks in, N2N Services — my own company, the one paying for the servers — is running on Meridian. Our core operational systems all live inside a single n2nservices tenant on the same runtime a prospect gets when they type a prompt into /templates. None of it is student-shaped. All of it is production for us. If Meridian couldn't have run our company, it wouldn't have been a platform. It would have been a student system with pretensions. (More on this in Arc IV.)
On the webinar, I ended up reaching for the analogy I now use for the whole shift.
The iPhone in 2007 wasn't shipped with an ecosystem of applications. It wasn't shipped with an SDK either — that came fourteen months later. What shipped was one operating system, disciplined enough that an ecosystem could be built on it, and then was. Meridian is that. The student platform is the first-party app. The platform underneath is what we're actually selling.
The vision evolution, then, wasn't a pivot. It was the market catching up to what the architecture was already telling us on day ten: we weren't building software for higher ed. We were building the substrate a customer builds their own software on — and higher ed was where we knew the pain best.
II. The architecture: four moves that made "generated from a prompt" real
The architecture didn't arrive as a diagram. It arrived as four convictions that hardened one by one, each one paid for by a specific piece of pain earlier convictions couldn't handle.
Move 1 — Metadata-driven, not code-driven
The single decision that made the rest of the platform possible: the runtime doesn't know what an "employee" or a "student" or a "matter" is. The runtime knows how to interpret a metadata document — objects, fields, relationships, validation rules, policies, automations — against a generic record store. Author the metadata, and the API, the record grid, the CSV importer, the report builder, the semantic search, the audit log, and the row-scoping guard all wake up already understanding the new shape.
The instinct in a normal codebase is to write a Student class and a students table. That instinct is fatal here. If a customer's prompt can invent new objects — and the whole product depends on that — then no object can be blessed by code. The runtime has to be object-agnostic all the way down.
That's what "generated from a prompt" actually costs. It costs you the shortcut of ever writing class Student.
Move 2 — Database-per-tenant, not row-level pretender
The second conviction, and the one I refused to yield on even when it made provisioning harder: every tenant gets its own physical Postgres database. Not a tenant_id column and a hopeful WHERE clause. Not shared tables with row-level security policies we crossed our fingers over. An actual CREATE DATABASE per tenant, an actual physical isolation boundary, an actual database name in the connection string.
This costs us on the ops side — connection pool math is different, migrations are different, provisioning is a real operation instead of an INSERT. It buys us the one thing that is not negotiable when you're going to point a prospect at their own governed tenant: a customer's data cannot leak into another customer's tenant because there is no query the runtime knows how to construct that would even reach it.
The physical boundary is a load-bearing part of the enterprise-grade story. Row-level security is a supplement to it — RLS is still enabled inside each tenant DB — never a substitute.
Move 3 — Live AI with an unconditional deterministic fallback
Four AI surfaces went live on AWS Bedrock in the first two weeks: the AI Builder (the multi-object data-model planner), Omnia (persona-aware conversational writes behind an inline confirm card), the Workflow Builder (plain-language automation lowering), and the AI Rule Generator (natural-language validation-rule authoring). All four are live-by-default when a model ARN is configured.
Every one of them also has a deterministic offline planner that runs on identical inputs and produces a valid-if-simpler result. If the model has a schema-invalid moment, if the region flakes, if a credential rotates mid-call, if the venue's wifi drops during a demo — the surface degrades to the offline planner and the user gets a functioning app anyway. The provenance badge tells them honestly which one they got: "Live · LLAI Agent" versus "Offline planner."
I want to be blunt about why this matters. You cannot demo a live-model product on a hotel's conference wifi without a fallback. Anyone who tells you you can hasn't done it. The AI-native pitch dies the instant the demo dies. So the AI-native pitch has to be built on infrastructure that survives its own AI going away — and that's the thing "enterprise-grade AI" actually means, not the model provider on your slide.
Move 4 — The critic loop is the substrate, not a testing artifact
The fourth conviction is the one I did not see coming, and it changed everything about the pace.
Meridian ships with over a dozen domain critics baked into the repo: a persona critic for every role that actually touches the system, migration architects for the major incumbents, and executive critics that fire last — including one I authored in my own voice, which runs on the eve of every release and asks the only question that matters. Every one of them writes a severity-graded report to disk on every release, cites specific files and lines, and gates handoff on blocker findings.
Alongside them: a hermetic evaluation suite — deterministic, DB-free, model-free assertions of every non-negotiable invariant. Tenant isolation. Field-level RBAC. Honesty gates. Row-scope narrowing. Fabricated-action detection. The eval suite grew roughly 19× along with the surface, and it outpaced the feature line count in growth rate.
None of that is a QA function. That is the substrate that makes AI-agent velocity survivable at all. Without it, a fast AI is just a fast way to ship regressions. With it, you get the velocity and the ability to look a customer in the eye about what the runtime will and won't let happen to their data.
That is the architecture. Four convictions. Everything else is a consequence.
III. What "enterprise-grade" came to mean to us
Here's where I have to be honest, because the term is degraded. "Enterprise-grade" in most vendor material means "we passed a SOC 2 checklist and have a green SLA badge." That's not what I mean. What I mean is the lived-in definition ten weeks of building this thing taught us — the one you arrive at by getting bitten and healing.
Enterprise-grade means isolation is proven, not asserted. We found the kind of tenant-scoping issues that only surface when you're moving at this pace — each closed the day it surfaced, in the record, with the eval that would have caught it added alongside the fix. Not because we're flawless. Because the pace found them, and the discipline was to close them the same day. Honest is more useful than flawless.
Enterprise-grade means every write is audited — even the AI's writes, especially the AI's writes. Every mutation in the system writes a row to an append-only audit table under the tenant, in the same transaction as the write itself, with the actor's real principal, the resource, the before-and-after, and a scrubbed reason. There is no code path that mutates a customer's data without that row. You cannot let AI agents into a customer's system of record without this. It's the ledger that makes the AI accountable instead of just fast.
Enterprise-grade means every AI write pauses on a human. Not a modal — never a modal — an inline confirm card in the surface where the ask was made, showing the exact resolved values, the exact objects touched, and a Confirm or Cancel button. The AI proposes; the human commits. The audit row records both the AI's proposal and the human's confirmation. This is not a UX preference. It is the seam between "an AI that helps me" and "an AI that acts as me." We were unwilling to blur it.
Enterprise-grade means documentation is an artifact of the release, not a task the human eventually gets to. Meridian's repo carries roughly as much Markdown as TypeScript — a ratio close to 0.7:1 doc-to-code. Every architectural decision has an ADR. Every release has dated notes. Every training guide has a page whose contents were fetched back to verify they round-tripped after publish. The reason isn't compliance. The reason is that when the AI is doing the typing, the human's job is to leave a trail the next human can rebuild the mental model from — and that trail has to be produced as the code is produced, not later.
And — the one that ties them all together — enterprise-grade means being willing to reimagine what you're migrating, not just move it. On the webinar I reached for a line that ended up doing more work than I expected:
"Think of Meridian as a mansion you're moving into. Don't try to move a hut into a mansion. Re-imagine your living conditions in the mansion. And then move the furniture you think is worth moving from your hut."
— Meridian webinar, August 27, 2026
The old enterprise-grade instinct is retrofit — take the 1981 data model, paint it with a SaaS URL, keep the seven-character field names, put a chatbot on top. The new one, the one this era makes possible for the first time, is reimagine, then migrate what deserves to come with you. The AI-native platform is what makes the reimagining tractable at all. Ten weeks of directing agents is what taught me to actually believe it.
IV. The dogfood: we shipped it because it was already running our company
Here is the part of the story I was most reluctant to write, because it sounds like a boast and I mean it as a confession. We did not build Meridian for ten weeks and then run a demo on a fake tenant. We built Meridian for eight weeks, and then for the last two weeks we ran N2N Services itself on it. That is why we were willing to launch.
Before Meridian, N2N ran the way most 50-person services firms run. A spreadsheet was the source of truth for HR. ClickUp held the projects and, under duress, doubled as the performance-management tool. HubSpot ran the sales pipeline. Basecamp carried the client communication. A shared drive with a folder called "SOC 2 evidence — DO NOT DELETE" held the compliance trail. The handoff from a signed deal in HubSpot to a delivery team in Basecamp was a Slack message and a hope. Every one of those systems was good enough on its own; the problem was that none of them talked to any of the others, and every quarter someone had to spend three days copy-pasting across the seams so the leadership dashboard could exist at all.
Rather than build a demo tenant to test Meridian, we made the harder bet: use ourselves as the pilot customer. Over the last two weeks before launch, we consolidated the operational core of N2N into a single n2nservices tenant on Meridian — HR, asset inventory, performance cadence, SOC 2 evidence, sales pipeline, and the sales-to-delivery handoff — five workflows that had never previously lived in one system, run out of one governed audit log, under one identity model, with one row-scope guard, with one report builder over the whole surface.
Nothing about the Meridian runtime changed to accommodate any of them. We authored metadata. The engine did the rest. That was the whole point.
The claim I want to make about this, plainly: we did not ship Meridian and hope. We shipped Meridian because we were already using it to run N2N. Every rough edge that would have burned a customer in month one burned us in week nine, in an internal tenant, where we could fix it before it ever reached a paying account. Every workflow gap a first customer would have raised as a support ticket, an N2N staffer raised as a Slack message — often into a service-desk channel that itself runs on Meridian.
There was an upside I did not plan for. The N2N tenant turned into the best product backlog we've ever had. The critic-and-eval loop from Arc II caught the invariant bugs — the tenant-isolation defects, the honesty-gate regressions, the row-scope narrowings. The internal tenant caught the workflow bugs — the ones that only exist when a real person is trying to get a real job done and the seam between two objects is a little bit wrong. The two loops covered different halves of the problem, and neither substituted for the other.
That, to me, is what dogfooding actually means in an AI-native world. It is not a checkbox on a launch-readiness slide. It is the reason the launch demo worked at all, and it is the reason I could stand on a webinar two days later and answer the "what if" question honestly, because I had already lived the answer.
V. The nerve center: if Meridian is the platform that builds any platform, we're required to prove it on our own
I want to close on the commitment that comes out of everything above, because it's the one I'm least willing to soften.
N2N has already shipped real, revenue-generating platforms — Helios (our integration spine) and Polaris (our code-agent + governance surface) — and we have a roadmap of more: Orion, Prism, CVC, and whatever the next customer conversation pulls out of us. Historically, each of those has been its own repo, its own data model, its own admin surface, its own auth story, its own audit path, its own deployment. Every one of them solves a real problem. Every one of them is also, by construction, an island — and every island is a quarterly meeting where somebody has to explain to a customer why the seven products they bought from us feel like seven products.
If our thesis is right — if Meridian really is the platform that builds any platform — then we are required to prove it in the one way that matters: by rebuilding our own platforms on it. Not the customer-facing shells; the whole thing. Objects, workflows, agents, audit, RBAC, reports. Helios becomes a Meridian tenant. Polaris becomes a Meridian tenant. Orion, Prism, and CVC are born as Meridian tenants on day zero. The Meridian runtime becomes the nerve center — the shared metadata substrate, the shared audit log, the shared identity model, the shared agent surface — and the individual products become the shapes that substrate takes for different buyers.
I'm calling this what it is: an enterprise architecture mandate. Every N2N platform we've shipped, and every N2N platform we ship going forward, has to live on Meridian, or the pitch is a lie. The mandate cuts both ways. It disciplines the platform team — Meridian has to be capable enough, general enough, and stable enough that a real product team is willing to bet their roadmap on it. And it disciplines the product teams — no more one-off admin panels, no more bespoke auth, no more private audit tables, no more re-implementing row-scope for the fourth time. Author metadata. Author policies. Author workflows. Ship.
Two things make this feasible right now, that weren't feasible six months ago. The first is the architecture from Arc II — an object-agnostic runtime, database-per-tenant isolation, four AI surfaces with deterministic fallbacks, and a critic-and-eval loop dense enough that we can move a whole product onto the runtime without cross-tenant blowback. The second is the dogfood evidence from Arc IV — N2N Services itself is already running on Meridian, so the "will it hold a real product" question has an honest answer: it's holding one.
The consequence I care about most is the customer's. Today, an institution that buys Helios and Polaris and (soon) Orion is buying three products with three admin surfaces, three audit logs, three role models, and three data pictures that don't quite line up. Tomorrow, an institution that buys any combination of them is buying one governed workspace whose left-hand nav happens to include integration flows, code agents, and whatever else we ship next — with one audit log, one identity, one report builder over everything, and one AI front door that already understands all of it because it's the same runtime underneath.
That is the story I want to be telling on this article's one-year anniversary: not that Meridian shipped, but that Meridian became the substrate every other N2N product is built on. If we get there, we didn't just build a good product. We changed what our company means by "a product." That's the whole point of a platform-that-builds-platforms.
What actually changed in me
The vision, the architecture, and the definition of enterprise-grade all evolved in public — you can read the ADRs. The thing that evolved in private was the mode I was working in. I want to answer the question I opened with — how did my vibe coding evolve? — because I think the honest answer is more useful than the launch story.
One. Vibes are the wrong word for the input, but the right word for the mode. What I actually feed the agents is very specific: an intent, an invariant, and a way I'd know it's wrong. "Add reference-aware search on the record grid — and it must never widen row-scope for a student, and I'll know it's wrong if I open the picker as a student and see a name outside my own row." That's not a vibe. That's a contract. But the mode of authoring the contract — reading the diff by feel, deciding whether it "smells right," pushing back on the agent when the code looks too clever — that part is still vibes. Both are true.
Two. Rules and skills are the leverage, not the code. I spent a serious fraction of these ten weeks writing rules and skills rather than features — a QA skill that exercises every control in the UI and is forbidden from deleting one, a rule that refuses a handoff proven by a proxy test instead of the real path, a rule that gates a release on its training guide actually being published, and a last-in-line skill that asks the only question that matters: would a real user use this? Each rule cost me an afternoon and saved me the same afternoon every subsequent day. The compound interest on well-written agent rules is the highest ROI I've ever seen in software.
Three. The unit of work stopped being a keystroke and became a decision. I did not type most of the code in this repo. I designed the funnels, insisted on the invariants, argued with agents about whether their proposed diffs actually honored those invariants, and stayed in the loop long enough to notice when they didn't. The days that felt fastest were the days I made the fewest keystrokes and the most decisions. If you want the numbers on that ratio, I published them at 180 days: thousands of accepted agent diffs against a two-digit count of tab completions.
Four. The paper trail kept up with the code — because we made it agent-work, not human-work. Every ADR is published. Every release has its own dated notes. Every training guide is fetched-back-verified after publish. If somebody joins the team tomorrow and reads only the docs, they can rebuild the mental model. That was not free. It was a specific choice to make documentation an agent-produced artifact of the release itself, not a separate task the human eventually gets to.
Five — the one I didn't expect. I got faster by getting more skeptical. The most consequential bug I found in the whole ten weeks — a bug in which the system narrated an action it had not actually taken — was caught by me reading a reply and thinking the words don't match the tools I saw fire on the trace. I could not have caught that as a code reviewer of a human's PR. It lives in the conversation, not the diff. The skill you get from doing this for ten weeks is a sixth sense for the moment an AI is confidently narrating something that didn't happen.
That skill is portable. That skill is the thing.
The arc, if you want to read it in order: 100 days was about capacity, 150 days about rigor, 180 days about operating, and this one — call it 210 days, though I've stopped counting — is about what the mode itself became. If the shorter version of that shift interests you, I wrote about it for the Forbes Technology Council earlier this month.
What's next
Meridian is live at dev.lightleap.ai. Guests can build a sandbox from a single prompt. Owners can claim it, invite co-owners, and use it as their actual system of record. Every object is exposable as a documented API. Data agents run on their own worker. Operations dry-run, then confirm.
Internally, the next chapter is already written: Helios, Polaris, Orion, Prism, CVC, and everything after them get rebuilt on Meridian. One runtime, one audit log, one identity, one AI front door — because we're not going to pitch a platform-that-builds-platforms and then keep shipping our own products off it.
Ten weeks ago none of this existed. Ten weeks ago I existed, but the mode I was working in didn't.
If you're reading this and you're still typing every line by hand, I'd ask one question: is it because you love the craft, or because nobody has yet shown you how to direct the code instead of type it? Those are different answers. The first one I respect. The second one is worth an afternoon of your time to fix.
We closed the webinar with something I meant every word of:
"What you will truly realize is that you will actually be, for the first time in our life, truly free of being held hostage by somebody else's timeline, somebody else's roadmap, somebody else's COBOL code, somebody else's Fortran code, somebody else's forms — by saying, this is my software, this is my campus, this is my institution. I will own our future. I will own our destiny."
— Meridian webinar close, August 27, 2026
Come see Meridian — tell us what you'd build if the platform was already built.
— Kiran
Kiran Kodithala is the Founder & CEO of N2N Services and LightLeapAI. Meridian is real; every claim in this article is grounded in the repo's actual git history, ADRs, and release notes.
Fifteen years of building. The leap is now.
Talk to N2N about partnerships, press, or careers — or visit LightLeapAI to see what we built.