DEV Community: Samarth Mukhija

I Built SlothFlow AI: A Local-First AI Assistant That Turns Brain Dumps Into Action Plans 🦥

Samarth Mukhija — Sun, 25 Oct 2026 13:12:31 +0000

We all have those days.

You have assignments to finish, projects to build, emails to reply to, interviews to prepare for, and about twenty other things running through your head.

You know what you need to do. The hard part is figuring out where to start.

I wanted to build something that could help with that problem, so for the Hacktoberfest DEV Challenge Week 3, I built SlothFlow AI — a local-first productivity assistant designed to turn overwhelming brain dumps into manageable action plans.

What is SlothFlow AI?

SlothFlow AI follows a simple idea:

Do less. Get more done.

Instead of spending time organizing every thought manually, you can write everything down in plain language and let SlothFlow turn those notes into a draft task plan.

The goal isn't to create another chatbot that tells you to be productive. It's to build a practical tool that helps you take the next step.

What can it do?

Turn brain dumps into action plans

Write something like:

I need to finish my project report by tomorrow, prepare for a backend interview, reply to my mentor, and organize my downloads folder.

SlothFlow converts your notes into individual tasks, suggests priorities, and provides estimated completion times.

You can review the results and choose which tasks to save.

Manage tasks in one place

Once saved, tasks appear in your workspace, where you can:

Track pending and completed tasks.

View estimated time remaining.

Mark tasks as complete.

Delete tasks you no longer need.

Add new tasks manually.

Start fresh with Daily Reset

The Daily Reset view summarizes your unfinished work and estimated time requirements.

Rather than treating unfinished tasks as failures, the idea is to make it easier to review them and choose a realistic next step.

Run AI locally

One of the decisions I made while building SlothFlow was to support local AI inference through Ollama.

When a compatible local model is available, SlothFlow uses it to generate a more contextual task plan. If Ollama isn't available, a built-in rules-based fallback can still produce a basic checklist.

This means you can try the application without an API key or a paid AI service.

How I built it

The project uses a lightweight stack:

Python — application logic

FastAPI — REST API and backend

Ollama — optional local LLM inference

SQLite — local task persistence

HTML, CSS and JavaScript — responsive frontend

Pytest — automated testing

The backend exposes endpoints for generating plans, creating and retrieving tasks, updating task status, deleting tasks, and generating the Daily Reset summary.

I also added input validation and made the AI output pass through a validation step before the application uses it.

Why local-first?

Personal notes can contain unfinished ideas, work details, and other information people might not want to send to an external AI service.

SlothFlow is designed to keep task storage on the machine running the application and to use a locally configured Ollama server for AI inference.

There is no external AI API requirement.

Of course, local-first doesn't automatically mean every deployment is secure. The current project is a local prototype, and a public deployment would need additional security measures.

Challenges along the way

One of the interesting parts of this project was making the application useful even when the AI model wasn't available.

Rather than making the entire application depend on a running LLM, I implemented a fallback rules engine. This keeps the core workflow accessible while allowing users to enable local AI when they want more contextual results.

I also built the task management flow around review and confirmation: generated tasks remain drafts until the user chooses to save them.

That distinction matters. AI-generated suggestions shouldn't silently become someone's to-do list.

What's next?

SlothFlow is an MVP, and there is plenty of room to improve it.

Some features I'd like to explore next include:

Smarter task decomposition and dependency detection.

Better scheduling based on available time.

Markdown export and import.

More robust testing with different local models.

Optional reminders and recurring tasks.

Improved evaluation of task quality and time estimates.

I'd also like to measure how much time the tool actually saves compared with organizing the same notes manually, rather than assuming that automation is automatically better.

Try it and contribute

I'm building SlothFlow as part of the Hacktoberfest DEV Challenge, and I'd love feedback from developers working on local AI, productivity tools, and open-source applications.

GitHub repository:https://github.com/Samearth17/slothflow.ai
Youtube Demo Video:https://youtu.be/CaHC42t-EOk

