Spitball

Understand any codebase with confidence. Spitball's AI maps how your code works and what to build next, then ships ideas as real PRs. Spitball ideas. Ship code. Watch your map grow.

Comment

💡 Inspiration

We wanted to build something fun, creative, and technically challenging. It took three ideas to get there.

Our first idea was a learning-roadmap tool to help students map out skill branches and find resources. Our second was a hot/cold crypto wallet tool. After talking both through with mentors and judges, we had to admit something hard: neither brought enough new value.

We kept the part we cared about, which was learning and tech. That led us to mind mapping. What if the thing you're trying to learn is a codebase? And once you understand it, what should you build next?

That second question hit home. Anyone vibe-coding with AI knows the loop: ask "what should I add next?", get a good list, and lose it in chat history. That became Spitball: a tool that turns a codebase into a live, interactive map of ideas you can explore, expand, and ship.

🚀 What it does

Paste a public GitHub repo URL, and Spitball reads the file tree and key files. Gemini then generates a mind map of specific next steps: features, fixes, and security improvements. Each idea cites the actual files it touches.

The map. Nodes are color-coded by type (feature, security, and so on) and sized by estimated effort. Click any node to see its details.

Expand. Spitball branches an idea into more specific child ideas, which sprout on the map.

Build it. Gemini writes the code change, and Spitball shows you the diff. One click opens a real pull request on GitHub.

It stays in sync. Spitball watches your main branch. When you merge a PR, its node turns green and new follow-up ideas sprout from it. If you push your own hand-written commit, Spitball detects what you built and grows the map from there.

Your codebase becomes a map you steer, not a chat you type into.

🛠️ How we built it

Our four-person team split into four lanes: graph/frontend, panels/UI, AI, and GitHub/infrastructure/demo. Design, pitch, and UX were shared across the team.

We spent about 80% of our planning time on the idea itself. We mapped each person's skills against the problem, then broke the build into phases with a hard MVP freeze at hour 24. Each phase had an exit check we had to pass before moving on. Our bar was a real "wow" moment, both for the judges and for ourselves.

We built against a mock map first, so frontend and backend could work in parallel before the real APIs were ready.

Stack: Next.js, React, TypeScript, Tailwind CSS, react-force-graph-2d, Google Gemini API (zod-validated structured output), GitHub REST API, MongoDB Atlas, and DigitalOcean App Platform

⚔️ Challenges we ran into

Pivoting twice under a clock. Throwing out two ideas cost us hours. It was the right call, but it compressed our build window.

Scoping as first-time builders. Several of us were new to shipping a project in a weekend, and our instinct was to over-plan and over-scope. Using AI, we learned to cut features so we could finish a working product. In the end, a simple split of the work served us better than a detailed but half-baked roadmap.

AI integration limits. We hit API rate limits and maxed out context windows when feeding in larger codebases.

Keeping environment variables in sync. We were juggling keys for Gemini, MongoDB, and GitHub across four laptops and a production server. A missing or outdated variable would break things with no obvious error, so we learned to check configuration first whenever something failed.

Choosing and setting up deployment. We went back and forth on where to host, which cost us time. Once we committed, the initial setup was a hurdle of its own: connecting the repo, configuring the build, and getting the first successful deploy live.

Staying MVP. With a 36-hour clock, we set a hard rule against scope creep. We built Spitball as an embedded extension that runs locally inside Visual Studio Code, rather than publishing it to the VS Code Marketplace. Publishing brings its own overhead: packaging, a publisher account, review, and making it work reliably on any machine.

🏆 Accomplishments we're proud of

We pivoted twice and still shipped a working product in 36 hours. For several of us, it was a first.

We closed the full loop live: an idea on the map becomes a real pull request, and merging it turns the node green and sprouts new ideas.

We integrated AI with careful prompt engineering and connected multiple API services into one working product.

📚 What we learned

Kill ideas early. Honest feedback from mentors and judges saved us from building something nobody needed.

Scope beats ambition. A small thing that works demos better than a big thing that half-works.

Working with LLMs on real code is a context problem. Most of our AI work was deciding what to send the model, not just how to prompt it.

Talk to users and prioritize ruthlessly. Market research and early feedback showed us what mattered, and prioritization decided what got built.

🔮 What's next for Spitball

Larger codebases. We want to handle bigger repos without hitting context limits, through smarter chunking and caching of analyzed files.

Security and cost controls. As usage grows, we'll add rate limiting, usage caps, and abuse protection (including against DDoS) so the service stays secure and API costs stay sustainable.

Publish to the VS Code Marketplace. We'll package the embedded extension so anyone can install it in one click, then bring it to other editors.

Collaborative maps. Teams will be able to spitball on the same map together.

Built With

Share this project:

Updates

Submission history