DEV Community: Aniket Singanjude

Midnight Oracle: An Open-Weight AI Fortune Teller Beyond the Veil

Aniket Singanjude — Sun, 01 Nov 2026 05:14:53 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Midnight Oracle is an AI-powered digital fortune teller that brings a mysterious supernatural experience to the web.

Inspired by Halloween, tarot symbolism, and the idea of mysterious entities communicating from beyond the veil, I wanted to build something more immersive than a conventional AI chatbot.

Users enter a mystical chamber, interact with an animated 3D crystal ball, select a tarot-inspired reading category, and ask questions about:

Love & Relationships – Explore fictional readings about relationships and emotional connections.
Career & Destiny – Discover imaginative perspectives about career paths and opportunities.
Luck & Fortune – Receive mysterious readings filled with symbolic signs.
General Mysteries – Ask the Oracle anything and uncover an unexpected fictional prophecy.

The Oracle responds with a personalized fortune, symbolic signs, a reflective message, and mystical elements such as a lucky colour, number, and object.

The experience features an original gothic-inspired interface with a 3D crystal ball, floating tarot cards, an animated ghost entity, atmospheric particles, and subtle lighting effects.

Midnight Oracle is designed purely for entertainment. Its fortunes are fictional interpretations, not actual supernatural predictions.

Demo

Live Demo: [Insert deployed application URL]

Video Demonstration: [Insert video link]

Code

GitHub Repository: https://github.com/aniket937/Midnight-Oracle

Explore the complete project, including its frontend, backend, AI integration, 3D components, and setup instructions.

How I Built It

I built Midnight Oracle using a modern full-stack architecture combining web technologies, 3D rendering, and open-weight AI.

Frontend:

Next.js 16
React 19
TypeScript
Tailwind CSS v4
Three.js
React Three Fiber
Drei

Backend:

Python 3.13
FastAPI
Pydantic
HTTPX

AI Integration:

OpenRouter API
Open-weight Gemma / Qwen model: [Insert exact model ID]
Ollama for local inference (if implemented)

How the AI Works

Users submit a question along with a selected fortune category.

The FastAPI backend processes the request and sends it to the configured open-weight language model using a carefully designed system prompt that defines the Midnight Oracle's personality.

The model generates a structured response containing:

Fortune title
Mystical introduction
Main fortune interpretation
Three symbolic signs
Reflective message
Lucky colour, number, and object

Pydantic validates the response before it is displayed on the frontend as an animated prophecy card.

The frontend handles the 3D environment, tarot interactions, crystal ball animations, fortune generation experience, and reading history.

Why Does Open Innovation Matter?

The most important decision in this project was making an open-weight AI model central to the experience rather than relying entirely on a proprietary AI API.

Using open-weight models gives Midnight Oracle flexibility and independence.

1. Model Freedom

The application can be configured to use different compatible open-weight models instead of being permanently tied to one model provider.

2. Local AI Possibility

With a local Ollama setup, the Oracle can generate fortunes without sending prompts to an external inference service. Once the model is downloaded, local inference can work without an internet connection.

3. Greater Control

The system prompt and model configuration can be modified to change the Oracle's personality, response style, and behaviour.

4. Reduced Provider Dependency

The application architecture separates AI inference from the frontend. This makes it easier to replace or change the inference provider without rebuilding the entire experience.

Open innovation makes the project more adaptable and gives users more control over how their AI experience operates.

The Spirit of It

There is something fascinating about asking a question in an empty, dark chamber and receiving a mysterious response from an entity that doesn't really exist.

That was the inspiration behind Midnight Oracle.

I wanted to combine the atmosphere of Halloween, the symbolism of tarot cards, and the possibilities of open-weight AI into one interactive experience.

The crystal ball represents the unknown, the ghost represents the mystery, and the AI represents the intelligence hidden inside the machine.

Not every mystery needs an answer. Some just need an Oracle.

DueWise: Turn Your Syllabus into a Study Plan with Open-Weight AI

Aniket Singanjude — Sun, 25 Oct 2026 10:29:45 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Meet DueWise — an AI-powered academic planning assistant that helps students spend less time organizing their work and more time actually getting it done.

Students receive syllabuses, assignment briefs, examination notices, and course materials throughout the semester. Manually reading these documents, extracting deadlines, creating tasks, planning revision sessions, and deciding what to study next can become a project of its own.

DueWise is designed to eliminate that repetitive work.

Upload an academic document once, and DueWise helps turn it into an actionable academic workflow.

Here is what it does:

