DEV Community: Yajush Srivastava

StudioTrack: A Concept for Helping Artists Manage Custom Orders

Yajush Srivastava — Mon, 19 Oct 2026 06:00:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

StudioTrack is a proposed order workspace for artists who sell custom work through Instagram. The idea came from my friend Suhani, a college student who makes and sells paintings. Taking an order is only the beginning of her work: she also has to remember the customer’s requirements, track the painting, balance deadlines with classes, and keep the customer updated.

I imagine StudioTrack as a quiet assistant behind that process. Suhani could paste a customer conversation or share an order form. The system would turn the request into a draft order card showing the subject, size, medium, references, requested deadline, and anything still unclear. It would show where each detail came from, so she could correct a misread message before accepting the commission.

Once an order is accepted, Suhani would move it through stages such as sketching, painting, finishing, and delivery. When she records progress, the AI would prepare a short customer update in her preferred tone. She would edit or approve it before sending. A private tracking page could show customers the progress she has chosen to share.

The control panel would also give her a brief view of what needs attention: orders approaching a date she set, drafts awaiting approval, and work she has marked as waiting for a customer. During an exam week, she could record reduced availability and see possible clashes without having AI change a promise she made.

This is aimed at solo artists and other makers who take custom orders through messages. The business hypothesis is that fewer lost details and less repetitive admin work would make a modest subscription worthwhile. I have not tested what Suhani—or anyone else—would pay.

Status: Concept only. StudioTrack was not built or tested during the Week 2 challenge window.

Demo

There is no working demo yet. The first demo I would want to build is one complete journey: an incoming commission request becomes a reviewable order card; Suhani corrects it, sets the price and date, records a painting milestone, approves an update, and sees exactly what the customer can view.

That journey matters more to me than a chatbot answering questions about the studio. It would show whether the tool actually reduces work while keeping Suhani in control.

Code

There is no project repository yet. StudioTrack is a product specification and proposed workflow, not an implemented application.

How I Built It

I have not implemented the system or tested a model. My proposed stack is a small Django application for the order board, customer pages, login, and stored order history, with an open-weight model running through a local inference service.

The model’s first job would be to read messy requests and return structured suggestions. Each suggested detail would carry the relevant words from the original request. Its second job would be to draft short updates using only order details and progress Suhani has confirmed. Application code—not the model—would control order stages, access to private information, approval records, prices, and promised dates.

I would start with pasted text because it matches how orders arrive without requiring access to Instagram’s messaging API. Reading screenshots, connecting DMs, and sending messages automatically would come later if the basic workflow proves useful and those integrations are permitted and reliable.

Why Does Open Innovation Matter?

A small art business cannot assume steady order volume or a large software budget. An open-weight model could make it possible to process requests locally and draft updates without paying an AI provider for every message. Keeping inference under the maker’s control could also give her more choice over where customer conversations and reference images go.

Openness would let the project test and replace models as well. Suhani’s messages may include shorthand, mixed languages, and details scattered across several replies. The right model is the one that handles her work accurately enough—not simply the one with the most impressive general benchmark.

Those benefits are still hypotheses. A real build would need to measure extraction errors, drafting edits, response time, running costs, and where data actually travels. I would report the mistakes alongside the successes.

I missed this challenge’s build window, but the concept remains worth pursuing. The next meaningful milestone is a working version Suhani can use on a real order—and her honest answer about whether it helped.

NUKKAD: Your Neighborhood Is A Map, You Haven't Finished.

Yajush Srivastava — Mon, 12 Oct 2026 03:57:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

I once went to Vaibhav Park in formals, just for fun. I found street dogs, people exercising, women doing yoga, and uncles relaxing. What stayed with me was that I hadn't known a place like this existed so close to me. That was not a Nukkad-generated walk. It was part of the reason I wanted to build Nukkad.

I grew up playing football, cricket, table tennis and pool around my society. Those shared places still exist, but it's easy to spend a free half-hour on a screen and assume there's nothing nearby worth going out for. I wanted a reason to notice the neighbourhood without making the phone the main event.

Nukkad is a local neighbourhood discovery app. Give it your interests, 20–60 minutes and a confirmed public walking start. A local open-weight model ranks eligible nearby places and suggests small things to notice. Application code checks the complete walk back to your start. You review the route, export a walk card to your phone or paper, and leave the app behind.

On return, report which destinations you reached or skipped and write what you saw. You can also record a visit directly from a place on the map, without planning a walk first. Reported visits live in place folders with editable journal drafts. Add photos and Nukkad can prepare a Location Card: a keepsake for a visit, separate from the walk card you take outside. Inferred interests stay pending until you review them. The map marks places you say you visited; it never claims you covered the surrounding streets.

Demo

For this demo, I asked my mom to try Nukkad. She visited Vaibhav Park and took five photos there, capturing flowering trees, walking paths, benches and outdoor exercise equipment.

The recording follows the experience of using Nukkad to keep a memory of that visit: adding a description, saving the photos in a place folder, and letting local AI prepare a journal and Location Card. The AI uses the description and supplied photos to write a summary and select a cover, while all five photos remain available in the folder.

