DEV Community: KUNDAN SOLANKI

GoodFirst : I built my friend a way into open source.

KUNDAN SOLANKI — Sat, 03 Oct 2026 13:05:36 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My friend Shivin wanted to get into open source this October. He could code. What stopped him was everything around the code. He'd open a real project, see a long README and a hundred open issues, and the questions piled up before he wrote a single line:

Which of these files actually matter?
How do I even run this?
Which issue is small enough for a first try?
Which programs exist for beginners like me, and when do they open?

So I built him GoodFirst.

Paste a GitHub repo and ask a question in your own words ("I know some JavaScript, how do I run this locally?"). A local Gemma model answers from the project's own docs, maps out the files that matter, and picks three good first issues, each with a reason it fits and a place to start. A second page lists open source programs (GSoC, Outreachy, LFX Mentorship and more) with official dates, and shows which ones are open, live or not announced yet.

Two rules shaped all of it:

It runs on a laptop like Shivin's. Windows, 8 GB of RAM, no GPU. No API key, no account, no bill.
It never pretends. A small model gets things wrong. Anything GoodFirst can't verify against GitHub gets crossed out, right there on the screen.

Demo

Paste a repo and an optional question.
A live timeline shows each step as it happens: reading the repo on GitHub, Gemma reading the docs, choosing issues, checking every claim.
You get the answer, a short summary, setup steps, the important files and three issues.
Next to it sits the evidence panel: every claim the model made, where it came from, and whether it was verified, flagged or removed.

Code

KUNDAN1334 / GoodFirst

GoodFirst

Your first green square starts here. GoodFirst helps beginners make their first open source contribution. Paste a GitHub repo and (optionally) a question. GoodFirst answers the question from the repo's own docs, maps out the files that matter, picks three good first issues, and shows the evidence for every claim it makes. Anything it can't back up with what GitHub returned gets crossed out. When your pull request's checks go red, it reads the failed log and explains what broke.

The AI is Gemma, an open-weight model, running on your own computer through Ollama. There are no API keys and no hosted LLM calls, and GitHub is only ever read, never written to.

Built for the DEV Hacktoberfest 2026 Weekend Challenge, "Build for a Friend".

Why I built this: Shivin

My friend Shivin wanted to make his first open source contribution. He had picked a project AOSSIE-Org/DebateAI…

View on GitHub

How I Built It

Stack: Gemma 3 4B on Ollama · LangGraph · FastAPI with streaming · Next.js + Tailwind · GitHub REST API (read-only, never writes)

1. The model doesn't drive

I didn't build an agent that decides what to fetch. Code fetches the README, the contributing guide, the file tree and the beginner-labelled issues, cleans them up and trims them to fit an 8K context. Gemma gets one narrow job per step, in a fixed graph:

fetch → explain → pick_issues → honesty_check

Every answer must match a JSON schema, passed straight to Ollama's structured outputs:

msg = self.model.invoke(
    [SystemMessage(content=system), HumanMessage(content=user)],
    format=json_schema,  # Ollama forces exactly these keys
)

Broken JSON gets one retry, then an honest "couldn't get a usable answer." No made-up fallback. It sounds limiting, but with a 4B model on a CPU, this is what made the output trustworthy enough to hand to a friend.

2. The honesty layer

After Gemma answers, plain Python checks every claim it can against what GitHub actually returned:

Gemma says	Checked against	If it fails
"Look at this file"	The repo's file tree	Removed
"Run this command"	The README and contributing guide	Flagged
"Try issue #123"	The fetched issue list	Removed
"Here's your answer"	Same file and command checks	Docs don't cover it? A question for the maintainers instead

Issue titles, links and labels always come from GitHub, never from the model. Each invented file or issue costs 10% confidence. Below 60%, GoodFirst stops sounding sure and writes a polite question you can paste to the maintainers instead.

3. What a small model taught me

Asking for "JSON" isn't enough. Gemma returned valid JSON with keys missing. A real schema fixed it.
"Pick three" sometimes got one. minItems: 3 in the schema fixed that too.
Hinglish took three tries. I added an English/Hinglish toggle because that's how a lot of us talk. Gemma ignored it, then copied my example word for word. A neutral example plus a reminder at the very end of the prompt finally worked, and GoodFirst warns you when the answer still comes back in English.
Being helpful backfired. When Gemma gave fewer than three valid picks, my code topped up the list from its own ranking, and once that added a bad issue. Now it only tops up with issues that score well. Fewer picks beat a bad suggestion.

4. Is it fast?

No. On my 8 GB laptop, with the model already loaded, explaining a repo takes about 75–85 seconds and picking issues about 30–37. That's the trade: two minutes of waiting in exchange for free, private and offline. The live timeline helps, because you can see exactly what it's doing while you wait.

The hand-over

Shivin used it and opened his first pull request.

Then the checks went red. The CI log was about 2,500 lines long, and somewhere in there was the one line that mattered. He had no idea which one. That's a brutal moment for a beginner: the hardest part is done, the PR is finally open, and a wall of red text says you broke something.