Document to tasks: Upload PDF, DOCX, or TXT files and extract their contents automatically.
AI-powered analysis: Generate summaries, identify academic requirements, and suggest assignments, deadlines, and actionable tasks.
Review before saving: Edit and confirm AI-generated suggestions instead of blindly trusting them.
Weekly study planning: Organize tasks around deadlines, available study time, and estimated effort.
Revision checklists and flashcards: Turn course material into concise revision prompts for active recall.
The “What Should I Do Now?” feature: Recommend one practical next action instead of leaving students overwhelmed by a long to-do list.

The goal is simple: reduce the friction between receiving academic work and knowing what to do next.

Demo

Live demo / video: [Add your deployed application or demo video link here.]

The project can also be run locally using the setup instructions in the repository README.

Code

GitHub repository: https://github.com/aniket937/DueWise

The repository contains the frontend, backend, setup scripts, documentation, and tests.

How I Built It

DueWise uses a full-stack architecture combining a modern web interface, a local database, document-processing tools, and an open-weight AI model accessed through OpenRouter.

Technology stack:

Frontend: Next.js 16, React, TypeScript, and Tailwind CSS v4.
Backend: Python and FastAPI.
Database: SQLite with SQLAlchemy and aiosqlite.
Document processing: PyMuPDF for PDFs and python-docx for Word documents.
AI integration: OpenRouter with a configurable open-weight language model.
Testing: pytest, Ruff, TypeScript checks, and the Next.js production build.

The AI analysis pipeline extracts text from uploaded documents and sends the relevant text to the configured OpenRouter model. The model proposes structured academic information, which the backend validates before presenting it to the user.

I also wanted the core application to remain useful without an AI API key. Document extraction, task management, database persistence, and deterministic task prioritization can work in Demo Mode without live model inference.

The system keeps extracted task suggestions separate from confirmed tasks, so users retain control over their academic schedules.

Why Does Open Innovation Matter?

For this project, open innovation is about flexibility, transparency, and avoiding unnecessary dependence on a single proprietary model.

DueWise uses an open-weight model through OpenRouter rather than hardwiring the application to a single closed-model provider. The model identifier is configurable, which makes experimenting with alternative open-weight models easier without redesigning the entire application.

This matters because different models can offer different trade-offs in reasoning quality, structured output, latency, and cost. Keeping the model integration separate from the application logic makes those trade-offs easier to evaluate.

Open innovation also influenced how the application handles everyday work:

Local document processing: PDF and DOCX text extraction happens in the backend before the AI request.
Local data storage: Academic tasks and application data are stored in SQLite rather than requiring a hosted database.
User control: AI-generated tasks require review and confirmation.
A useful fallback: Core task management and deterministic prioritization do not depend on a live AI request.
Model flexibility: The runtime model can be changed through configuration when another suitable open-weight model is available.

There is an important trade-off: DueWise uses hosted inference through OpenRouter. When users request AI analysis, relevant extracted document text is sent to the configured provider. Live AI analysis therefore requires an internet connection, and this implementation does not claim fully offline AI processing.

For me, openness is not just about choosing a model. It is also about building an application whose components can be inspected, adapted, and replaced without having to rewrite the whole product.

The Lazy Payoff

The best part of DueWise is the reduction in repeated decisions.

Instead of manually copying deadlines from a syllabus, creating separate tasks, and figuring out how to distribute everything across the week, the student starts with one upload and reviews the proposed plan.

The “What Should I Do Now?” feature tackles another common problem: having so many tasks that choosing the first one becomes difficult.

DueWise recommends a manageable next step based on deadlines, priority, remaining effort, and progress. The underlying prioritization also works without an AI request.

I have not established a measured before-and-after time-saving benchmark yet, so I will not claim a specific number of minutes saved. The intended payoff is fewer manual steps, less administrative effort, and a clearer path from a pile of academic documents to the next task.

Prize Categories

This submission focuses on the overall Hacktoberfest Open-Source AI Challenge.

I have not selected a partner prize category because the current implementation does not establish that it qualifies for a specific partner category.

SkinSense: Building a Skincare Side Hustle with Open AI

Aniket Singanjude — Mon, 19 Oct 2026 06:31:09 +0000

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

What I Built

I built SkinSense, a personalized skincare companion designed to make skincare decisions easier to understand.

The idea came from a real problem: choosing skincare products is confusing. People often struggle to understand their skin type, compare products with similar ingredients, build a routine, and figure out what different ingredients actually do. Many end up relying on random internet searches and trial and error.

I wanted to bring these activities into one simple application.

SkinSense currently includes a frontend with 14 pages and backend API flows for profile management, routine generation, ingredient explanations, and product checking.

