GiveSpark — AI-powered ways to be generous this weekend

Atharva pawar — Sat, 05 Sep 2026 15:10:36 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

GiveSpark is a small tool that turns "I should do something generous this weekend" into an actual plan. You tell it what you're good at, how much time you have, and optionally a cause you care about — and it uses Google's Gemini model to hand back four specific, doable ways to be generous, built around you instead of a generic list.

No "just volunteer somewhere." No "donate to charity." Real, concrete ideas sized to fit the time you actually have — whether that's 15 minutes or the whole weekend.

Demo

Try it live: https://givespark-iota.vercel.app

Note: since this calls the Gemini API directly from the browser, you'll need to paste your own free Gemini API key (get one in seconds at aistudio.google.com/apikey) to generate ideas. No signup or payment required for the free tier.

[Add your screenshot or short screen recording of the wizard flow here]

Code

atharva-pawar80 / givespark

React + Vite

This template provides a minimal setup to get React working in Vite with HMR and some Oxlint rules.

Currently, two official plugins are available:

@vitejs/plugin-react uses Oxc
@vitejs/plugin-react-swc uses SWC

React Compiler

The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.

Expanding the Oxlint configuration

If you are developing a production application, we recommend using TypeScript with type-aware lint rules enabled. Check out the TS template for information on how to integrate TypeScript and Oxlint's TypeScript related rules in your project.

View on GitHub

How I Built It

I built GiveSpark as a step-by-step wizard instead of a single long form, so it feels like a short conversation rather than filling out paperwork. The screen is split in two: a dark editorial panel on the left that changes its headline as you move through each step, and a light, functional panel on the right where you actually answer.

The centerpiece is a small SVG "spark line" on the left — a thin line with four dots that lights up marigold as you complete each step, doubling as both progress indicator and the one memorable visual detail of the design.

Once you've answered all three questions and pasted a Gemini API key, the app builds a prompt from your answers and asks Gemini to respond with strict JSON (a title and detail for each idea). That gets parsed and rendered as four slightly rotated "note" cards with a torn-paper look, so the output feels personal rather than like a data table.

Stack: React + Vite, the Gemini API (gemini-3.6-flash) called directly from the client, and Lucide for icons. No CSS framework — the whole design system is a small hand-written stylesheet embedded in the component, so it runs anywhere with zero extra setup.

Prize Categories

Best Use of Google AI — the entire core feature depends on Gemini. The app builds a structured prompt from the user's inputs (skills, time, cause), asks Gemini to return strict JSON, and renders the response as personalized "kindness notes." Without the model, this is just a form — the AI is what turns three inputs into something genuinely useful.

What I Learned Building a Fraud Detection Model (And Why 99% Accuracy Almost Fooled Me)

Atharva pawar — Fri, 31 Jul 2026 12:08:34 +0000

A few weeks ago, I decided to stop just watching ML tutorials and actually build something end-to-end — from messy real data to a working, served model. I picked credit card fraud detection, using the well-known ULB fraud dataset (284,807 real anonymized European transactions, with only ~0.17% actually fraudulent).

Here's what I learned along the way — including a mistake that taught me more than any tutorial could have.

The trap: 99.8% accuracy that means nothing

The first thing I checked was the class balance. Only 292 out of 170,799 transactions in my training data were fraud — about 0.17%.

That number matters more than it looks. If a model just predicted "not fraud" for every single transaction, it would score 99.83% accuracy — and be completely useless. It would catch zero fraud, ever.

This is the single biggest lesson from this project: never trust accuracy alone on imbalanced data. The real metrics that matter are precision and recall on the minority class — in my case, how many real fraud cases the model actually catches (recall), and how often it's right when it flags something as fraud (precision).

Cleaning data on purpose, badly, to learn how to fix it

Before touching the real dataset, I deliberately broke a copy of it — injecting missing values, duplicate rows, and inconsistent formatting (like "$618.00" mixed in with clean floats in the same column). Then I had to detect and fix each problem myself.

A few things stuck with me:

Not all "bad" data should be treated the same way. A truly missing value and a badly-formatted-but-recoverable value need different fixes. I filled true missing values with the median (resistant to outliers), but parsed the messy currency strings back into numbers instead of throwing them away.
Duplicate rows are sneaky. They don't look wrong — they're just the same real event logged twice — but they quietly bias a model into over-weighting whatever pattern got duplicated.

Comparing models honestly, not just picking one

I trained and compared several approaches on the same data:

Model	Precision (fraud)	Recall (fraud)
Logistic Regression	0.78	0.78
Logistic Regression (scaled)	0.87	0.71
Logistic Regression + class_weight='balanced'	0.05	0.98
Random Forest	0.96	0.83

That third row is a great cautionary example. Forcing the model to aggressively catch every fraud case sounds good in theory — but it tanked precision to 5%, meaning it flagged huge numbers of real, legitimate transactions as fraud just to avoid missing rare cases. Depending on the business, that tradeoff might be worth it — or it might be a disaster. There's no universal right answer; it depends on what a false alarm actually costs versus what a missed fraud case costs.

Random Forest ended up winning clearly, likely because it can carve out complex, non-linear patterns in the anonymized features — something a single linear decision boundary (Logistic Regression) struggles with.

Tracking experiments properly instead of a hand-written table

By the third or fourth model variant, I was manually copying accuracy numbers into a notes file to keep track of what I'd tried. That's exactly the problem experiment tracking tools like MLflow are built to solve — instead of a fragile personal table, every run's parameters and metrics get logged automatically, comparable side-by-side, permanently.

Once I actually felt that manual-tracking pain firsthand, adding MLflow made immediate sense — it wasn't just "a tool someone said to learn," it was solving a real annoyance I'd already run into.

Shipping it as an API — and a bug that traced back to an earlier mistake

I wrapped the final model in a FastAPI service so it could take a transaction's details and return a live prediction. Testing it threw a real error:

X has 30 features, but RandomForestClassifier is expecting 31 features as input.

Turned out there was a stray leftover index column (__index_level_0__) still present in the training data — an artifact from how the dataset had been exported — that I'd accidentally trained the model on. The fix wasn't in the API code at all; it was going back to the training script and dropping that column before retraining.

That was a good reminder that bugs discovered at serving time often point back to something upstream in data prep, not the code you're currently staring at.

What's next

This project is now cleaned, tracked in MLflow, and served through a working API that correctly classifies both fraud and legitimate transactions I tested it against. Next up: containerizing it with Docker, and building a Retrieval-Augmented Generation (RAG) project to round out the skill set.

If you're early in your ML journey too — my honest advice is to deliberately break something (like I did with the dirty data) and fix it yourself, rather than only ever working with clean, ready-made datasets. That's where the real learning happens.

Currently learning ML engineering and AI agent development hands-on, one real project at a time. Open to entry-level opportunities and would love to connect with anyone working in this space.

DEV Community: Atharva pawar