I'd built GoodFirst to get him to his first PR, and hadn't thought about what comes right after. His very first real use found the gap. So I added CI help: paste the pull request, and GoodFirst pulls the failed checks and their logs, cuts the log down to the part around the error, and explains in plain words what failed, why, and how to fix it.

The same rules apply. Every log line it quotes must exist in the real log, or it's removed. Every file it names must exist. And for the question every beginner asks, "was it my change?", GoodFirst doesn't just trust the model. It checks in code whether the error mentions a file the PR changed.

Why Does Open Innovation Matter?

It's free. A beginner shouldn't need a credit card or an API key to get help reading a README.
It runs on what he already has. 8 GB of RAM, no GPU, and it works offline once a repo is cached.
It's private. The "dumb" questions beginners are scared to ask in public never leave the laptop.
I control the whole pipeline. I can pin Gemma to a schema, swap 4B for 1B with one setting, and wrap it in checks I can read and change. With a closed API you work around the model. Here I could build around it. A frontier model would write nicer paragraphs. It would also cost money, need an account, send everything to a server, and sound just as confident when it's wrong. For a first-timer, a small model that proves its claims beats a big one that doesn't.

Prize Categories

Best Use of Gemma.

Coca-Cola Animated Page

KUNDAN SOLANKI — Mon, 17 Feb 2025 14:25:26 +0000

This is a submission for Frontend Challenge - February Edition, CSS Art: February.

Inspiration

For this challenge, I wanted to explore the beauty of pure CSS art and push my creativity. Inspired by the elegance of minimalism and the versatility of CSS, I created this artwork to showcase how simple shapes and colors can bring an idea to life.

Demo

You can view my CSS Art live here: https://665f638cf1ccec2f53672412--elaborate-fenglisu-ec5400.netlify.app/

Here’s a preview of the artwork:

Code: https://github.com/KUNDAN1334/Practice_Projects/tree/main/Landing_Page

Journey

Working on this CSS Art challenge was both fun and insightful. I experimented with different CSS properties like clip-path, box-shadow, gradients, and animations to achieve the desired visual effect. Some key takeaways from this project:

Learned how to create complex shapes using clip-path and border-radius.
Explored the use of CSS gradients to add depth and dimension.
Enhanced my understanding of CSS animations to make the artwork dynamic.
I am particularly proud of how everything came together smoothly, and I hope to explore more intricate designs in future challenges

What’s Next?

In upcoming projects, I plan to:

Try more interactive CSS Art using hover effects and animations.
Explore SVGs combined with CSS for even more detailed artworks.
Participate in future frontend challenges to refine my CSS skills further.
If you liked my work, feel free to leave feedback and connect with me! 🚀

pinata-whiteBoard

KUNDAN SOLANKI — Sat, 12 Oct 2024 18:41:31 +0000

This is a submission for the The Pinata Challenge

What I Built

I built a collaborative whiteboard application called "Pinata Whiteboard" using React and Pinata IPFS services. This application allows users to draw, upload images, save their whiteboards to IPFS, and even mint their creations as NFTs

Demo

My Code

https://github.com/KUNDAN1334/pinata-whiteboard

More Details

Here are clear examples of how I used Pinata in my project:

1.Image Upload: When a user uploads an image to the whiteboard, it's stored on IPFS using Pinata's pinning service.

const handleImageUpload = async (file) => {
  const cid = await uploadFile(file);
  const url = getFileUrl(cid);
  canvasRef.current.addImage(url, 0, 0, width, height);
};

2.Saving Whiteboards: Users can save their whiteboards to IPFS, storing the entire whiteboard state.

const handleSave = async () => {
  const whiteboardData = canvasRef.current.getWhiteboardData();
  const cid = await saveWhiteboard(whiteboardData);
  alert(`Whiteboard saved! CID: ${cid}`);
};

3.Loading Whiteboards: Users can load previously saved whiteboards from IPFS.

const handleLoad = async (cid) => {
  const whiteboardData = await loadWhiteboard(cid);
  canvasRef.current.loadWhiteboardData(whiteboardData);
};

4.Listing Saved Whiteboards: The application fetches and displays a list of saved whiteboards using Pinata's Pin List API.

const listWhiteboards = async () => {
  const response = await axios.get(
    'https://api.pinata.cloud/data/pinList?status=pinned',
    {
      headers: {
        pinata_api_key: PINATA_API_KEY,
        pinata_secret_api_key: PINATA_SECRET_API_KEY,
      },
    }
  );
  return response.data.rows.filter(pin => pin.metadata.name === 'Whiteboard');
};

5.NFT Minting: Users can mint their whiteboards as NFTs, storing both the image and metadata on IPFS using Pinata.

const handleMint = async (e) => {
  e.preventDefault();
  const imageBlob = await getWhiteboardImage();
  const imageCID = await uploadFile(new File([imageBlob], 'whiteboard.png'));
  const metadata = {
    name,
    description,
    image: `ipfs://${imageCID}`,
  };
  const metadataCID = await mintNFTMetadata(metadata);
  alert(`NFT minted successfully! Metadata CID: ${metadataCID}`);
};