The commercial direction is to make SkinSense useful for independent skincare consultants and small beauty studios. They could use a tool like this to organize client-provided information, explain ingredients in simpler language, and prepare personalized skincare education materials more efficiently.

The potential business model is a paid professional workspace. The idea is to save repetitive work while helping consultants provide clearer explanations to their clients. This business model still needs validation with real potential customers.

SkinSense is a skincare education and decision-support tool, not an AI dermatologist. It does not replace professional medical advice or guarantee that a product will work for everyone.

Demo

GitHub Repository:

https://github.com/aniket937/SkinSense

Live Demo / Video:

[Add your deployed application URL or demo video here.]

The demo should show the profile workflow, routine generation, ingredient explanation, and product-checking experience.

Code

Repository: https://github.com/aniket937/SkinSense

The frontend uses Next.js 16, React 19, and Tailwind CSS v4. The backend uses FastAPI and Python 3.13.

The current prototype has been built with separate frontend pages and backend API contracts so the main user flows can be developed and tested independently.

How I Built It

I used Next.js, React, TypeScript, and Tailwind CSS v4 for the frontend, with FastAPI and Python 3.13 on the backend.

The current application includes workflows for:

Creating and managing a user profile.
Generating a skincare routine.
Explaining skincare ingredients.
Checking product information.
Handling backend responses through structured API contracts.

The frontend production build passes, and the current backend test suite includes basic health and secret-handling checks.

One important limitation is that the current AI endpoints still use deterministic fallback responses for demonstration. A live open-weight model integration remains an important engineering step, and OCR processing is currently unavailable. I have kept these limitations explicit rather than presenting simulated results as live AI output.

My intended architecture places an open-weight model behind a replaceable backend adapter. The goal is to use it for contextual routine generation, ingredient explanations, product interpretation, and personalized question answering, with structured output validation and safety controls surrounding the model.

Why Does Open Innovation Matter?

Skincare information can involve personal concerns, routines, product histories, and conversations. I believe the architecture should give developers meaningful control over how that information is processed.

An open-weight AI approach could make it possible to:

Run inference locally or in a controlled environment when practical.
Evaluate and replace models without rewriting the entire application.
Customize prompts and behavior for a specific skincare workflow.
Reduce dependence on a single proprietary model provider.
Explore different cost and deployment options as the product grows.

Open AI does not automatically make an application private, safe, or free to run. Those benefits depend on the actual model, runtime, hosting arrangement, and application security.

For SkinSense, the aim is to combine open-model flexibility with reliable data handling, clear uncertainty, and safety validation.

The live open-weight model integration is not yet complete in this prototype, so these are intended architectural benefits rather than verified results from a deployed model.

My Agent Session

I used OpenCode to help with development, implementation planning, and debugging.

DevRelay agent session: [Add the actual shareable session link if available.]

My First User

The idea was inspired by a real person's confusion around skincare routines, product selection, and ingredient information.

I have not confirmed a paying customer or a validated willingness to pay for the professional version yet. The next step is to put the workflow in front of independent skincare consultants, gather feedback, and learn which parts genuinely save them time.

PlantWise AI: Bringing Open-Weight AI to Real-World Gardening | Hacktoberfest 2026

Aniket Singanjude — Sun, 11 Oct 2026 13:47:09 +0000

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

What I Built

I built PlantWise AI, a location-aware plant discovery and growing suitability application that helps people understand plants and explore whether they may be suitable for growing in their area.

The idea started with a simple question: What if someone could enter the name of a plant, select their location, and understand its growing requirements before deciding to grow it?

PlantWise AI brings plant information, location-based growing suitability, and AI-assisted gardening guidance into one application.

Users can explore a plant, provide their location, review its growing requirements, and get guidance through an AI assistant. Instead of keeping people limited to reading about plants online, the goal is to help them take that knowledge outside, start exploring plants, and make more informed decisions about gardening.

The project is designed for beginners, gardening enthusiasts, and people interested in growing plants at home.

One important design decision is that the suitability engine does not depend on a language model. The core application can continue working even when the hosted AI assistant is unavailable.

Demo

Live application: https://plantwise-1.onrender.com/

The frontend and FastAPI backend are deployed on Render.

The demo showcases the plant discovery experience, location-based growing suitability, and AI-assisted plant guidance.

Code

GitHub repository: https://github.com/aniket937/PlantWise

aniket937 / PlantWise

PlantWise AI

A growing-suitability assistant for crops and vegetables. Pick a plant, enter a location, and the app compares the site's historical climate against that plant's documented agronomic requirements — and explains the reasoning.