If you try it, I'd love to hear what works, what doesn't, and which repetitive task you'd want to automate next.

If you'd like to contribute, ideas around better task extraction, accessibility, testing, and local model support would be especially welcome.

Final thoughts

I think the most useful AI applications aren't necessarily the ones that do the most complicated things. Sometimes, they're the ones that remove a small but persistent source of friction from everyday life.

That's what I wanted to explore with SlothFlow AI.

Less time organizing the work.

More time actually doing it.

Thanks for reading! 🦥

SoloSprint AI: Turning Side-Hustle Ideas Into Action With Local Open-Source AI

Samarth Mukhija — Sun, 18 Oct 2026 08:45:13 +0000

A lot of developers and students have skills they could turn into a side hustle. The difficult part is often deciding what to sell, how to price it, who to approach, and what the first steps should be.

For Hacktoberfest's Side Hustle challenge, I built SoloSprint AI a privacy-first assistant designed to help turn an early business idea into an actionable plan.

What is SoloSprint AI?

SoloSprint AI helps users turn their skills and ideas into a structured starting point for a side business. It is built around local AI inference rather than requiring users to send their ideas to a hosted AI service.

The goal is simple: make AI assisted planning more accessible to people who are just getting started.

See it in action

Demo video: https://youtu.be/ESk3F5Y83bQ

Source code: https://github.com/Samearth17/SoloSprint-AI

How it works

The project uses Python and FastAPI for the application backend, with Ollama providing access to a local open-weight language model.

The intended workflow is straightforward:

Describe a side hustle idea and your skills.

Generate a structured plan with practical next steps.

Use that starting point to think through your offer, pricing, and client outreach.

The application is designed to run locally, allowing users to experiment without making a third-party AI API a required part of the workflow.

Why open innovation matters

For me, open source AI is exciting because it gives developers more control over the tools they build.

Running inference locally can help keep personal ideas and early client briefs on a user's own machine. Open model ecosystems also make it easier to experiment with different models and adapt a project to different hardware, budgets, and needs.

That flexibility matters for students, independent developers, and freelancers who want to experiment without immediately taking on the costs or dependencies of a hosted AI service.

Built with

Python

FastAPI

Ollama

HTML, CSS, and JavaScript

An open-weight language model

What I learned

Building SoloSprint AI reinforced the importance of making AI useful for a specific problem rather than adding a model just for the sake of using one.

I also had to work through local environment and dependency issues while getting the application running. That is part of building software too: getting from an idea to something another person can actually run.

What's next?

I would like to continue improving the user experience, add more flexible output formats, and make it easier for other developers to contribute.

Feedback and suggestions are welcome in the GitHub repository.

🌿 FieldLens AI: A Local AI Explorer That Gets You Outside

Samarth Mukhija — Sun, 11 Oct 2026 15:04:24 +0000

We spend so much of our time looking at screens that sometimes we forget to look at what's around us.

A walk through a park can become an opportunity to observe birds, compare leaves, notice insects, and ask questions about the environment. But getting started can be surprisingly difficult when we don't know what to look for.

That's the idea behind FieldLens AI — an AI-powered nature exploration project designed to turn ordinary outdoor walks into small discovery missions.

I built it for the Hacktoberfest Week 1 challenge, whose theme is Touch Grass: use open-source AI to encourage people to spend less time on screens and more time in the real world.

🌱 What I Built

FieldLens AI helps users plan short nature exploration sessions based on their available time, environment, and interests.

The project focuses on making outdoor discovery accessible rather than overwhelming.

The main features include:

Nature mission planning: Create exploration activities based on the time available and the environment.

Personalized discovery: Tailor activities to interests such as plants, birds, insects, trees, and biodiversity.

Field journal: Record observations and reflections for later.

Screen-free mode: Keep the focus on the outdoor experience instead of prolonged phone use.

Local-first architecture: Use browser-local storage for personal journal entries, avoiding the need to send them to a remote journal service.

