The Zerops Challenge is simple on paper: 48 hours, build something, deploy it on Zerops, submit. What actually happens in those 48 hours is less simple. This is the honest version of mine — what I built, how I actually used AI while building it, and the three specific ways production said no before it said yes.
What I actually built
DevFlow takes a public GitHub repository URL and turns it into something you can actually explore instead of manually digging through. Paste a repo, and it clones it, figures out the languages, frameworks, dependencies, folder structure, and API routes, and turns all of that into a knowledge graph you can query — including asking it plain-English questions about the codebase, grounded in what it actually found, not just a model's general guess about what a typical repo looks like.
The idea came from a problem I actually have: joining an unfamiliar codebase always means the same slow ritual — README, package.json, folder structure, entry point, routes, services, repeat until it clicks. DevFlow is my attempt at compressing that.
The pipeline:
GitHub repo URL
↓
Analysis job queued
↓
Worker clones + inspects the repo
↓
Extract languages, frameworks, dependencies, API surface
↓
Project facts into a FalkorDB knowledge graph
↓
Explorable report + "Ask DevFlow" Q&A
Three services, deployed on Zerops: the frontend, the API, and a worker that pulls jobs off a queue and does the actual repo analysis in the background — so a big repo doesn't hang an HTTP request while it clones and inspects.
Why I didn't just throw the repo at an LLM
The lazy version of this idea is: clone repo, dump the files into a prompt, ask an LLM to explain it. I didn't want that, for one concrete reason — if you ask an LLM to "explain this architecture" with no grounding, you can't tell if the answer reflects the actual repo or the model's general assumptions about what repos like this usually look like.
So the graph comes first. Facts get extracted deterministically — no LLM involved in deciding "this is a monorepo" or "this exposes a REST API" — and only once those facts exist does the AI layer get to answer questions, using the graph as its source of truth instead of its own memory.
How I actually used AI Studio, honestly
I used Google AI Studio during the build, mostly for prototyping speed. I want to be specific about what that means, because "I used AI" can mean wildly different things, and the Zerops Challenge rules require disclosing this properly anyway — I'd rather over-explain than have it look vague.
I didn't ask it to build the app. I broke the project into individual pieces:
- a specific analysis step,
- a specific worker task,
- a specific piece of the graph pipeline
and had AI Studio implement one bounded piece at a time. Every piece got checked against three things before I moved on:
- did it build,
- did the tests pass,
- did it actually behave correctly when I ran it myself.
If any of those failed, I fixed it, or fed the failure back and re-tried. Nothing got accepted because it looked plausible — it got accepted because I ran it and watched it work.
That distinction mattered more than usual on this project, because the parts that actually took real debugging time weren't things AI Studio touched at all — they showed up once the code hit Zerops in production, which is where prototyping speed stops mattering and the actual environment starts talking back.
Failure #1: Node said 20, pnpm wanted 22
First deploy attempt on Zerops failed immediately:
pnpm 11.20.0
requires at least Node.js v22.13
The Zerops environment was running Node 20. Straightforward once I saw it — pin the base image to Node 22 — but it's the kind of failure that only shows up once you leave your local machine, where whatever Node version happened to be installed just quietly worked.
Failure #2: pnpm blocked its own dependencies
Fixed the Node version, redeployed, hit a new wall:
ERR_PNPM_IGNORED_BUILDS
pnpm's newer dependency build-script approval model was silently refusing to run install scripts for a few packages. This was new to me — I didn't know pnpm distinguished between "installing a dependency" and "letting that dependency run its own build steps" until it stopped one of mine cold. Fix was to explicitly allow the specific build scripts instead of disabling the safety check outright.
Failure #3: it built, then it wouldn't start
This is the one that actually took the longest to figure out, because the build succeeded. Green build, no errors, felt done. Then the process crashed on startup:
TypeError [ERR_INVALID_ARG_TYPE]
The "path" argument must be of type string or an instance of URL. Received undefined
Traced back to fileURLToPath(...) being called with something undefined — an ESM-related path resolution issue that only showed up at runtime, not at build time. Which is the actual lesson here: a successful build tells you the code compiles. It tells you nothing about whether the process survives being started. Those are two different checks, and I'd been treating a green build like a finish line.
The visible symptom downstream was a 502 — because the API process was crashing before it ever bound to a port, health checks failed, and Zerops had nothing to route traffic to. Debugging a 502 by looking at networking first would've been a waste of time here; the process was already dead before networking was even relevant.
How I actually used Zerops
Three services running: the frontend (static), the API, and the worker. The API and worker both needed to talk to Supabase for persisted analysis data and to FalkorDB for the graph layer, so getting service-to-service networking and environment variables right across all three was its own small project. The worker is what makes the async pipeline possible — repo analysis happens off the request thread entirely, so the frontend can show real job progress instead of a spinner that means nothing.
What actually mattered
Not the AI Studio prototyping speed, honestly, even though that helped. What mattered was the loop I used everywhere, on the app code and on the deploy config both: change something, run it for real, read what actually happened, fix the actual cause, repeat. AI Studio moved implementation faster. It didn't skip a single one of these three failures for me — I found all three by reading logs, not by asking a model what was probably wrong.
Repo: https://github.com/Devanshukoli/devflow
Live deployment: https://frontend-2d86.prg1.zerops.app/
Top comments (0)