DEV Community: Ujjwal Gupta

12yFix — Find the friction. Fix the experience.

Ujjwal Gupta — Sat, 24 Oct 2026 20:37:53 +0000

What I Built

12yFix is an AI-assisted accessibility audit and remediation tool.

It scans GitHub-hosted web applications using Playwright + axe-core, identifies accessibility issues, and uses AI to generate targeted code fixes.

Developers can then review, validate, visually test, and optionally create a GitHub PR for the fix.

The goal is simple: turn accessibility remediation from finding a problem into finding → fixing → validating → shipping.

Demo

🎥 https://youtu.be/bpaYJmbPYhI

Code

💻 https://github.com/heyujjwal/A11yFix

How I Built It

Frontend: React, TypeScript, Vite, Tailwind CSS

Backend: Node.js, Express

Accessibility: axe-core + Playwright

GitHub: Octokit + simple-git

AI: OpenRouter with inclusionai/ling-3.0-flash

AI is used for accessibility fixes and Playwright test generation, while the developer stays in the review loop.

Why Does Open Innovation Matter?

12yFix combines open-source tools like axe-core, Playwright, React, and GitHub APIs with configurable AI models.

Using open technologies makes the workflow easier to inspect, modify, extend, and experiment with instead of locking it to a single proprietary system.

The Lazy Payoff

Instead of manually jumping between accessibility reports, source code, browsers, tests, and GitHub, 12yFix brings the workflow together:

Scan → Find → Fix → Validate → Review → PR

Less repetitive investigation. More time spent actually improving the product.

RailBreaker: a local, open-source AI planner for breaking a long Indian train journey into confirmed-seat hops

Ujjwal Gupta — Sun, 18 Oct 2026 17:14:53 +0000

What I built

I live in Mumbai. Home is Lucknow, about 24 hours away by train. A flight is out of budget and the direct train is almost always waitlisted. So I end up trying combinations by hand: "Mumbai → Bhopal tonight, then Bhopal → Lucknow tomorrow?" IRCTC only searches direct trains, and nothing lists the break-journey options for you.

RailBreaker lists every schedule-feasible way to make the trip in 1 to 3 separate sittings. It ranks them by extra time over the fastest direct train, estimated fare, class and layover risk. Each plan ends in a copy-paste IRCTC checklist, so I only check seats on a short list instead of guessing.

It covers combinations I could never enumerate by hand:

different break stations (Nagpur, Bhopal, Itarsi, Jhansi, Kanpur...)
the same train booked as two tickets, which adds zero extra time and often fixes a waitlisted full journey
switching between stations of one city (Dadar ↔ LTT) and nearby destinations with a road leg

Demo

Code: https://github.com/heyujjwal/p5y-pathify

The open-source stack

Piece	What it does
Gemma 3 via Ollama (open weights, runs on my laptop)	understands trips typed in English, Hindi or Hinglish, turns "via MP, no night layovers, 3AC or better" into filters, explains trade-offs, and reads availability screenshots
DataMeet railways dataset (open data)	stations, trains and schedules
Python + Streamlit	the engine and the UI

The routing is deterministic Python (a pruned search over a timetable graph). The model only handles language and reading. It never does the routing or the arithmetic, so it can't invent a train.

Why open innovation mattered here

Private and offline. My trips and my IRCTC screenshots never leave my laptop. Gemma runs locally through Ollama.
Free to run. There is no per-query API bill, so the tool can stay free for students and people on a tight budget. A closed API would charge per request, which breaks the business for exactly the people who need this.
Swappable and tunable. I can change the model (Gemma, Qwen, Llama) with one environment variable. I can also fine-tune a small model on Hinglish travel phrasing, which a general API handles poorly.
No lock-in on data. Open timetable data means I can fix a wrong train or add days-of-run myself, instead of waiting for a vendor.
Honest split of work. Using a small local model only where language is involved kept it fast on a laptop and kept the numbers trustworthy.

Would anyone pay for this?

