Winning the NVIDIA DGX AITX Hackathon

One weekend. One Jetson. 2.3 million Austin construction permits. Nemotron Nano 8B running locally. The project won first place at NVIDIA's DGX AITX hackathon. The build looked nothing like a normal hackathon sprint, and that's the part I want to talk about.

The brief

DGX AITX ran Friday through Sunday and provided a DGX Spark, a Jetson AGX Orin, and a question: what can NVIDIA hardware enable today? The obvious move was to aim at the DGX with image generation, video pipelines, or fine-tuning. I took the Jetson path and asked a different question: what production-shaped problem can run on a thing the size of a hardback book, locally, with no token bill?

Austin has 2.3 million construction permits. Solar, battery, generator, EV charger. Every one of those is in a database somewhere, behind a search box that answers in seconds when it works at all. City planners spend weeks pulling numbers manually. There's no AI search layer. No semantic understanding of what's been built where. No way to ask "what's the solar-to-battery ratio in 78704?" and get an answer.

That became the problem. The project was Undervolt. The "under" because the city is under-built on storage. The "volt" because that's the unit that keeps a freezer running when the grid fails.

What shipped

A working web app. Not a demo. Not a deck.

• GPU-accelerated ingest of all 2.3M permits using RAPIDS cuDF on the DGX Spark, then exported to a Parquet file the Jetson could serve.
• A Nemotron Nano 8B model running locally on the Jetson via Ollama. No NIM container, no API. The whole inference loop fits in 24GB of unified memory.
• An interactive map of every solar installation, battery, EV charger, and generator across Travis County.
• A natural-language query layer that turned "show me where battery storage lags solar" into structured queries against the permit data.
• A discovery: a 22-to-1 solar-to-battery ratio across the city. Austin produces clean energy but can't store it. When the grid fails, and it has, solar panels stop being useful.

The discovery wasn't planned. I was not hunting for it. The model surfaced the ratio when I asked it to find anomalies, and the implication became obvious from there. That's the part that won.

The agentic engineering part

Here is the work breakdown. In a 12-hour build, the data pipeline can eat the whole day if you let it. The permit data was parsing, cleaning, and indexed in 75 minutes because the brief was narrow: read this schema, normalize these fields, produce this Parquet output, and prove it with a small eval.

The pattern went like this. One stream owned the data layer: load, clean, test, fix. A second owned the map UI: Mapbox, layer toggles, click-to-detail. A third owned the model layer: pull Nemotron, write the system prompt, build the structured-query tool, eval against ten gold-standard questions. Three streams ran in parallel. I worked at the orchestration layer: which work stream gets which brief, which eval defines done, which output ships and which gets sent back.

Each stream had a tight brief: "Here's the permit schema. Here's three example rows. Here's the output format I need. Here's the eval. Don't return until the eval passes." That brief takes thirty seconds to write. The work that follows is fifteen to forty minutes. While it runs, you write the next brief.

The trick isn't prompting. It's which agent does which part, in what order, with which context, under what review. Three parallel sub-agents on three parallel tracks beats one giant agent attempting the whole thing. I learned this the hard way on earlier projects, lost an evening to context bloat, and never went back.

By Saturday afternoon, the app worked. The rest of the weekend went into making the discovery presentable: tightening the query, improving the chart, writing the demo script, and rehearsing for Sunday's pitch.

What the judges noticed

Three things, ranked by what got the most questions:

1. Local inference. Nemotron Nano 8B running on the Jetson, no cloud round-trip. The judges asked twice whether it was hitting an API. It was not. They appreciated that.
2. A real discovery. The 22-to-1 ratio is a finding, not a feature. Most hackathon entries are features without findings. Production AI shows the second.
3. Production posture. It looked like an app. It loaded fast. It didn't error in the demo. The last two hours went into making it not break under stage pressure, not adding capability. That decision compounds.

What the experience taught me about the bar

A few things that I want to keep applying:

Real data over fake data. Most hackathon entries use synthetic data because real data is hard. Real data is also where the value is. Spend the hour to wire up a real dataset.

A discovery beats a feature. A feature is "I built X." A discovery is "I found Y." Y is what gets remembered.

Local is now a first-class deployment target. The Jetson is fast enough. Nemotron is good enough. There's a real architectural decision to make every time you reach for an API: does this need to be cloud, or am I defaulting to it?

Clean decomposition beats raw activity. The useful split was data ingest, map UI, and model query layer. Each stream had a bounded contract. That mattered more than how much typing was happening.

That last one is the part I keep coming back to. The project worked because the technical cuts were clean: real data, local inference, bounded prompts, and a demo centered on a finding rather than a generic feature.

What's next

Undervolt isn't a hackathon project anymore. It's running at undervolt-atx.vercel.app. The intelligence layer is real, the data refresh is automated, and the API is open. There has been outreach around whether it can become useful beyond the hackathon.

The deeper move is underneath it: every serious build I have done since this one has used the same agentic pattern. That includes the AI referee prototype, the local-only photographer copilot, and the home-network monitor. Brief small. Run parallel. Eval before code. Production from day one.

For another builder, the reusable lesson is simple: use agents where the eval is clear, use local models where privacy or cost matters, and make the output answer a question someone actually cares about.

That pattern has kept paying off.