DEV Community: Radhika Godambe

THE VEIL — I Built an AI Ouija Board That Runs Entirely on Your Machine 🕯️

Radhika Godambe — Sat, 31 Oct 2026 15:39:00 +0000

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

What I Built

THE VEIL is an AI-powered Ouija board that runs entirely on your local machine — no cloud, no API keys, no internet required once you've pulled the model.

You ask a question, and an ancient spirit answers. But not like a chatbot. The planchette physically glides across the board, pausing over each letter, illuminating it, and spelling out a cryptic response one character at a time. When the message is complete, it drifts to GOODBYE.

The theme said Ghost in the Machine. I took it literally: there's an LLM living inside Ollama on your laptop, pretending to be a spirit trapped behind a 19th-century parlor game. It doesn't know it's software. It speaks in fragments. It never explains itself.

The inspiration was simple. It's October 31st. What if a séance actually worked — and the spirit on the other side was a 3-billion-parameter language model running on localhost?

Demo

The experience flows like this:

Landing — A dark screen. "THE VEIL" in gold gothic lettering. Floating particles. Some questions are better left unanswered. Click ENTER THE SÉANCE.
The Board — A full CSS/SVG Ouija board fills the screen: curved alphabet rows (A–M, N–Z), numbers 0–9, YES and NO in the corners, GOODBYE at the bottom. Flickering candles at the edges. A film grain overlay. A wooden planchette with a circular viewing window hovers at center.
Ask — Type your question. Click SUMMON. The screen dims. The planchette trembles. Reaching beyond the veil...
The Response — The planchette begins to move. It glides to the first letter — the letter glows gold — the character appears in the transcript below. Then the next. And the next. Each movement is spring-animated using actual DOM coordinates, so it's pixel-accurate at any screen size.
Goodbye — When the message is complete, the planchette drifts to GOODBYE. You can ask again or end the séance.

The whole thing runs at localhost:5173 (frontend) and localhost:8000 (backend).

Code

https://github.com/radhikaaa25/the-veil

How I Built It

The Stack

Layer	Technology	Why
Frontend	React + Vite	Fast dev, hot reload
Styling	Tailwind CSS v4 + vanilla CSS	Design tokens via `@theme`, plus detailed component styles
Animation	Framer Motion	Spring physics for the planchette, `useMotionValue` + `useSpring` for natural gliding
Backend	Python + FastAPI	Thin bridge between frontend and Ollama
AI	Ollama + `llama3.2:3b`	Fully local, open-weight, no API key
Audio	Web Audio API	Ambient drone generated from oscillators — no external sound files

The Open-Source AI