It brings the idea behind Nukkad into everyday use: step outside, notice something nearby, and bring back a memory worth keeping.

Code

Nukkad on GitHub is MIT licensed. The setup guide covers the local model and first map download. The architecture and evaluation guides explain the design boundaries and measured results. The app credits OpenStreetMap; model weights retain their own terms.

How I Built It

Start with mapped places, then check the walk

Nukkad saves an OpenStreetMap extract and walking graph locally. The user confirms a public starting point, inspects possible entrances, and can correct a closed or inaccessible place. A park's polygon centre is a display point, not automatically a usable gate. Map tags are evidence, not a guarantee of current access.

Give AI a real job with firm boundaries

I run Gemma 4 E2B through Ollama on the laptop. It ranks a bounded list of eligible places using explicit interests and reviewed local history. After code fixes the route, Gemma drafts observation activities for the selected stops. On return, it can draft third-person journal prose from the user's report. For photo-backed Location Cards, it writes a short summary and can choose a cover from multiple supplied photos. With one photo, code uses that photo directly; code always renders the card layout.

The model cannot add a destination or declare a route safe. Code calculates the outbound legs and return, walking and stopping time, distance, daylight and current eligibility. It rechecks the plan before a walk card is accepted or exported. Ranking and wording can fail separately, so Nukkad labels each fallback instead of presenting a template as AI output.

Let the person own the memory

Original notes remain intact. Generated writing is editable, and earlier versions survive regeneration. An inferred interest needs an exact source quote and review before it affects a later quest. Seeing people doing yoga at a park, for example, would not by itself mean I want yoga-themed walks.

One bug taught me that saving inputs isn't the same as finishing an experience. Saving a direct visit initially stored its note and photos but didn't prepare the journal or Location Card the user expected. I connected preparation to the completed save, exposed failure and retry states, and made retries reuse the saved visit instead of reuploading everything. The original note remains the source of truth even when generation fails.

What I checked

The current repository passes 165 Python and 59 JavaScript tests, plus lint and formatting checks. Actual local-model evaluations used synthetic places and notes, not invented field results. In one twelve-case Gemma 4 E2B run, eleven cases had feasible routes: all eleven used validated AI ranking, eight used AI observation wording, and three displayed template wording after bounded attempts. The warm generation median was 5.87 seconds in that fixture. The model changed some stop choices against a simple interest-aware baseline, but blind human ratings are pending. Different is not automatically better.

A small synthetic vision check also exposed a limitation: in a five-image case, Gemma selected a square scene although the note referred to circles. Users can change the cover. Passing a schema validator does not prove a choice is meaningful.

Why Does Open Innovation Matter?

The context that makes Nukkad personal is also the context I wanted to keep on my laptop: where I went, what I noticed, photos I kept, and what I might enjoy next time. Gemma runs locally; notes and media stay in local storage. Generation needs no hosted inference account or per-request API bill, though hardware, disk space and electricity still cost something.

Open components let me inspect and change the decision path. I can see why a place was eligible, compare Gemma with deterministic ranking, edit prompts and validators, and choose another installed local model. A separate Gemma 3 run passed the production ranking-and-wording path. That supports model swapping, not equal recommendation quality; I have not fine-tuned a model or established a human preference win over the baseline.

The interface, saved map, bundled assets and downloaded weights are designed for use without a connection after setup. Initial installation, place search and map download need internet; optional air-quality refreshes do too. A process-level test blocked non-local requests from Nukkad during generation, but I have not completed a whole-machine disconnected trial. The supported advantage over a closed hosted API is control of personal context and model behaviour, not automatically better suggestions.

Nukkad has no live GPS, guarantee of public access, street-level air sensor or medical advice. Actual phone readability, a Nukkad-guided outing and blind recommendation ratings still need human testing. I would rather show those gaps than turn a synthetic demo into a story about a walk that never happened.

My Agent Session

I used coding agents to build Nukkad, while setting the product direction, reviewing behaviour and steering fixes. The saved-visit bug above is one example of that loop. The coding agents are separate from Gemma, which runs inside Nukkad.

Prize Categories

Best Use of Gemma. Gemma 4 E2B performs local destination ranking, observation writing, journal drafting and photo-assisted Location Card preparation. Fallbacks and limits remain visible.

dAIly: AI Planning Agent for My Friend.

Yajush Srivastava — Mon, 05 Oct 2026 05:45:24 +0000

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

What I Built

My friend Kushagra is my college mate and a third-year computer science student. During a conversation, he told me about his goals: learn machine learning, participate in GSoC 2027, build projects, and, most importantly, improve his DSA skills and get better at competitive programming.

He knew what he wanted to do. He struggled to fit it all into his day.
On Mondays, his classes run from 1 PM to 5 PM. On Tuesdays, they run from 8 AM to 1:40 PM. Wednesdays stretch from 9 AM to 5 PM. Teachers give assignments as they finish units, mid-semester exams need preparation, and sometimes he travels out of town.

