I said, “Stay tuned.” So here’s what happened next.
In June, I wrote about deciding to rebuild the CYBE^R® Portal at the request of my leadership. No engineers, no handoffs, just me and a lot of being comfortable while uncomfortable. I ended that piece by saying we were close and that the backend was being restructured at the same time.
That was true. What I didn’t say, because I didn’t know it yet, was how far we were going to take it.
We’re much further along now than I ever expected to be.
Finishing the frontend was its own thing. I wrote about that part: the design system, the shared components, changes that now land everywhere at once instead of trickling through individual pages. That part is done, and it works the way I imagined it. At the time, that milestone felt like the whole mountain.
Then our founder, AJ, and I turned our attention to the backend.
This is where I have to be honest again, the same way I was in June. I am not a backend developer, any more than I was a frontend developer six months ago. What I am is someone who understands what the portal is supposed to do at a fundamental level. AJ understands the systems underneath it. Together, we did what the first piece described doing on the frontend, except now we were doing it in the layer that runs the whole thing. And I will say this: the backend was mostly an AJ thing. There were pieces I wired into the frontend and things I added here and there, but the heavy lifting underneath was our founder’s vision.
We added roughly 25,000 more lines since the frontend was complete. That’s not a typo. That’s the backend being rebuilt rather than patched, plugging gaps that had existed since the original build, restructuring the logic, and wiring in capabilities the portal never had before.
I’m going to tell you what those capabilities are. But first, I need to show you what the full thing looks like in numbers, because until I ran them myself, I didn’t appreciate what we had built.
We measured the portal again on August 5th. Same ask as before: a line count across all three repositories, frontend, API, and database. Same rule too, excluding minified bundles, vendor code, and anything that would artificially inflate the number. I wanted the real thing.
One thing I want to be upfront about. These numbers are approximate, and if anything, they run low, because I can only count what I can actually see. There are whole systems I can’t fully reach into, like the rails we built for Zenith Intelligence™ and Zenith Agents™, the envelope system, and the various tools on the DELVEin side of the portal. So what follows is only what I could count, not everything that’s actually there.
Here’s what came back.
The frontend came in at 63,205 lines across 79 files, covering the pages, shared components, and the design system. The API is roughly 29,900 lines of business logic, authentication, integrations, and report generation. The database is roughly 29,200 lines of schema, migrations, functions, and tooling. That puts the application code total at approximately 122,300 lines.
We also counted the architecture contracts again, the machine-readable module contracts that describe how each part of the system relates to every other part. This is where the number moved the most. In July, we had roughly 32,200 lines of it, and today we’re at roughly 77,500. That isn’t because the system got twice as complicated in three weeks, but because we finally finished the discipline. Every module now carries one of these contracts, not just the newest ones. Most teams never start this kind of work, and we saw it all the way through.
That brings the total footprint to approximately 199,700 lines of code and contracts.
I’m a multimedia specialist who has spent twenty-plus years in design, and I have never in my life produced 199,700 lines of anything.
The number gets more interesting when you look at it from the other direction.
Lines of code are a blunt proxy for effort, so I want to be careful here. These are directional ranges, not precise figures, but here’s the range I get when I ask AI to research our performance.
A traditional team would look something like two frontend developers, two backend developers, a designer, and a part-time PM and QA. Building what the portal is today would have needed roughly 9,500 to 14,500 engineering hours. At agency rates, or the fully loaded cost of carrying that team, you’re looking somewhere between $1.2M and $1.8M, and eighteen to twenty-two months of calendar time to get there.
That’s the denominator, and it rose from where it was in July for the same reason the application code did: we kept building. It didn’t move because of the architecture contracts, since a traditional team was never going to write those in the first place.
I’m not going to put the exact numerator in this piece, because the point isn’t the multiple. The point is that the gap between what this would have cost and what it did cost is large enough to change how I think about what’s possible for a team our size. The savings don’t just sit in a bank account; they compound every time we ship the next thing.
I’ve been describing the portal in terms of what it looks like from a coding perspective. Let me tell you what it does.
The original CYBE^R® Portal was built on intelligence, but it served that intelligence in snapshots. You pulled a report, you read it, maybe printed it, and moved on. Field Marketing Enablement® was there too, but half-baked, letting you create an event, pick local CISOs, generate a Battlecard, and manually update their attendance status. That was the whole loop.
What exists now is a fundamentally different product, fully built and fully closed.
CYBE^R® Portal 2.0 anchors everything in the site itself, so the intelligence follows you. Executive profiles surface on the Geo View, in the event calendar, across every Field Marketing Enablement® page, and even when those executives are speakers at a conference or event in the Event Calendar. Wherever you are working, the intelligence is right there with you.
Planning through Field Marketing Enablement® is fully baked in. Pick a date and a location, and the portal surfaces the cybersecurity conferences happening in that same region that month, so scheduling becomes an informed decision instead of a guess. CISO targeting and venue selection both work by geography, and budget tracking has become a huge part of the new Field Marketing Enablement® module.
And then there’s the piece people kept asking for: hosted event landing pages. The portal now hosts a page for your event that you can share with your invitees, so they get the details, they sign up, and every acceptance loops straight back into Field Marketing Enablement®. The invite, the RSVP, and the tracking all live in one place.
Intelligent Sales Account Plans (ISAPs) and Battlecards are live inside the portal, powered by Zenith Intelligence™ and Zenith Agents™. This is not live AI scraping five sources off the web and returning the same results it gave to your competitor this morning. Zenith draws on OVER 1.4 billion tokens and growing of curated intelligence, every piece of it researched and verified by our OS-INT team before it ever reaches a mode. Zenith Agents™ then layer that research onto the AI at the moment of generation. All of it is sourced rather than guessed. Both are tied to specific executives and events. The Battlecard gives a rep or co-sponsor everything they need to know about an executive before they walk into a meeting or event. The full ISAP goes deeper, layering in an organizational overview, budget context, tech stack, stakeholder map, executive archetype analysis, and key messaging. It’s everything a sales professional needs before a first conversation, corporate meeting, or presentation, and even marketing can generate the report for them.
First invite to closed deal, all in one place, and that is the difference between looking at intelligence and operating on it. This is not the finish line, either. We built the CYBE^R® Portal 2.0 to move at the speed of the people using it, so tell us what you need, and if the idea is sound, we build it. Not next quarter or next year, our process will react in real time, not on some enormous delay.
I care about this part, maybe more than is strictly professional.
The old portal looked like what it was, a developer-built portal with tables assembled by capable people executing on design elements handed to them. It was definitely functional, but it wasn’t the product of someone who started from “how does this feel to someone seeing it for the first time?”
What exists now starts from exactly that question. One design system and a token-based approach, where a single change propagates everywhere at once rather than being chased across individual pages. Every interaction state I wanted to feel natural actually feels natural, because I was the one making the call in the moment, not describing it to someone else across a handoff and hoping it would land.
Clients will see the difference before they read a single word on the screen, because the image appears before the language does. That’s what I’ve been working toward.
I wrote in the first piece that I expected to feel like a fraud the entire time. What I mostly felt, instead, was that this is the interesting part, because the work that matters tends to live just past “I don’t know if I can do this.”
That’s still true. What I’d add now is that the scope of what’s possible changes when the cost structure changes. We didn’t set out to write two hundred thousand lines of anything. We set out to fix something that needed fixing, and then we kept going, and the next thing and the thing after that became achievable the same way the first thing had.
That’s the compounding I mentioned earlier, and it isn’t just financial. It’s the accumulation of believing the next thing is also doable.
We’re not done, and there’s already a next thing. But what exists today is EXACTLY the product I would have handed a client if someone had hired me to design and build it. I’ve completed plenty of work over twenty-plus years and similar UI projects. But, this is the first time the finished UI is 100% what I pictured when I started. In the first article, I wrote about the trade-offs, the compromises, the small changes that pile up until the result is close to your vision but never quite it. This time, there was none of that drift. What I saw in my head is what shipped.
And you don’t have to take my word for any of it. The CYBE^R® Portal 2.0 is live right now, today. It isn’t a demo, it isn’t a roadmap, and it isn’t “coming soon.” Go see what a designer and a founder built mostly themselves with some help from dev: delvein.com
Lee West, Head of Creative @ DELVEin