The suitability verdict is not a ratio or a score. It is a weighted rule-based assessment: each requirement (cold tolerance, heat tolerance, frost risk, growing-window length, water balance, soil, sunlight) is evaluated against a documented range and reported as pass / caution / fail / not assessed, and the verdict is reached from those. Unknown values are reported as unknown rather than guessed.

The project is deliberately honest about its limits: climate values are climatological normals for a reanalysis grid cell, not a forecast, and a positive verdict is a good signal, not a guarantee.

Repository layout

backend/ — FastAPI application, SQLAlchemy persistence, climate + AI services, suitability engine, pytest suite.
frontend/ — Next.js 16 application…

View on GitHub

How I Built It

I built PlantWise AI using Next.js, React, TypeScript, Tailwind CSS, Python, and FastAPI.

The frontend provides the user interface, while the FastAPI backend handles application APIs, configuration, and AI integration. The project is deployed on Render, with the frontend and backend running as separate services.

For the AI assistant, I integrated the open-weight Gemma model google/gemma-4-26b-a4b-it:free through OpenRouter.

Initially, I planned to run an AI model locally using Ollama. However, my machine did not have Ollama installed, and downloading a multi-gigabyte model was not practical given my available disk space and the hackathon deadline.

Instead of abandoning the AI feature, I adapted the architecture to use hosted inference with an open-weight model. This allowed me to integrate the assistant without storing the model weights on my laptop.

The main technologies used were:

Frontend: Next.js, React, TypeScript, and Tailwind CSS.
Backend: Python and FastAPI.
AI: Gemma open-weight model accessed through OpenRouter.
Hosting: Render.
Version control: GitHub.

A key architectural decision was keeping the suitability engine independent of the LLM. The AI assistant provides additional explanations and guidance, but the core application does not need a language model for every operation.

This separation also makes failures easier to handle: when the hosted assistant is unavailable, the rest of the application can remain usable.

Why Does Open Innovation Matter?

For PlantWise AI, open innovation was not just a technology choice. It helped me build around the constraints I actually had.

1. Open-weight AI made the project practical

Running a large model locally was not feasible on my laptop because of storage constraints. Using an open-weight Gemma model through OpenRouter allowed me to integrate AI without downloading several gigabytes of model weights.

This made it possible to focus my limited development time on building the actual product rather than setting up local inference infrastructure.

2. The model is replaceable

I wanted the application to depend on a clearly defined AI service rather than being permanently tied to one model.

Using a configurable model ID means I can evaluate other compatible open-weight models in the future. Different models can be tested for response quality, latency, cost, and suitability for plant-care questions without redesigning the entire application.

This flexibility is valuable because an AI model that works well today may not be the best choice as better models become available.

3. Open innovation helped me build within limited resources

A hackathon project should demonstrate useful engineering, not require expensive infrastructure before it can be tested.

The hosted free-model option allowed me to start experimenting without purchasing dedicated inference hardware or downloading a local model. Free access has provider limits and may change, so this does not mean the application is guaranteed to cost nothing to operate indefinitely.

4. I separated AI from the core application

I did not want a language model failure to make the entire product unusable.

Plant information and growing suitability remain separate from the hosted AI assistant. This creates a more resilient architecture and reduces unnecessary dependence on model availability.

5. Transparency matters as much as intelligence

A language model can produce convincing explanations even when the underlying information is incomplete. For a gardening application, that can lead to poor decisions.

My approach is to keep the suitability assessment separate from AI-generated explanations. Environmental suitability should be based on available supporting information, and missing data should not be disguised as certainty.

What Open Innovation Does Not Solve

The AI assistant still requires an internet connection because inference is hosted through OpenRouter. User context sent to the provider is also subject to the provider's data-handling policies.

The current architecture does not claim fully offline AI or complete local data privacy. Instead, it demonstrates a practical way to use an open-weight model while retaining the flexibility to change models and keeping the core application independent of the AI service.

For me, this is the value of open innovation: it provides alternatives, flexibility, and opportunities to build useful software without assuming access to expensive hardware or proprietary model infrastructure.

How PlantWise AI Fits the "Touch Grass" Theme

The theme is about making the screen the shortest part of the experience.

PlantWise AI approaches this through plant discovery and growing guidance. A user can learn about a plant, understand its requirements, and use that information to decide what to explore or grow in the real world.

The long-term goal is to make the transition from online information to offline action easier: choosing a plant, observing local growing conditions, preparing a garden, or starting a small growing project.

The application is not intended to replace real-world observation or local agricultural expertise. It is intended to help people get started with better information.

Prize Categories

Best Use of Render
Best Use of Gemma