Each day leaves him with a different amount of time and energy.
When he comes home tired, he still has to choose: practise DSA, learn ML, work on a project, or finish an assignment? He spends time deciding, makes a timetable, and then struggles to follow it when things change.

I suggested building an AI agent that could help him plan around those changes. He liked the idea, and I built dAIly specifically for him.
dAIly is a local desktop planning agent. It helps him discuss goals, break them into smaller tasks, and plan his day using his class timetable, deadlines, free time, and energy.

If a new assignment comes up, he can add it to today’s plan without making it a permanent goal. If his priorities change, he can ask for a new plan. He reviews the suggested changes before applying them and records what he actually did after a focus session.
The aim is to help him choose useful work for the day he actually has.

Demo

The demo uses sample planning history, but the AI responses are generated locally through Gemma.

The five-minute narrated video shows the Today page, adding and discussing goals, planning the day, and tracking progress. It also includes Kushagra’s cameo, where he shares what he liked after trying the app.

Code

Explore the dAIly repository

I built dAIly solo, without using an existing project as a starting point. I used Codex as a coding assistant, wrote substantial parts myself, reviewed almost all the code, and fixed bugs myself.

The application code is MIT licensed. Gemma’s model weights have their own separate terms.

How I Built It

dAIly uses Gemma 3 4B, running locally through Ollama. I built the desktop app with Electron, React, and TypeScript. SQLite stores goals, subtasks, plans, conversations, and focus-session history.

I set up the first routine, sleep schedule, focus preferences, and goal priorities around Kushagra’s needs. Users can change these during onboarding and in the app’s settings.

From a conversation to a plan

Before exploring the features, Kushagra asked what made dAIly an AI agent rather than a simple chatbot.

The answer is how the conversation leads to actions in the app.

Gemma receives the details it needs for planning: goals, unfinished tasks, deadlines, free time, and recent session outcomes. It reads the user’s update and returns a proposed plan in a structured format. The app checks the proposal and fits the work around classes, other commitments, and breaks. Kushagra reviews it before applying it.
A goal discussion can lead to saved subtasks. An approved plan becomes a schedule. After a focus session, Kushagra reports what happened, and later recommendations can use that information.

These steps are what make dAIly a planning agent. It saves information across conversations and connects its advice to changes the user can approve and carry out.
The user stays in control. The agent cannot silently apply every suggestion, and a timer ending never automatically marks a task as complete.

The hardest part: changing plans without losing things

The hardest part was getting the agent to understand when and why it should change a plan, goal, or subtask.

A new assignment should affect today’s schedule. A goal discussion might change the steps needed to reach that goal. Work interrupted yesterday could affect today’s recommendation, while a deadline tomorrow might change what comes first.

At the same time, the agent needs to keep what the user has already confirmed. Asking for a revised plan should not make an earlier assignment disappear or lose a preference Kushagra just shared.

Making this work meant improving the model instructions, response formats, checks, saved records, and scheduling code.

What testing taught me

One early response suggested 45 minutes of work when only 20 minutes were available. The response was valid JSON, but the plan did not fit the day.

That taught me to check more than the response format. I added checks for available time, shorter blocks when energy is low, valid task IDs, and deadline order. Gemma suggests the work, and the app checks whether it fits into a usable schedule.

In a documented Linux evaluation, I ran six fixed scenarios twice. All 12 passed their automated checks. Planning requests took about 9 to 22 seconds, including requests where an invalid response needed another attempt.

This was a small test. It does not show how fast the app will run on every laptop or prove that every suggestion will be helpful.

Why Does Open Innovation Matter?

To help someone plan, the app needs personal information: their routine, unfinished goals, deadlines, and the days when they struggled to get started.

Running Gemma locally through Ollama lets that information stay on the laptop instead of going to a hosted model API. Once the app and model are installed, the AI can work without an internet connection.

There is also no hosted inference charge for each update or plan revision. Running the model still needs suitable hardware and electricity, but each conversation does not add an API bill.

Using an open-weight model and having the app’s code available locally lets me inspect and change the model instructions, checks, and planning behaviour. I can adjust how suggestions become actions as I learn what works for Kushagra.

That matters because his first trial already showed me something I need to improve.

What Kushagra Said and What Comes Next

Kushagra liked the main flow: discuss a goal, review its subtasks, and then plan the day. It matched what he wanted from our original conversation.

He also pointed out a problem.

Even when he set a 120-minute focus preference, the AI often suggested shorter blocks: 20, 40, or 50 minutes, frequently around an hour at most. He wanted a fuller plan for his available day, but sometimes had to keep asking before the AI gave more time to his work.

That extra back-and-forth made the app less useful to him. Allowing longer focus sessions in the app did not mean the model would choose them when appropriate.

This is what I want to improve next: follow his preferred working style and plan enough work across his free time, while still taking tiredness, classes, and deadlines into account.

His feedback helped me understand what success should look like. dAIly should help him spend less time deciding and make it easier to start the work he cares about.

This started with a conversation between college mates. Now I have a working app, and Kushagra’s experience is helping me decide what to improve next.

Prize Categories

Best Use of Gemma: dAIly uses Gemma 3 4B locally through Ollama for goal discussions and planning.