Notes from taking third spot at the Dell x NVIDIA AI Hackathon

We built a self-learning IT firewall for our hackathon. The firewall runs on an 100% airgapped Dell GB10

I signed up for the Dell x NVIDIA local AI hackathon last Sunday. One day, forty Dell Pro Max boxes with GB10 chips on the tables, and a hard rule: build something that runs entirely on the box. No cloud APIs. No pre-built agents.

We took the “no pre-built” rule further than we needed to. We didn’t even pre-discuss ideas. We wanted to see if a team that had never worked together could brainstorm cold on the day and still ship something worth demoing. That was the whole exercise.

Setup ate the first two hours

The event was well organized. My one complaint: not enough coffee. There were energy drinks, and we made do, but coffee is coffee.

The bigger problem was the Wi-Fi. Getting the GB10 online and pulling the last few dependencies. Anything that touched the network cost us 30 to 60 minutes we didn’t have. As per instructions, we’d already brought the models pre-loaded on a pendrive. Brian had brought a portable network switch, and the moment he plugged it in, connections were working fine.

I’ve been running local models for a while, so I had the weights on me and the stack scripted in my vLLM repo. Once the box was online, I brought up Qwen3.6-27B (27B dense) behind a LiteLLM gateway and exposed it on the local network so the whole team could hit it. That gave us a working local inference endpoint about a third of the way into the day.

I’ve documented my setup previously here:

The hardware provided — GB10 boxes, monitors, keyboards, mice — was generous. But the peripherals were Bluetooth. Half of them didn’t pair cleanly. More on that at the end.

Finding a problem worth solving locally

We spent the next stretch brainstorming. Four people who had never built AI solutions together, all coming from different domains, all with their own pet ideas. It took a while to converge, and honestly I underestimated how long that would take.

We put two constraints on the wall before we picked anything:

1. The problem must genuinely need local. If a cloud LLM could plausibly do it, the whole hardware story falls apart. We were looking for a domain where the customer would refuse to send data outside their network.

2. The problem must not need real-time. Local models are slow. Anything that needed sub-second response was out.

We started with healthcare — small practices, doctors, pharmacies. Then someone pointed out none of us actually understood the healthcare workflow well enough to build for it in a day.

The conversation drifted to how data leaves these small practices, and that turned out to be an IT problem. Small clinics can’t afford IT teams. They want something they can drop into what they already have. That framing — a drop-in solution for an under-resourced team — was the useful abstraction. And the moment we stopped constraining ourselves to healthcare, the customer became obvious: IT administrators at mid-to-large organizations managing firewalls and network rules.

The pitch wrote itself from there. An IT firewall protects the company from both internal data exfiltration and external traffic. Traffic logs are some of the most sensitive data in the org and no security-conscious IT team wants them leaving the network. Firewall rules don’t update frequently, so latency isn’t a killer. And with AI agents getting deployed everywhere inside these companies, IT teams are stuck with firewalls that don’t understand agent behavior at all. They want a firewall that evolves as agent usage grows.

That’s Squidward: a 100% air-gapped, self-improving IT firewall that runs inference locally on the GB10 and flags anomalies in corporate traffic, especially traffic originating from agents.

Building it

Once we had the problem, the build was the fun part. That’s what everyone shows up for. We split the work, sketched an architecture diagram, and decided the product would ship with two interfaces:

• A dashboard. The old-school way. IT admins can see network traffic, review rules, drill into alerts, block traffic, take actions.

• An OpenClaw agent. Same underlying database, but conversational. Ask it what’s happening. Ask it to block something. Ask it why an alert fired.

The bet was that IT admins will always want the dashboard, but the agent surface is where the actual leverage sits.

A few hours of coding got us to end-to-end. Not polished, but the demo path worked.

The pitch and the result

Coding stopped at 6:30 and 8 shortlisted teams got called up for the pitch and demo. Five minutes each, live pitch, top 8 teams. We walked up, showed Squidward, and took third place.

After the awards, the judges shared each team’s rubric scores. We were a few points off the top spot. Sharpening the demo narrative and rehearsing the pitch would probably close that gap next time — and that’s the biggest lesson I’m taking into the next hackathon: on a rubric where demo + pitch is 30% of the grade, thirty focused minutes of rehearsal is the highest-leverage half hour of the day.

Team v-x: (l-r) Rohan, Brian, Shrivara, Devashish

What I actually took away

The result is a great start. The bigger thing is that a room full of builders spent a full day on local inference, on real hardware, solving problems where the local constraint was load-bearing - not gimmicky. That’s a shift. A year ago most of these demos would have quietly called out to GPT-4 behind the scenes.

I’m a believer in open weights and open source. As local models keep getting more efficient and more accurate, the number of real enterprise use cases that don’t touch a cloud LLM is only going up. The Dell/NVIDIA hardware story isn’t a marketing exercise - the boxes are actually fast enough now.

Looking forward to more of these. Next one I want the top spot.

Takeaways for future hackathons

For anyone doing one of these, especially a local AI hackathon:

1. Bring a wired mouse and a wired keyboard. Do not trust provided peripherals. Bluetooth pairing at a venue with a hundred people is a coin flip.

2. Bring a portable network switch and an Ethernet cable. Venue Wi-Fi will fail. The team next to us had a switch and skipped an hour of pain.

3. Pre-stage everything on a USB drive. Model weights, dependencies, container images, your stack repo. Assume you get zero bandwidth at the venue.

4. Rehearse the pitch. Even a bad five-minute practice run beats winging it. On a rubric where demo is 30% of the score, this is the highest-leverage thirty minutes of your day.

5. Pick a domain you understand. We almost burned our day on healthcare before pivoting. If you don’t know the customer’s workflow, you can’t write a convincing pitch, no matter how good the tech is.

Demo Video:

Repo: https://github.com/ric03uec/squidward

Deck: https://ric03uec.github.io/squidward/deck/#1

Huge thanks to my teammates Brian, Rohan, and Shrivara for a full day of building.

Methodology

• Research: Attended and placed 3rd at the Dell x NVIDIA AI Hackathon on 2026-07-26 (Museum of Flight, Seattle). Full day: hands-on GB10 setup, local model deployment with vLLM + LiteLLM + Qwen3.6-27B, product ideation, coding, and pitch.

• LLM used: Claude Opus 4.7 (claude-opus-4-7)

• Drafting process: Voice memo of the day → transcript → LLM structured into blog post, cutting filler and repetition while preserving voice.

• Author rewrite: ~30% rewritten — retitle, tone control on the pitch/result section, factual corrections (model spec), opinions and takeaways framed by me.

• Fully mine: Every observation, product decision, pitch, opinion, and takeaway. The hardware advice comes from the actual day.

• Fully LLM: Sentence-level cleanup, paragraph structure, transitions.