The goal is simple: use technology to help people engage with the world around them, then encourage them to put the technology away.

🎬 Demo

Watch FieldLens AI in action: [INSERT YOUR VIDEO LINK HERE]

The demo walks through the application, from generating a nature mission to recording an observation in the field journal.

💻 Source Code

The project is available on GitHub:

FieldLens AI — GitHub Repository

You can explore the implementation, review the source code, and follow the setup instructions in the repository's README.

🧠 How I Built It

The application uses Python and FastAPI for the backend, with HTML, CSS, and JavaScript for the frontend.

The AI component is built around Hugging Face Transformers and a locally runnable open-weight text-generation model. The intention is to generate useful, context-aware nature missions without depending on a paid, hosted AI API.

The application also supports fallback missions so that the core experience remains usable when local model inference is unavailable.

An important implementation detail: local model output and fallback output must remain clearly distinguishable. A fallback response should never be presented as a result generated by the model.

The field journal uses browser local storage, allowing observations to persist across page reloads without creating an account or sending journal content to a remote service.

This architecture keeps the project relatively lightweight while demonstrating how open-weight AI can be integrated into an everyday application.

🔓 Why Open Innovation Matters

For this project, open innovation is about more than avoiding API costs.

Using an open-weight model with a local inference workflow gives developers greater control over where inference happens, which model is used, and how the application behaves.

It also provides an opportunity to experiment, inspect the implementation, change the model, and build on existing tools without making a paid hosted AI service the foundation of the product.

There are still trade-offs. Local models require storage and computing resources, their output quality varies, and a model must be downloaded before it can be used without an internet connection.

The privacy benefit also depends on how the application is implemented. Local inference does not automatically make every part of an application private, so keeping journal data local and avoiding unnecessary data collection are important design decisions.

For a nature explorer, this approach makes sense: the AI should help prepare the experience, while the actual experience happens outside the screen.

🌳 What I Learned

Building FieldLens AI reinforced an important lesson: adding an AI model to an application is only one part of creating a useful AI product.

The application still needs understandable interactions, sensible fallbacks, clear status reporting, data handling that matches its privacy claims, and a user experience that serves the underlying purpose.

I also wanted the concept to encourage a healthier relationship with technology. A successful outdoor session should leave someone with something they noticed or learned, not simply more time spent interacting with an app.

There is room to improve the project further, including richer observation workflows and additional ways to support nature learning without making unsupported claims about species identification.

🚀 Try It

Explore the source code, follow the installation instructions in the README, and try creating a short outdoor discovery mission.

GitHub: https://github.com/Samearth17/fieldlens-ai
YouTube : https://youtu.be/YfBh3Mf1YRI

If you try it on a walk, I'd love to hear what you discover.

Thanks for reading, and happy Hacktoberfest! 🌿

I Built a Private AI Scam Detector for a Friend with Local Open-Source AI

Samarth Mukhija — Sun, 04 Oct 2026 10:44:50 +0000

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

What I Built

Have you ever received a message that made you stop and think:

"Is this actually legitimate, or is this a scam?"

That was the problem I wanted to solve for a friend.

Instead of building another generic AI chatbot, I built ScamShield Local a small, privacy focused AI tool that gives you a second opinion when a message looks suspicious.

You paste a suspicious SMS, WhatsApp message, email, job offer, payment request, or investment message into the application, and it analyzes the text and gives you:

a risk level
a risk score
the warning signs it detected
recommended actions

The idea is simple:

Pause before you trust.

Why I Built It

I wanted to build something that could actually be useful to someone I know.

Scam messages are becoming increasingly convincing. They often create urgency, impersonate companies or people, promise unrealistic rewards, or ask for sensitive information.

The problem is not always knowing that something feels suspicious.

The problem is understanding why it is suspicious.

That's what ScamShield tries to help with.

Instead of just saying:

"This is a scam."

it explains the signals that made the message risky and gives the user safer next steps.

Demo

