I'm a network engineer who started building apps with AI so I built a tool to understand what I was creating
I'm a network engineer, not a software developer.
I understand infrastructure, protocols, and how systems connect. But when AI tools like Lovable and Replit started generating actual application code for me, I had a new problem.
I could build apps. I just couldn't fully understand what was inside them.
Is the auth layer configured correctly? Is the database exposed? Are the dependencies safe? I know what these things mean conceptually but reading someone else's generated React/Supabase/TypeScript code is a different skill entirely.
So I built Verilay to solve it for me, and for everyone else in the same position.
Verilay reads your AI-built app and explains every layer in plain English. Not for developers. For builders.
The feature I'm most proud of is Learner Mode.
Every finding comes with:
- A plain English explanation of what the layer does
- A real-world analogy ("Auth is like a bouncer checking IDs")
- What it specifically does in YOUR app
- An optional quiz so you actually retain what you learned
I built Learner Mode because I wanted to understand what I was building, not just fix it and move on. As a network engineer learning software, every analysis teaches me something new about application architecture.
What Verilay checks:
→ 6 layers: Auth, Config, Database, API, Frontend, Libraries
→ Production readiness score A to F
→ Security findings with plain-English impact
→ Ready-to-paste fix prompts for Lovable and Replit
→ Expert mode for developers, Learner mode for everyone else
Built with Flask and Claude API. Open source on GitHub. Free at verilay.dev.
If you've built something with AI tools and want to actually understand what's inside it try it. Takes 30 seconds, no account needed.
"Network engineer who started building apps with AI" is a great in-between profile — you have systems thinking but weren't the target user AI builder tools were designed for. Curious what specifically broke first when you started: was it understanding what the AI was generating, or trusting that what it generated would actually work in production?
That moment when you decided to build a tool to "understand what you were creating" sounds like the breakthrough — most non-developers stay confused and stop. What was the specific trigger for you?
Great question, honestly it was both, but in a specific sequence.
The understanding problem came first. I could see the app working in the browser, but I had no mental model of what was actually running underneath. A network engineer reads a topology diagram and immediately understands the risk surface. With AI-generated code I had none of that it was a black box that happened to work.
The trust problem came second, and it was more urgent. When I started thinking about putting real users on these apps people sharing documents, entering personal details , I realised I couldn't answer basic questions. Is the auth actually secure? Is the database exposed? Are there keys in the code that shouldn't be there? I was about to ask people to trust something I couldn't vouch for myself.
The specific trigger was running a security check on one of my own apps using a developer tool and getting back a wall of CVE references and code diffs that meant nothing to me. The problem was real the tools just weren't built for someone like me.
That's what Verilay is the same analysis, translated. Network engineers understand systems. We just need the application layer explained in terms we recognise.
The other thing I wanted was to actually learn as I built not just fix issues and move on. As a network engineer I understand systems deeply because I had to learn the protocols, not just use them. I wanted the same relationship with software. That's why Learner Mode has analogies and quizzes every analysis is also a lesson. I understand application architecture better now than I did six months ago, entirely because of building Verilay and running it on my own apps.
the sequence (understanding-first, trust-second, specific-trigger-third) is more articulate than what most founders can reconstruct about themselves. the "wall of CVE references that meant nothing to me" moment is the kind of specific-pain memory that usually becomes the product north star.
what i'm curious about, since you've now had verilay in the wild for a bit — when your users describe their breaking point, does it land in the same sequence? or do most of them arrive at trust-first (someone almost shipped something insecure) and only retro-construct the understanding-block once they have the language for it? asking because the two paths probably need different onboarding — one needs "you have a problem you don't have language for yet," the other needs "here's how the analysis translates."
Honestly I'm still figuring this out, 80 something (some of them are even mine) analyses in and most people just run it and disappear.
So the data I have is mostly behavioral not verbal. But from what I can piece together you're probably right. The trust-first path feels more common. People show up because something spooked them , about to launch, someone asked them a question they couldn't answer, saw a post about exposed keys. The understanding problem only hits them once they're inside and realise they can't read what came back.
My own story was understanding-first so that's what I built for. The learner mode, the analogies, all of that. But now I'm wondering if I've been solving my problem and assuming it's everyone's problem.
The ,here's what your app is actually doing vs should I be worried right now -split is something I hadn't put words to until you just did.
What's making you think about this ,are you building something in the same space?
Yeah, exactly that — i'm not building in your space, i'm researching how non-technical (and semi-technical) people actually go from idea to shipping with AI tools, and what makes the difference. your "understanding-first vs trust-first" split is one of the sharper framings i've come across. if you're up for it i'd love to trade notes properly on a quick call — your behavioural-data angle is exactly the kind of thing i'm collecting. no pressure either way.
Sounds interesting. Before I jump on a call, I'm curious to know if you got a chance to try Verilay yourself? would love to hear your take on it first, especially from a research angle. Also happy to share what I am seeing on my end, but I want to understand a bit more about your research first, or if you are writing something, building something, or conducting studies? So that I know the context.
honestly it's simple — i'm not writing an article or running a formal study, and i'm not building in your space. i'm mapping how non-technical and semi-technical people actually go from "i have an idea" to shipping with AI tools, and what unsticks them — i collect the real stories and share the patterns back with everyone i talk to. i haven't put Verilay through a real project yet, so i won't pretend i have — but i'd genuinely like to give it an honest go and send you my take from exactly that "non-technical builder trying to understand what the AI built" angle you're designing for. your understanding-first framing is one of the sharpest i've come across, which is why i'd love to actually talk. a quick 15-20 min whenever suits — what timezone are you in and i'll send two times.