Possible ways to charge (these are ideas I haven't tested with customers):

a small yearly pass for students and migrants who travel home during festival season
a version for relocation companies and PG operators to give newcomers
a "waitlist predictor" add-on trained on user-reported outcomes

What it does not do (read this)

It plans possible journeys. It does not know live seat availability and never touches IRCTC. You check the listed legs yourself, or paste the screenshot back so the local model marks plans Verified or Blocked.
The free dataset is an old snapshot (around 2016) with no days-of-run, so trains default to daily. I added a days-file override and a validator that prints direct trains to compare with IRCTC.
Fares are estimates.
Separate tickets are not protected if the first train runs late.

Try it

git clone https://github.com/heyujjwal/p5y-pathify.git
cd railbreaker
pip install -r requirements.txt
ollama pull gemma3:4b
python scripts/build_real_data.py --download --from Mumbai --to Lucknow
streamlit run app.py

The README has a step-by-step build guide and a one-page use-case doc.

[Boost]

Ujjwal Gupta — Sat, 17 Oct 2026 18:56:51 +0000

Ujjwal Gupta

Oct 10

Green Stop: a Mumbai commute reset that runs on a local open-weight model

#devchallenge #hf26challenge #ai #opensource

3 min read

Green Stop: a Mumbai commute reset that runs on a local open-weight model

Ujjwal Gupta — Sat, 10 Oct 2026 21:57:44 +0000

The problem

Mumbai commuters lose hours to traffic: a 1-hour trip becomes 3. Telling tired people to "go touch grass" after that doesn't work, since nobody wants a detour. So I built something that fits green time into the commute they already have.

What I built

Green Stop takes where you are and how many minutes you can spare. It finds a green spot you can walk to and back in that time and gives you:

the spot's name and full address
walking time and total time needed
live temperature and AQI
a Google Maps walking-directions link
a short friendly note from a local LLM, in English, Hindi or Marathi

The screen is used for about 30 seconds. The rest is a walk.

Demo

github-production-user-asset-6210df.s3.amazonaws.com

Code: https://github.com/heyujjwal/green-stop

How it works

Place you type
  → OpenStreetMap geocoding
  → my hand-picked CSV spots + OpenStreetMap parks/gardens/beaches
  → distance math (walk there + 5 min + back)
  → Python builds the facts card
  → Gemma 3 4B via Ollama writes a 2-sentence note
  → Gradio UI

A key design choice: Python finds the facts and the LLM only adds a human note. Small models invent places if asked to recall them. Here the model is never trusted with facts, so every address, distance and time comes from data.

Stack: Ollama + gemma3:4b (open weights), OpenStreetMap (Nominatim + Overpass), Open-Meteo, Gradio, Python.

Why open mattered

Privacy: your daily commute route is sensitive. The model runs on my laptop and the app has no accounts, no tracking and no cloud LLM. The place cache stays local.
Works with a bad signal: the model, matching logic and cached results run without internet. Only first-time lookups and Google Maps navigation need a connection.
Free: no API keys and no per-call cost. OpenStreetMap and Open-Meteo are open data.
Swappable: I changed models by editing one line in config.py
Local knowledge: open map data plus my own CSV means I can add small gardens and shaded lanes that big map apps miss.

Taking it outside

I tested Green Stop on my own commute from [10th Oct]. Here is a real run:

Input: Marine Lines Station, Mumbai, [50] minutes, English

What the app returned:

Spot: Marine Drive Promenade (seafront)
Walk: about 3 min each way (0.3 km)
Total time needed: about 11 min (there, 5 min break, back)
Backup options: SK Patil Garden (7 min), Navi Wadi Garden (8 min)
Directions: a Google Maps walking link opened straight from the result
Note from the local model: a short, friendly line suggesting I sit on the sea wall and breathe

Day	Starting point	Minutes spared	Spot suggested	Did I go?	Mood before → after
1	Marine Lines Station	[11 min]	Marine Drive Promenade (3 min walk)	[Yes/No]	[e.g. tired → calmer]

What worked

The spot was only a 3-minute walk from the station, so it cost almost no extra time. That is the whole idea: green time inside the commute I already had.
The Google Maps link opened walking directions in one tap.
The result was specific (spot, distance, total time) rather than vague advice.

What went wrong

The address was not precise. OpenStreetMap's reverse lookup returned "Mumbai Coastal Road - Phase I, Navjeevan Wadi, Kalbadevi..." instead of "Marine Drive". The pin sits on the promenade edge, so the lookup picked a nearby road. Fix: I can type verified addresses into my CSV, which the app uses first.
Live weather and AQI showed "unknown (offline)"
The model's caution line was generic. Because conditions were unknown, it still added "if AQI is above 150 or raining..." That is noise, not information. Fix: only ask for a caution when real data exists.

Honest limitations

The model runs on my laptop, so the app only works while the laptop is on. A home mini PC or a phone-native build is the next step.
Park pins point to the middle of the park, not the gate.
OpenStreetMap data is uneven, so I curate my own spots for places I actually use.
Walk times are estimates (straight-line distance × 1.3 at 5 km/h), not live routing.

What's next

Phone-native version with an on-device model, automatic gate/entrance detection, shade and crowd info, and more cities.

Creator Compass — A Private AI Advisor for a Creator's Real Life

Ujjwal Gupta — Mon, 05 Oct 2026 04:58:00 +0000

What I Built

I built Creator Compass, a personal AI advisor for a friend who recently started her Instagram creator journey while pursuing her PhD at IIT.

She's a talented singer, plays tennis, enjoys spending time with friends, and loves creating reels, carousels, memes, jokes, sarcasm, and self-love content.

The problem wasn't that she had no content ideas.

The problem was deciding when to create, what to create, and when not to create at all.

She wants to grow as a creator, but she also worries about:

Whether a post will actually fit her personality and audience
Constantly worrying about views and engagement
Running out of ideas
Spending too much time creating content
Whether content creation will interfere with her PhD and research
Sharing personal thoughts and daily life with an AI service

So instead of building another "AI that generates Instagram captions", I built something closer to a personal creator advisor.

She tells Creator Compass:

How she's feeling
What happened during her day
How much time she has

Creator Compass then recommends whether she should:

🟢 Create today

🟡 Keep it low-effort

🔴 Don't post today — focus on your actual life

When it recommends creating, it suggests a content idea, format, hook, reasoning, and estimated effort.

The goal isn't to promise virality.

The goal is to help her grow without letting Instagram take over her life.

Demo

Code

GitHub: https://github.com/heyujjwal/creator-compass/

How I Built It

Creator Compass is built around local open-source AI.

Architecture

React
   ↓
Spring Boot REST API
   ↓
Ollama
   ↓
Qwen3

The frontend collects the creator's current context and sends it to a Spring Boot backend.

The backend constructs the advisor prompt and sends it to a locally running Qwen3 model through Ollama.

The model returns the recommendation, which is displayed in the frontend.

For the MVP, I intentionally kept the architecture simple:

React for the interface
Spring Boot for the backend API
Ollama for local model inference
Qwen3 as the open-weight AI model
No database
No Instagram credentials
No automatic posting
No external AI API

This keeps the project small, understandable, and easy to extend.

Why Does Open Innovation Matter?

This project deals with something that isn't just technical data.

The friend I'm building it for may share things about her mood, personal life, PhD work, research, relationships, and daily experiences.

Sending all of that to a third-party AI API wasn't something I wanted to make a requirement.

Using an open-weight model with local inference changed what I could build.

With Ollama, the AI can run locally on the user's machine instead of requiring every personal thought to leave the machine and go to a hosted AI service.

It also means the AI isn't a black box that I have to completely depend on.

I can:

Change the model
Modify the system prompt
Run the application offline
Experiment with different open-weight models
Customize the advisor's personality
Extend the system without changing the entire architecture

That's what open innovation made possible here:

I could build an AI around a person's actual life without making a closed AI API the center of the product.

What I Learned

The biggest thing I learned while building this was that an AI project doesn't need to solve a massive problem.

It can solve a very specific problem for one person.

Instead of asking:

"What AI product can I build?"

I started with:

"What is something my friend actually struggles with?"

That changed the project completely.

Creator Compass isn't trying to replace her creativity.

It's trying to give her a second opinion — and sometimes tell her that she doesn't need to post anything today.