The AI is Ollama running llama3.2:3b (Meta's open-weight model, 3 billion parameters). The backend sends each question to Ollama's chat API with this system prompt:

You are an ancient, mysterious spirit communicating through a Ouija board. Respond with a short, eerie, poetic, and cryptic message. Keep responses under 15 words. Never explain yourself. Avoid modern slang, emojis, or references to being an AI.

The model stays in character remarkably well at this size. Short, constrained prompts are where small open-weight models shine — you don't need GPT-4 to say "THE ANSWER LIES BENEATH WHAT YOU HAVE FORGOTTEN" in a creepy voice.

The response is sanitized server-side: stripped to uppercase, punctuation removed, collapsed to only characters that exist on the board (A–Z, 0–9, spaces). The frontend never has to guess whether a character is renderable.

The Planchette Animation

This was the hardest and most important part. The planchette doesn't use a typing effect. It physically moves.

Every letter on the board is a React ref. When the AI response arrives, the app:

Splits the response into individual characters
For each character, calls getBoundingClientRect() on that letter's DOM element
Calculates the position relative to the board container
Sets a Framer Motion spring target (stiffness: 80, damping: 22, mass: 0.8)
The planchette glides to the letter with natural deceleration
The letter illuminates with a gold glow
The character appends to the revealed text below the board
After all characters: the planchette moves to GOODBYE

Because positions are read from the DOM at animation time, the board is fully responsive. Resize the window and the planchette still lands exactly on each letter.

The Atmosphere

The board itself is pure CSS — layered gradients that simulate dark wood grain, a double border for the antique frame effect, and an inner box-shadow for depth. Typography uses Cinzel Decorative (for titles) and IM Fell English (for body text), both loaded from Google Fonts.

The particles are a <canvas> element with 40 floating golden dots that drift upward and fade. The candles are CSS animations (@keyframes flicker) with a radial gradient glow. The ambient sound is generated entirely from the Web Audio API — three sine-wave oscillators (55Hz, 220Hz, 36.7Hz) with LFO modulation for a slow, eerie drone. No audio files ship with the project.

Architecture

React (Vite :5173)
  ↓ POST /api/ask {question}
FastAPI (:8000)
  ↓ Ollama chat API
llama3.2:3b (localhost:11434)
  ↓ response
FastAPI → sanitize → {answer}
  ↓
React → split chars → animate planchette → reveal text

The backend is 2 files. The frontend is 9 components. No database, no auth, no cloud.

Why Does Open Innovation Matter?

This project only works because the AI is open and local.

It works with the lights off. Once you've pulled llama3.2:3b from Ollama, the entire séance runs without internet. The model sits on your disk. The backend talks to localhost. The frontend talks to the backend. No tokens, no rate limits, no "service unavailable."

The persona stays in character. With a closed API, you're fighting content filters. "You are a spirit communicating through a Ouija board" is exactly the kind of prompt that triggers safety guardrails on commercial models. A local open-weight model doesn't second-guess the fiction. It plays the role.

It costs nothing to run. A 3B parameter model runs comfortably on a laptop CPU. No GPU required. No billing page. No surprise invoice because your Halloween party guests asked it 200 questions.

It's private. Your questions to the spirit board stay on your machine. Nobody's logging "will I find love" or "is someone watching me" to a server in Virginia.

The model is swappable. Don't like the responses? Change OLLAMA_MODEL in .env to mistral, phi3, gemma2, or any model Ollama supports. The prompt engineering is simple enough that most models handle it well.

A closed API could technically generate the text. But it couldn't do it offline, for free, without filters, on a Halloween night with the Wi-Fi turned off for atmosphere. Open made this the experience it is.

The Spirit of It

I built this on Halloween. That wasn't an accident.

There's something about a Ouija board that a chatbot window can never replicate — the tension of watching the planchette move, letter by letter, not knowing where it's going. The pause between characters. The moment you realize the word it's spelling.

When I first got the planchette animation working and asked it "Is someone watching me?", it spelled out:

THE SHADOWS REMEMBER YOUR NAME

I was alone in my room at midnight. The candles were flickering on screen. The ambient drone was humming through my headphones. And for about three seconds, I forgot it was a language model.

That's the moment this project is for.

ScopeGuard: Privacy-First Open-Source AI Scope Creep Detector for Freelancers

Radhika Godambe — Sun, 18 Oct 2026 18:58:35 +0000

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

What I Built

Every freelance developer knows the dread of this Slack message:

"Hey! The site looks great. Quick question—can we also add user authentication, a customer admin portal, and Stripe checkout before we go live on Friday?"

Freelancers call it scope creep. In reality, it is unbilled hours, blown deadlines, and unpaid overtime. According to freelancer surveys, over 70% of independent contractors absorb unbilled client work simply because pushing back feels confrontational or risks the client relationship.

Even worse: freelancers work under strict NDAs and confidentiality agreements. You cannot simply upload your client’s proprietary statement of work (SOW) or confidential emails into ChatGPT or closed cloud APIs without violating client trust and contract terms.

Introducing ScopeGuard 🛡️

Protect your time. Get paid for every extra mile.

ScopeGuard is a 100% local, privacy-first AI application that acts as an objective contractual shield. It automatically analyzes incoming client messages against original signed agreements, flags scope creep with exact clause citations, drafts boundary-enforcing replies in multiple tones, and turns unpaid requests into billable Change Order Quotations with 1-click PDF exports.

Who Would Pay For It?

Freelance Web & Mobile Developers: Who lose an average of $2,000–$8,000 annually in unbilled "small favors".
Design & Digital Agencies: Managing multiple simultaneous client contracts who need objective change-order enforcement.
Independent Consultants & Contractors: Who want an objective, neutral third party to draft polite, contract-backed pushback.

If ScopeGuard captures just one extra change order for $750, a $15/month subscription pays for itself for 4 years on day one.

Code

radhikaaa25 / ScopeGuard

ScopeGuard 🛡️

Protect your time. Get paid for every extra mile.

ScopeGuard is an open-source, privacy-first AI application designed specifically for freelancers, agencies, and independent contractors to detect and prevent scope creep. By automatically comparing incoming client requests against signed project agreements and statement-of-work (SOW) documents, ScopeGuard identifies out-of-scope work, generates boundary-enforcing client replies in multiple tones, and builds deterministic change-order quotations with instant PDF exports.

Developed for the Hacktoberfest Open-Source AI Challenge under the theme Side Hustle.

💡 The Problem & The Solution

The Problem: Freelancers frequently agree to fixed-scope projects, only for clients to request "small tweaks" and extra features disguised as minor additions (e.g., authentication, dark mode, blog CMS, payment gateways). Over time, this leads to unbilled hours, delayed delivery, and client tension.
The Solution: ScopeGuard acts as an objective, contractual shield. It extracts clauses from your agreements, semantically compares incoming messages against agreed deliverables…

View on GitHub

Repository: https://github.com/radhikaaa25/ScopeGuard

ScopeGuard is built as a complete, production-grade application:

Backend: Python 3.11+ / Django 5 with Django REST Framework
Frontend: React 19, TypeScript, Vite, Tailwind CSS (sleek dark mode design system), and Recharts
PDF Engine: Deterministic ReportLab document generation
License: Open-source under MIT

How I Built It

ScopeGuard was engineered from scratch around a local-first open-source AI pipeline:

┌────────────────────────────────────────────────────────────────────────┐
│                        SCOPEGUARD ARCHITECTURE                         │
└────────────────────────────────────────────────────────────────────────┘

 ┌──────────────────────────────────────────────────────────────────────┐
 │                  MODERN REACT FRONTEND (PORT 5173)                   │
 │  ┌────────────────────┐  ┌─────────────────────┐  ┌───────────────┐  │
 │  │ Vite + React 19    │  │ Tailwind Dark Theme │  │ React Router  │  │
 │  └────────────────────┘  └─────────────────────┘  └───────────────┘  │
 │  ┌────────────────────┐  ┌─────────────────────┐  ┌───────────────┐  │
 │  │ Recharts Analytics │  │ Lucide UI Icons     │  │ Axios Client  │  │
 │  └────────────────────┘  └─────────────────────┘  └───────────────┘  │
 └──────────────────────────────────┬───────────────────────────────────┘
                                    │ HTTP / REST API (Port 8000)
                                    ▼
 ┌──────────────────────────────────────────────────────────────────────┐
 │                     DJANGO REST FRAMEWORK BACKEND                    │
 │  ┌────────────────────────────────────────────────────────────────┐  │
 │  │ Endpoints: /api/projects  /agreements  /analyses  /quotations   │  │
 │  └────────────────────────────────┬───────────────────────────────┘  │
 │          ┌────────────────────────┼────────────────────────┐         │
 │          ▼                        ▼                        ▼         │
 │  ┌───────────────┐        ┌────────────────┐       ┌───────────────┐ │
 │  │ SQLite / ORM  │        │ ReportLab PDF  │       │ Document Text │ │
 │  │ Database      │        │ Change Orders  │       │ PDF, DOCX, TXT│ │
 │  └───────────────┘        └────────────────┘       └───────────────┘ │
 └──────────────────────────────────┬───────────────────────────────────┘
                                    │ Local Pipeline (Zero Cloud APIs)
                                    ▼
 ┌──────────────────────────────────────────────────────────────────────┐
 │                    LOCAL OPEN-SOURCE AI PIPELINE                     │
 │  ┌────────────────────────┐          ┌────────────────────────────┐  │
 │  │ ChromaDB Vector Store  │          │ SentenceTransformers       │  │
 │  │ (Local HNSW Index)     │◄────────►│ (all-MiniLM-L6-v2)         │  │
 │  └───────────┬────────────┘          └──────────────┬─────────────┘  │
 │              │                                      │                │
 │              ▼                                      ▼                │
 │  ┌────────────────────────┐          ┌────────────────────────────┐  │
 │  │ Ollama Local LLM       │          │ Local Semantic Fallback    │  │
 │  │ (llama3 / qwen3)       │◄────────►│ (Deterministic Regex/NLP)  │  │
 │  └────────────────────────┘          └────────────────────────────┘  │
 └──────────────────────────────────────────────────────────────────────┘

The Open AI Components

Local LLM Inference via Ollama: All deep reasoning and contractual extraction runs locally through Ollama using open-weight models such as llama3:8b, qwen3:8b, or gemma2:9b. No requests leave your computer.
Local Vector Search with ChromaDB: When an agreement (PDF, DOCX, or TXT) is uploaded, it is chunked and indexed into an on-device ChromaDB vector database with cosine similarity search.
Local Embeddings with SentenceTransformers: Semantic chunking uses all-MiniLM-L6-v2 locally via PyTorch—delivering millisecond semantic retrieval with zero cloud dependencies.
Resilient Local NLP Fallback Engine: If a freelancer is running on battery or Ollama is offline, ScopeGuard automatically falls back to an internal deterministic regex and semantic rule engine. The app never crashes and remains 100% functional offline.
Deterministic Pricing Engine: Financial calculations (hourly rates, line items, and totals) are strictly deterministic math—preventing LLM hallucination on financial agreements.

Why Does Open Innovation Matter?

Open innovation is not just an implementation detail for ScopeGuard—it is the entire reason the product can exist.

Client Confidentiality & NDA Compliance: Freelancers cannot paste client agreements, trade secrets, or unreleased feature roadmaps into OpenAI or cloud LLM endpoints. Closed APIs introduce data leakage risks and terms-of-service surveillance. Open-weight models running on-device guarantee 100% data privacy and NDA compliance.
Zero Marginal Inference Cost: For a side hustle or bootstrapped solo product, closed API rate limits and token fees eat margins alive. By leveraging open-weight models, ScopeGuard runs with $0 in recurring inference costs.
No Vendor Lock-In or Arbitrary De-platforming: Closed AI providers frequently deprecate model endpoints, alter alignment rules, or raise prices without notice. Open-weight models provide perpetual reproducibility and reliability.
Targeted Semantic Precision: By combining local vector search with open embeddings, we achieve high-precision clause retrieval without paying to feed entire 50-page contracts into huge cloud context windows.

My Agent Session

ScopeGuard was pair-programmed using DevRelay and the Antigravity agentic workflow to scaffold the Django REST architecture, build the local ChromaDB pipeline, and implement the React 19 UI system.

My First User

To test ScopeGuard in the real world, I put it into the hands of my friend Sarah, a freelance frontend developer who builds custom Next.js web applications for local businesses.

She was in the middle of a project where the client sent this exact message:

"Could you also set up a members-only portal so our customers can create accounts, log in, and view their past orders?"

We uploaded her original project agreement into ScopeGuard and ran the client's message through the analyzer:

Result: ScopeGuard flagged the request as OUT_OF_SCOPE with 92% confidence.
Cited Clause: EXCLUDED FROM SCOPE: User authentication, customer login systems, or backend databases.
Action: ScopeGuard generated a Professional reply acknowledging the idea, explaining that it falls outside the initial milestone, and generated a $1,350 Change Order Quotation (18 hours @ $75/hr).

Sarah sent the response directly to the client. Within two hours, the client replied: "Understood! Let's approve the change order so we can get it into the next phase."

Her feedback:

"The hardest part of freelancing is telling a client 'no' without sounding difficult. ScopeGuard made it completely objective—it wasn't me saying no, it was the contract we both signed. I would easily pay $20 a month for this peace of mind."

Prize Categories

Hacktoberfest Open-Source AI Challenge: Week 2 — Side Hustle (Main Track)
Best Use of Gemma (Open-Weight Model Category): Tested and fully compatible with gemma2:9b and gemma2:2b on Ollama for efficient on-device contractual inference.

Protect your time. Get paid for every extra mile. Check out the open-source repo on GitHub and star the project! 🛡️

Touch Grass: Natural Language Outdoor Discovery

Radhika Godambe — Sun, 11 Oct 2026 19:57:21 +0000

Submission for the Hacktoberfest Open-Source AI Challenge – Week 1: Touch Grass

What I Built

Finding somewhere to go outdoors shouldn't require browsing through multiple websites, filtering endless map results, or scrolling through hiking forums.

Touch Grass is an open-source, AI-powered outdoor discovery application that lets users search for trails, parks, and running clubs using natural language.

Instead of navigating multiple filters, users can simply ask:

"Show me easy shaded trails under 3 miles."
"Which parks in Austin have restrooms and allow dogs?"
"Find me a weekend run club that runs less than 5 miles."

The application uses an LLM-powered Text-to-SQL agent to translate these questions into SQLite queries, retrieve matching records, and display the results in a responsive dashboard.

The idea is simple: spend less time searching for outdoor activities and more time actually doing them.

Demo

Application Features

1. Natural Language Search

Users can enter questions directly into the search bar or choose from predefined example queries to get started.

2. SQL Query Inspector

The application displays the SQL generated by the model, allowing users to see how their natural language request was translated into a database query.

3. Dynamic Results Table

Results are displayed in a responsive table with formatting based on the returned data:

Color-coded difficulty badges (Easy, Moderate, Hard).
Readable boolean indicators (✅ Yes / ❌ No).
Trail distances in miles.
Location and activity information.

4. Loading and Error States

The interface handles loading, empty results, and invalid queries with appropriate feedback.

Example Interaction

User input:

"Show me easy trails under 3 miles with shade."

Generated SQL:

SELECT
    name,
    length_miles,
    has_shade,
    location
FROM trails
WHERE LOWER(difficulty) = 'easy'
    AND length_miles < 3
    AND has_shade = 1
LIMIT 50;

Example Results:

Trail	Distance	Shade	Location
Sunset Ridge Loop	1.8 mi	✅ Yes	Austin, TX
Lady Bird Lake	1.3 mi	✅ Yes	Austin, TX
Piedmont Park Loop	2.4 mi	✅ Yes	Atlanta, GA

The generated SQL is also visible in the interface, making the application's behavior easier to understand and debug.

Code

The project is open-source and organized as a full-stack monorepo.

GitHub Repository: (https://github.com/radhikaaa25/touch-grass)

Tech Stack

Layer	Technologies	Purpose
Backend	Python 3.11+, FastAPI, Uvicorn	REST API
AI Agent	LiteLLM, Gemini / Open-weight Llama	Natural Language to SQL
Database	SQLite3	Outdoor activity storage
Frontend	React 19, Vite, Tailwind CSS v4	User interface
Tooling	Pydantic v2, TypeScript	Data validation and type safety

Architecture

The application follows a straightforward request-response pipeline:

             User
               |
               v
      React Frontend
               |
               v
        FastAPI Backend
               |
               v
       Text-to-SQL Agent
               |
               v
      LiteLLM Model Router
               |
               v
       Generated SQL Query
               |
               v
        Query Validation
               |
               v
         SQLite Database
               |
               v
         JSON Response
               |
               v
       Dynamic Results UI

How I Built It

1. Schema-Grounded Text-to-SQL

One of the main challenges was making sure the language model generated queries using actual database tables and columns rather than inventing its own structure.

To address this, the backend retrieves the SQLite schema and includes it in the agent's system prompt.

The model receives both the database structure and a set of query-generation rules.

SYSTEM_PROMPT = f"""
You are a SQL query generator for an outdoor activities SQLite database.

DATABASE SCHEMA:
{get_schema_string()}

RULES:
1. Output ONLY a single valid SQLite SELECT query.
2. Do not include markdown, code fences, or explanations.
3. Never generate INSERT, UPDATE, DELETE, DROP, ALTER, or CREATE statements.
4. Use only the tables and columns provided in the schema.
5. Boolean columns (has_shade, has_restrooms, allows_dogs)
   use 1 for true and 0 for false.
6. Use LOWER() for case-insensitive string comparisons.
7. Always include 'name' and 'location' in the results.
8. Limit results to a maximum of 50 rows.
"""

This helps constrain the model's output and makes the generated queries more consistent with the available data.

2. Model-Agnostic Integration with LiteLLM

I used litellm to keep the application independent of a single LLM provider.

The backend can be configured to use Google Gemini, local open-weight models through Ollama, or supported cloud-hosted models through providers such as Groq.

The model can be changed through an environment variable without rewriting the agent logic.

response = litellm.completion(
    model=self.model,
    messages=[
        {
            "role": "system",
            "content": SYSTEM_PROMPT
        },
        {
            "role": "user",
            "content": question
        },
    ],
    temperature=0.0,
    max_tokens=300,
)

This also makes it possible to experiment with different models and compare their Text-to-SQL performance.

3. SQL Validation and Error Handling

Since the SQL is generated by a language model, it needs to be checked before execution.

The backend includes a validation layer that:

Removes surrounding Markdown code fences when present.
Checks that the generated query begins with SELECT.
Rejects queries that do not satisfy the expected format.
Handles SQLite execution errors using try/except sqlite3.Error.
Returns readable error messages to the frontend.

These checks provide an initial safeguard against unintended queries. For a production deployment, I would strengthen this further with SQLite read-only connections, single-statement enforcement, and stricter SQL validation rather than relying on prompt instructions or prefix checks alone.

4. Building the Frontend

I wanted the interface to feel like an outdoor discovery tool rather than a conventional database search application.

The frontend uses React, Vite, and Tailwind CSS with an earth-toned visual theme.

Design choices:

Forest greens (#1d3818 to #8dba7e), bark browns, and soft sky accents.
A prominent natural-language search bar.
Example query chips for first-time users.
A terminal-inspired SQL inspector.
Dynamically generated result columns based on the API response.
Custom formatting for distances, difficulty levels, and boolean fields.
Responsive layouts for different screen sizes.

The frontend does not need to know which database table the user is querying beforehand. It builds the results table from the returned column names and values.

This allows the same interface to display trails, parks, and running clubs without separate result components for every category.

Why Open Innovation Matters

I wanted Touch Grass to be easy to run, modify, and extend without depending entirely on proprietary services.

Three aspects of open innovation influenced the project.

1. Local Model Support and Privacy

Outdoor discovery applications can involve location information and personal activity preferences.

By supporting local models through Ollama, Touch Grass provides an option to process natural-language queries locally instead of sending them to a cloud-hosted LLM.

This gives developers more control over where their data is processed.

2. Flexibility Across AI Providers

Using LiteLLM allows developers to experiment with different supported models without changing the application's core architecture.

Someone running the project locally can choose an open-weight model, while another developer can configure a hosted provider.

The application is not tied to one model or vendor.

3. Community-Driven Outdoor Data

SQLite provides a lightweight starting point for maintaining a curated collection of trails, parks, and running clubs.

The project can be extended with additional locations, activity categories, and community-contributed datasets.

The goal is to make outdoor discovery accessible and adaptable to different cities and communities.

My Agent Session

I used Google DeepMind Antigravity during development to assist with scaffolding, implementation, and debugging.

The development process involved:

Setting up the FastAPI and React monorepo.
Implementing the Text-to-SQL agent and database integration.
Building the search interface and dynamic results table.
Resolving Python dependency and virtual environment configuration issues.
Testing backend functionality and verifying the frontend build.

Antigravity was useful for iterating across the backend and frontend while keeping the application architecture consistent.

Challenges and Learnings

The most interesting part of building Touch Grass was connecting natural-language input to structured database operations.

A few key takeaways:

Schema context matters. Providing the model with the actual database structure makes Text-to-SQL generation more reliable than relying on generic instructions.

LLM output still needs validation. Even with explicit prompting, generated SQL should be treated as untrusted input.

Model flexibility is useful. Separating the model provider from the application logic makes experimenting with local and hosted models significantly easier.

A simple interface can hide a fairly interesting backend. From the user's perspective, the entire workflow is just asking a question and viewing matching outdoor activities.

What's Next?

Some improvements I'd like to explore:

Integrating OpenStreetMap data for broader location coverage.
Adding geolocation-based searches for nearby trails and parks.
Supporting community submissions for new outdoor locations.
Improving SQL validation and database access restrictions.
Testing Text-to-SQL accuracy across different open-weight models.
Adding map-based visualization alongside the existing results table.

Prize Categories

Primary Challenge: Hacktoberfest Week 1 – Touch Grass

Featured Categories:

Best Use of Open-Source AI / Open Weights
Full-Stack Developer Experience

Built with Python, React, SQLite, and LiteLLM.

Less scrolling. More strolling. 🌿

Source code: GitHub – Touch Grass