Here is a short demonstration of ScamShield Local:

https://youtu.be/zkFD0ySIWoI

In the demo, I paste a suspicious message into the application and let the local AI analyse it.

The application identifies the warning signs, produces a risk score, and recommends what the user should do next.

Code

The complete project is available here:

https://github.com/Samearth17/scamshield-local

How I Built It

I wanted the application to be small, fast, and easy to run locally.

The stack is:

FastAPI for the backend
HTML, CSS, and JavaScript for the frontend
Ollama for local AI inference
an open-weight model running locally
Pydantic for structured response validation
pytest for automated testing

The architecture looks like this:

Browser
   |
   | POST /analyze
   v
FastAPI
   |
   | Local request
   v
Ollama + Open-Weight Model
   |
   v
Structured JSON
   |
   v
Risk Analysis
   |
   +-- Risk Level
   +-- Risk Score
   +-- Red Flags
   +-- Recommended Actions

The application doesn't require a hosted AI API or a database.

The message is sent to the local FastAPI application, which communicates with Ollama running on the same machine.

I also added validation and safeguards around the model response so that malformed output does not directly reach the user.

The risk score is normalized so that the displayed score always agrees with the risk level. For example, a HIGH-risk result cannot end up displaying something contradictory like 10/100.

Why Local Open-Source AI?

This is probably my favorite part of the project.

A person might paste a very personal message into a scam detector. It could contain a phone number, someone's name, payment information, or part of a private conversation.

I did not want the basic workflow to require sending that information to a third party AI API.

With local inference, the model can run directly on the user's machine.

That means:

the message doesn't need to be sent to a third-party AI provider
the user has more control over their data
there is no requirement for a hosted AI API key
the underlying model can be changed for another compatible open-weight model
the application can continue to work independently of a hosted AI service

For this particular problem, open and local AI isn't just a technical choice it is part of the product's privacy story.

Building It With AI

I also used AI coding tools during development to accelerate implementation, debugging, testing, and iteration.

But the goal wasn't to simply generate a chatbot and call it a project.

The interesting work was deciding:

what information the user actually needs
how the model should structure its response
how to handle malformed model output
how to keep the risk score consistent
what safety guidance should appear for high-risk messages
what the application should explicitly not claim

That distinction became especially important while building a tool that deals with potentially sensitive messages.

What I Learned

One thing I learned from this project is that getting an LLM to produce an answer is relatively easy.

Getting that answer to be useful, predictable, and responsible is much harder.

I ended up spending significant effort on things that aren't immediately visible in the UI:

structured output validation
malformed-response handling
input validation
risk-score normalization
safety guidance
automated tests
clear limitations

I also learned that a small project can sometimes make a stronger demo than an overly ambitious one.

Instead of building a huge platform, I focused on solving one problem well.

Limitations

ScamShield is not a guarantee that a message is fraudulent or safe.

It only analyzes the text provided to it. It does not independently verify:

sender identity
URLs or their destinations
attachments
account activity
transaction history
the wider conversation context

A LOW risk result does not mean that a message is safe.

The application is intended to provide an additional perspective and encourage users to verify important requests independently.

Built for a Friend

The whole reason this project exists is that I wanted to build something practical for someone I know.

The workflow is intentionally simple:

Paste → Analyze → Understand → Make a safer decision

No complicated setup in the interface.

No account.

No database.

No need to send the message to a hosted AI API.

Just a small local AI tool that can help someone stop for a moment before clicking, paying, or sharing sensitive information.

Final Thoughts

This started as a weekend challenge, but I liked the idea behind it: build technology for a person, not just for a portfolio.

ScamShield Local is small, but it gave me a chance to explore local AI, structured LLM outputs, safety-focused UX, and privacy-aware application design in one project.

If you try it out, I would genuinely love to hear:

What would you want an AI scam detector to explain before you decide whether to trust a message?

GitHub: https://github.com/Samearth17/scamshield-local

Demo: https://youtu.be/zkFD0ySIWoI