DEV Community: Devasish Mishra

LeakLens: A Swiss-Editorial Financial Autopilot Powered by TabPFN-3.5 That Audits Messy Bank CSVs

Devasish Mishra — Mon, 26 Oct 2026 06:47:22 +0000

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

Links & Quick Links

Live Interactive Workbench: https://leaklens-web.onrender.com
GitHub Repository: https://github.com/TechGenDM/LeakLens
FastAPI Analytical Backend: https://leaklens-api-akh1.onrender.com

(Judge Quickstart: Click *01 INDIE DEV SAAS, **02 STUDENT TRIAL CREEP, or 03 FREELANCER CASHFLOW at the top of the workbench to run real in-context TabPFN inference with zero CSV upload required!)*

1. The Problem: The $133/Month "Laziness Tax"

Every month, millions of us download raw bank, credit card, or UPI statement CSVs with the intention of doing a proper audit. And almost every month, those files sit unopened in ~/Downloads.

Manually wrangling messy bank descriptors (POS DEB STRIPE*RENDER-SRV, TEMP AUTH COURSERA*PLUS), calculating irregular billing cadences, spotting silent price creep, and projecting runway in a spreadsheet takes hours of tedious mental labor.

According to C+R Research’s Consumer Subscription Study, the average consumer estimates they spend $86/month on recurring subscriptions, while their actual itemized spend is $219/month—a $133/month ($1,596/year) blind spot, with 42% of consumers admitting they still pay for subscriptions they completely forgot existed.

Existing solutions fail the "Slow and Steady" test:

Paid Trackers (The Subscription Irony): Services like Rocket Money charge up to $144/year (becoming another subscription!) while requiring you to hand over live bank login credentials to third-party aggregators.
Manual Spreadsheets: Writing regex, pivot tables, and balance formulas feels like unpaid homework, so we procrastinate.
Closed Cloud Chatbots: Uploading raw financial statements to commercial LLMs compromises privacy, and text-based generative models are notorious for arithmetic hallucinations on structured ledger tables.

2. What I Built: LeakLens (`// 03`)

LeakLens is an open-weight financial autopilot built around Prior Labs' TabPFN-3.5 and an open-weight legal drafter.

It takes the core spirit of Hacktoberfest Week 3 ("Slow and Steady"): rewarding user laziness by automating a dreaded, cognitive-draining chore so the user does nothing while the system works.

Instead of another generic dark-mode chatbot with neon gradients, LeakLens is designed as a Swiss Editorial Financial Instrument—grounded in warm alabaster paper (#F6F4EE), exposed 1px architectural gridlines, high-contrast Instrument Serif editorial headlines, and monospace JetBrains Mono tabular figures.

You drop a raw statement CSV (or click a persona preset), and LeakLens immediately executes a 3-Layer Hybrid Pipeline:

[ Raw Statement CSV / Persona Preset ]
│
▼
┌───────────────────────────────────────────────────────────┐
│ LAYER 1: Deterministic Symbolic Engine (Pandas) │
│ • Noise & payment processor stripping │
│ • Living expense quarantine (Rent, Groceries, Dining) │
│ • Exact cadence regularity, price drift %, duplicate cycle│
└─────────────────────────┬─────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────┐
│ LAYER 2: TabPFN-3.5 Predictive Core (Prior Labs) │
│ • TabPFNClassifier: 7-feature in-context leak probability │
│ • TabPFNRegressor: 90-day cash runway quantile forecasting│
│ (p10, p50 median, p90 uncertainty fan) │
└─────────────────────────┬─────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────┐
│ LAYER 3: Autonomous Action Studio (Groq / Open-Weights) │
│ • FTC 16 CFR Part 425 & ROSCA Cancellation Notices │
│ • Price-Match Negotiation & Downgrade Scripts │
│ • RFC-5545 .ics Calendar Renewal Shields │
└───────────────────────────────────────────────────────────┘

3. Signature UI/UX & Design Thinking

To ensure LeakLens felt like a calm, precision financial instrument rather than AI slop, I built four custom micro-interactions:

550ms Laser CSV Deconstruction (CsvDeconstructTransition): When switching personas or uploading a statement, the interface sweeps raw monospace transaction lines with a vermilion laser scanline before physically morphing into grouped merchant cards.
Tactile Hardware Kill-Switches & Spring Odometer: Toggling any detected leak on the ledger immediately strikes through the monthly cost, applies an archival emerald tint (#E6F4EF), and rolls the Reclaimed Annual Cash counter using Framer Motion spring physics (stiffness: 380, damping: 32).
Live 90-Day TabPFN Runway Simulator: An interactive SVG canvas displays the baseline cash balance trajectory (dashed vermilion) alongside the solid emerald Reclaimed Path. As you toggle kill-switches, the green line and the shaded +$X,XXX Recovery Wedge dynamically expand in real time.
"Verify Before You Cancel" Trust Box: Rather than pretending AI is infallible, LeakLens explicitly highlights what the CSV mathematically proves versus subjective context you should verify (e.g., "CSV proves charge jumped +52.6%, but cannot verify if your team intentionally upgraded compute tiers").

4. Why Open Innovation Matters for What I Built

Financial statements represent the single most sensitive digital artifact a human produces—exposing where you live, eat, travel, and spend money.

Privacy Without Compromise: Auditing your personal finances should never require uploading your bank history to a closed cloud vendor. LeakLens is architected with complete offline capability: the entire FastAPI + TabPFN-3.5 + open-weight pipeline can run locally on an Apple Silicon or Linux machine (Local Private Runtime) with zero external network calls.
Foundation Models Engineered for Tables: General-purpose text LLMs struggle with multi-quantile regression and calibrated tabular probabilities. Prior Labs' TabPFN-3.5 represents true open-weight innovation: a tabular foundation model trained on synthetic Bayesian priors that performs instant in-context classification and non-parametric quantile forecasting without days of hyperparameter tuning.
The $0 Personal FinOps Era: By building on open weights and open-source infrastructure, LeakLens proves that personal financial autonomy can be delivered at zero marginal cost forever—without charging the user a subscription to manage their subscriptions.

5. Partner Category Submissions

Best Use of TabPFN ($200)

LeakLens uses TabPFN-3.5 as the analytical brain of the application in two ways:

TabPFNClassifier (Leak Risk Scoring): Evaluates a 7-dimensional feature vector (amount_zscore, cadence_regularity, price_drift_pct, is_micro_charge, charge_count_90d, days_since_first_seen, is_trial_conversion_pattern) against in-context prior distributions to assign calibrated leak probabilities (e.g., 99.9% on sudden API spikes vs 0.0% on essential living expenses).
TabPFNRegressor (Multi-Quantile Runway Forecasting): Generates 13 weekly forecast points over 90 days with native p10, p50, and p90 uncertainty bounds directly driving our interactive SVG simulator.

Best Use of Render ($200)

LeakLens is deployed on Render as a decoupled full-stack architecture:

Backend Service (leaklens-api): Python 3.11 FastAPI web service hosting the deterministic Pandas rules engine and TabPFN client runtime.
Frontend Service (leaklens-web): Next.js 15 (App Router, Tailwind CSS, Framer Motion) communicating with the backend via environment variables.

Built with care for Hacktoberfest 2026. Code is open-source under the MIT License.

I Built a Local-First Contract Q&A App That Cites the Exact PDF Page

Devasish Mishra — Mon, 19 Oct 2026 06:48:27 +0000

Contracts are full of important details: liability caps, confidentiality periods, governing law, deadlines and exceptions. Finding one clause in a long PDF can be tedious. Sending the document to a cloud AI service is also not always acceptable when it contains sensitive information.

For Hacktoberfest 2026 Week 2, I built Air-Gapped RAG, a local-first contract PDF question-answering prototype that lets a user ask questions about a document and inspect the evidence behind the answer.

The idea is simple: an answer should be verifiable, and when the document does not contain the answer, the system should say so rather than guess.

What I built

Air-Gapped RAG lets a user upload a contract PDF, extract its text, index its contents locally, and ask questions through a browser interface.

The application combines:

Next.js, React and Tailwind CSS for the frontend.
FastAPI and PyMuPDF for the backend and digital PDF extraction.
Tesseract OCR for scanned or image-only PDFs.
LanceDB for embedded local vector storage.
nomic-embed-text for text embeddings.
Gemma 4 12B through Ollama for local answer generation.

The model receives retrieved document evidence rather than being asked to answer from general knowledge alone. The application validates citation references against the retrieved sources and preserves the original physical PDF page numbers.

Watch the demo

Here is Air-Gapped RAG in action. This demo shows the local contract upload workflow, evidence-backed answers with physical-page citations, and how the application handles questions when the document does not contain the answer.

The demonstration uses a synthetic contract, so no real or confidential documents are exposed.

The demonstration uses a synthetic three-page Master Services Agreement.

First, I upload the contract and index its contents. Then I ask:

What is the limitation of liability cap under Section 4?

The document specifies a $250,000 USD cap or the fees paid during the preceding twelve months, whichever is lower. The application returns an answer backed by a citation to physical page 2.

Next, I ask about a statutory penalty under Australian commercial law—something the synthetic contract does not establish.

The expected result is Not found in records, without fabricated citations.

That second example matters just as much as the first. A document assistant should be able to acknowledge when it lacks evidence.

The hardest part was not simply connecting an LLM

A basic RAG demonstration can retrieve a relevant paragraph and generate a plausible response. Making the result useful for contract review requires more care.

1. Preserving physical-page citations

A citation is only useful if a reader can locate the cited material in the original document. The extraction and chunking pipeline therefore preserves one-indexed physical page numbers, and the server validates generated source references.

During development, I also investigated a legal retrieval failure where an important qualification continued onto the following page. I improved the retrieval and context assembly logic so relevant cross-page clauses could be considered without indiscriminately adding more chunks to every query.

2. Handling scanned PDFs and tables

Extracting digital text is not enough for image-only documents. I added a local Tesseract OCR fallback and worked on reconstructing table-like text so values remain associated with their corresponding labels.

The difference matters when a question depends on a particular table row or rating, not just finding the correct page.

3. Refusing unsupported answers

The system is instructed to answer from the retrieved evidence and abstain when that evidence is insufficient. The backend also checks source identifiers instead of blindly trusting citation identifiers generated by the model.

This reduces the risk of presenting unsupported answers as if they were proven by the document. It does not eliminate every possible retrieval or language-model error, so important answers still need human review.

What offline testing taught me

I tested the application on an Apple Silicon Mac with 24 GB of unified memory and documented the verification procedure and results in the repository.

The recorded physical-host tests covered PDF upload, indexing, grounded answers, physical-page citations, safe abstention, a browser workflow with the frontend bound to loopback, and scanned-PDF OCR while external connectivity was disabled. The socket audit reported no unexpected external connections under the recorded test conditions.

The procedure and its limitations are documented here:

Offline verification report

This is evidence of offline functionality on the tested configuration—not a universal security certification. Different operating systems, hardware and future dependency versions need their own verification. Dependencies and model weights must also be installed before the machine is disconnected.

Why open innovation matters

A local-first design would be much less useful if every document had to be sent to a hosted model for inference.

Using open-source tools and a locally runnable open-weight model lets the application process documents without depending on a cloud LLM API for its core question-answering workflow. Developers can inspect the code, change components, run the application on their own hardware and investigate its behavior.

That freedom also brings responsibility: model terms still apply, resource requirements matter, and local execution alone does not prove that every process is free from network activity.

Who could use this?

Potential users include contract freelancers, consultants and small businesses that regularly need to locate clauses or verify terms in lengthy agreements.

A small legal practice might also find page-cited answers useful during initial document review. However, this is still a prototype. I have not yet validated customer demand or willingness to pay, and I would not present it as a replacement for legal judgment or professional review.

The next product decision should come from watching real users try the workflow and understanding where accuracy, installation or usability prevents them from trusting it.

What's next?

I want to keep the project focused: make the installation reproducible, preserve evidence-backed answers and safe abstention, and learn from people who would actually use it before expanding the architecture.

Repository: https://github.com/TechGenDM/Air-Gapped-RAG

Built for the Hacktoberfest 2026 Week 2 Side Hustle challenge.

Prize category: Best Use of Gemma

devchallenge #hf26challenge #ai #opensource

I Asked AI a Question. Then It Told Me to Put My Phone Away.

Devasish Mishra — Thu, 08 Oct 2026 07:20:44 +0000

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

What I Built

Most AI tools are designed to keep you talking to them. I wanted to build one that sends you away.

OpenField turns a question about your surroundings into a short field study. You type something you are curious about, like "Which side of my street stays shady the longest?", then add a place and a time budget (15, 30, 45 or 60 minutes). Local Gemma turns that into a small plan: 4–6 steps, the evidence to collect at each step, rough timing, and safety notes.

Then the app gets out of your way. You can open a minimal Field Mode with a timer and big step cards, or print a Field Card and leave your phone at home.

When you come back, you enter what you saw: notes, counts, measurements and photos. Gemma reads that evidence and writes a Field Report with three clearly separated parts:

Observed: what you actually recorded
Inferred: what reasonably follows from it
Uncertain: what your evidence cannot support yet

AI plans. You observe. The world supplies the data. AI helps you make sense of it.

Who is it for? Anyone curious about a place they can walk to: students, gardeners, birders, walkers, or a teacher who wants a 30-minute outdoor activity that is more than a worksheet.

OpenField is not a navigation app, a scavenger hunt, or a chatbot with a map. The screen is the shortest part of the experience on purpose.

I Took It Outside

I did not want to write about getting off the screen while sitting at a screen all week, so I ran a simulated study to test the complete OpenField loop.

My question: Which side of my street stays shaded the longest during this time of day?
Where and when: A quiet residential street, late afternoon
Time budget: 30 minutes
Model and machine: Gemma 4 E4B (gemma4:e4b) running locally through Ollama on a MacBook Air M4 with 24 GB RAM

What the protocol asked me to do: I compared the two sides of the street at several points during the 30-minute window. I recorded whether each observation point was in direct sun, partial shade or full shade, noted the approximate time, and took photos of representative locations.

What it was like without the phone: The interesting part was having to pay attention to the same locations repeatedly instead of checking the screen after every observation. Small changes in the shade line became much easier to notice when comparing the street from the same points.

What came back: I recorded 5 observation notes, 4 simple shade observations and 3 photos covering different points along the street.

What Gemma concluded:

Observed: The recorded observations showed that the left side of the street was shaded at more observation points during the study period.
Inferred: Based on those observations, the left side appeared to remain shaded for longer during the tested period.
Uncertain: The study was too short to establish that the left side stays shaded longer throughout the entire day or across different days and weather conditions. Gemma correctly did not claim a general rule from the limited observations.

What went wrong: The 30-minute window was enough to compare the two sides, but not enough to establish a strong long-term pattern. A better version would repeat the same observations at different times of day and on multiple days.

Simulated field run used to test the complete evidence-to-report workflow.

Demo

The demo walks through the full loop:

Create Study → Field Protocol → Field Mode → Return & Evidence → Gemma debrief → Field Report

Code

TechGenDM / OpenField

OpenField is not an outdoor recommender or scavenger-hunt app. It is a local-AI “field study” engine that turns curiosity into a short real-world investigation.

OpenField 🌿

Ask a question about the real world. OpenField turns it into an honest field study.

"AI plans. You observe. The world supplies the data. AI helps you make sense of it."

OpenField is a local-AI field study engine powered by Gemma via Ollama. It turns curiosity into a short, structured investigation, helps you step away from the screen while observing, and uses the evidence you bring back to generate a report that separates what was observed from what was inferred and what remains uncertain.

Built for Hacktoberfest 2026.

What is OpenField?

Most AI tools keep the user on the screen.

OpenField does the opposite.

You give it a question about your surroundings. Local Gemma turns that question into a 15–60 minute field protocol. You take the protocol outside (or use it indoors), observe the real world, record notes/counts/photos, then return and let local Gemma analyze the evidence.

The…

View on GitHub

OpenField is open source under the MIT License. The repo has the full app, a specification, architecture notes, a contribution guide, tests and setup instructions. The first commit was on October 6, 2026, and the project was built inside the Week 1 challenge window.

To run it yourself:

git clone https://github.com/TechGenDM/OpenField.git
cd OpenField
ollama pull gemma4:e4b
npm install
npm run dev

How I Built It

OpenField is built around Gemma running locally through Ollama. There is no cloud AI API anywhere in the core app. The stack is small on purpose: Next.js, TypeScript, Tailwind CSS, Zod, Ollama and Gemma.

Question → Protocol (Gemma) → Field Mode or Field Card → Evidence → Debrief (Gemma) → Observed / Inferred / Uncertain

1. Question to protocol.

The user gives a question, a place, a time budget and an investigation type. Gemma returns a structured Field Protocol: the research question, 4–6 steps, evidence requirements, time estimates, safety guidance and an optional audio briefing script.

I validate that output with Zod and deterministic checks. For example, the steps must fit the time budget, and the safety rules must be followed. A small local model gets checked, not trusted.

2. Leaving the screen.

Field Mode runs its timer and step navigation in the browser, so nothing needs to talk to Ollama while you are outside.

The even simpler option is the printed Field Card: paper, a pen, and no battery.

3. Bringing evidence back.

On the Return & Evidence screen you record observations per step and attach photos. Before any photo is used, the browser resizes it to a maximum of 1024px and strips the EXIF and GPS metadata.

The processed image is only sent to the local app.

4. The debrief.

Gemma gets the protocol and your evidence, and writes the Field Report. Every finding must point back to something you recorded.

If the evidence is thin, the report is designed to say so instead of filling the gap with confident guesses.

That Observed / Inferred / Uncertain split is the part of the design I care about most.

Why Does Open Innovation Matter?

A field study is about your street, your garden, your photos and your notes. That evidence belongs to the person who collected it.

Running Gemma locally through Ollama made three things possible that a closed API would not:

Your evidence stays on your machine. Field photos and notes are never sent to a remote AI service just to get a report.
It costs nothing to run. There is no API key and no per-request bill. Once the model is downloaded, the AI part does not need the internet.
The model is swappable. The app talks to a structured local interface, not a proprietary endpoint, so another open model can be tried without redesigning the product.

There is a trade-off, and I want to be honest about it. A local model is smaller than the biggest cloud models, so I could not just trust whatever it said.

That is why the protocol is validated and why every claim in the report must point to evidence.

Open and local did not just make the project cheaper. They shaped how I designed it.

My Agent Session

I used AI coding assistants, including Antigravity IDE, for repository inspection, implementation, debugging, testing and release preparation.

I directed the product design, the architecture and the review of every change.

Prize Categories

Best Use of Gemma.

Gemma is the core reasoning engine behind both major parts of OpenField:

Generating the Field Protocol from a real-world question.
Performing the multimodal evidence debrief after the field study.

I am intentionally entering only the Gemma partner category because it is the technology that is genuinely central to the project rather than adding integrations just to collect categories.

What I Learned

The best AI experience might sometimes be the one that makes you use AI less.

It is easy to build another place where you ask a question and get an answer. It is harder to build something that says, "here is what to go and look at," and then stops talking.

The model only reasons about evidence the real world actually supplied.

That moved AI, in my head, from an answer machine to an investigation assistant.

What's Next

The MVP is intentionally small. I do not want OpenField to become a giant AI platform.

Next I want to improve accessibility, test coverage, printable field materials and report export. I have also opened focused contributor issues in the repository for these areas.

The core loop should stay simple:

Question → Observe → Evidence → Understand.

The best moment in OpenField is the one where you stop using it.

Thanks for reading!

My friend spent more time choosing a local AI model than building. So I built Hack Day Starter.

Devasish Mishra — Mon, 05 Oct 2026 05:21:14 +0000

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

What I Built

A friend of mine wanted to try building with local AI for a hackathon project.

He had a 24 GB Apple Silicon laptop and wanted to build locally, but before he could start building, he had to figure out which model would actually make sense for his machine.

The problem wasn't coming up with an AI idea. It was getting from:

"I want to use a local AI model."

to:

"I have a working project."

Before actually building, there were several questions to answer:

Which model can this laptop realistically run?
How much RAM does it need?
Is there enough disk space to download it?
Does it support tool calling?
What exact Ollama model tag should be used?
How do I connect that model to a real application?
What happens when Ollama is not running?
What happens when the model hasn't been downloaded yet?

That setup work can take away a lot of valuable hackathon time.

So I built Hack Day Starter.

It is a hardware-aware local AI model recommender and starter generator.

You describe the machine you're building on. Hack Day Starter filters and ranks verified local models for that hardware, explains why a model fits, lets you choose between a Local Chat or Tool-Calling Agent, and generates a ready-to-run TypeScript starter for Ollama.

The idea is simple:

Remove the setup decision that happens before the real building begins.

The flow looks like this:

Hardware profile
      ↓
Compatibility filtering
      ↓
Verified model recommendation
      ↓
Local Chat / Tool-Calling Agent
      ↓
Generated TypeScript starter
      ↓
Ollama + local model
      ↓
Start building

This was built during the Hacktoberfest 2026 "Build for a Friend" challenge.

Demo

Live App

Hack Day Starter → https://hack-day-starter.vercel.app

Video Demo

The demo starts with a hardware profile and ends with a real local tool-calling application running through Ollama.

The web app is the recommender and generator.

The generated project is the thing the developer actually takes away and runs locally.

Code

GitHub → https://github.com/TechGenDM/Hack-Day-Starter

How I Built It

The stack is Next.js, TypeScript, Tailwind CSS, and Ollama.

But the interesting part isn't the framework stack.

It is the set of decisions I made around model selection and local execution.

1. I didn't want another static "RAM → model" table

A simple mapping would have been easy:

8 GB  → small model
16 GB → medium model
24 GB → larger model

But that breaks down quickly.

Two models with similar parameter counts can have very different memory requirements, context windows, capabilities, and practical hardware fit.

So Hack Day Starter builds a hardware profile using information such as:

RAM
free disk space
operating system
Apple Silicon / GPU information
NVIDIA VRAM where applicable
intended use case

The recommendation engine first removes models that should not be recommended at all, then ranks the remaining models using factors such as memory headroom, disk headroom, hardware acceleration, task relevance, model capacity, and verified capabilities.

The recommendation itself is deterministic.

I didn't ask another LLM to decide which model should be used.

2. Model information needs to be treated as data, not truth

Local AI changes quickly.

A tutorial written a few months ago can easily point to a model that has been replaced, changed, or isn't appropriate for the hardware anymore.

So I created a curated Verified Model Registry.

The registry currently tracks 23 model entries and records information such as:

exact Ollama tags
model size
context window
lifecycle status
capabilities
verification status

The recommendation layer only considers models that pass the project's local and verification rules.

The generator checks the registry again before creating a starter, so an arbitrary model tag can't simply be supplied by the client to bypass those checks.

3. Chat and Agents are different starting points

I didn't want the generated project to become another giant framework.

There are two intentionally small starter types.

Local Chat

A minimal TypeScript application that communicates directly with the local Ollama API.

Tool-Calling Agent

A small agent loop where the model can request a tool, the local runtime executes it, and the result is sent back to the model.

For the demo, I verified a complete local tool-calling run with Gemma 4 12B:

User:
What is 342 multiplied by 19, and then divide by 4?

Model → Tool Call:
calculate({"expression":"(342 * 19) / 4"})

Tool Result:
1624.5

Model:
342 multiplied by 19, divided by 4, equals 1624.5.

That was important to me.

I didn't want to stop at "the model supports tool calling."

I wanted to see the complete loop actually work:

model → tool request → local execution → tool result → model response

4. The generator doesn't use an LLM to generate the code

This was another deliberate decision.

Hack Day Starter generates the starter project from deterministic templates.

That means the application controls:

the project structure
the selected model
the exact Ollama tag
the setup commands
the starter type

The same input should produce the same project.

For a developer tool whose whole purpose is to remove setup uncertainty, predictable generation matters more than making the generator itself "AI-powered."

5. I learned that local AI has another failure mode: setup

Getting a model selection right is only half the job.

A generated application can still fail immediately because:

Ollama isn't running

or:

The model hasn't been downloaded

So the generated starters include a readiness check.

Instead of showing a raw connection error, the starter explains what is missing:

Ollama not running
        ↓
Start Ollama

Model not installed
        ↓
ollama pull <exact-model-tag>

Ready
        ↓
npm run dev

That sounds like a small UX detail.

For someone new to local AI, it can be the difference between "I understand what happened" and "the project is broken."

6. I added safety boundaries around generation and tools

The project also has a few hard checks:

arbitrary model tags are rejected
retired or unverified models cannot be used
Agent starters require verified tool-calling support
the exact selected Ollama tag is preserved
the calculator uses a strict parser instead of eval() or new Function()

The repository currently has 36/36 automated tests passing across recommendation logic, registry validation, starter generation, readiness checks, security checks, and setup-flow contracts.

What Building This Taught Me

The hardest part wasn't making a model answer a prompt.

The harder problem was deciding what should happen before the prompt ever reaches the model.

I started with the obvious mental model:

"Give me hardware → give me a model."

The project became much more useful when I treated it as:

"Give me hardware → tell me what I can safely use → explain why → give me a runnable starting point."

That changed the project from a model lookup tool into a bootstrapper.

I also learned that "local AI" is not just about inference.

The developer still has to install the runtime, download the weights, understand the hardware limits, and connect everything to an application.

The real product is reducing that friction.

Handing It Over

Before finishing the project, I ran the workflow with a friend.

The part that mattered most was that he didn't need me to explain what model to choose or what command to run next. The recommendation, exact model tag, and setup steps were visible in the product itself.

The important test wasn't whether I could use the application.

I already built it.

The real test was whether someone else could go through:

hardware → recommendation → starter → setup

without needing me to explain every screen.

That was the standard I used for the final UX.

There is still plenty I could improve, but the core hand-off works: the recommendation explains itself, the selected model is explicit, and the generated project tells the developer exactly what to do next.

Why Does Open Innovation Matter?

A closed AI API could have helped me build an AI application.

But it would not have solved the particular problem I was trying to solve.

The core of Hack Day Starter is local model selection and local execution.

The developer can:

choose a model based on their own hardware
inspect the model information used by the recommendation
download the weights locally
run inference through Ollama
swap to another compatible model
inspect and modify the generated TypeScript code
build without making a hosted inference API a requirement

That control matters because the model is not just an API endpoint anymore.

It becomes part of the developer's own environment.

It also changes the privacy boundary.

For the generated application, inference can happen through the developer's local Ollama instance rather than sending prompts to a third-party inference service.

There are real tradeoffs.

Local models still need enough hardware. Downloading weights takes disk space and time. Smaller models won't always match the quality of large hosted frontier models.

I don't think those tradeoffs make local AI universally better.

They make it different.

For this project, the open approach gives the developer more control over:

the model, the runtime, the hardware, the code, and where the data goes.

That's exactly what I wanted my friend to have.

I wanted to create a shorter path from "Can my laptop run this?" to "I'm building."

Prize Categories

Best Use of Gemma

I'm entering Best Use of Gemma because Gemma 4 12B is used as a real local model in the project, and I verified a complete tool-calling workflow with it through Ollama.

Built for a friend during Hacktoberfest 2026.

DEV Community: Devasish Mishra

LeakLens: A Swiss-Editorial Financial Autopilot Powered by TabPFN-3.5 That Audits Messy Bank CSVs

Links & Quick Links

1. The Problem: The $133/Month "Laziness Tax"

2. What I Built: LeakLens (// 03)

3. Signature UI/UX & Design Thinking

4. Why Open Innovation Matters for What I Built

5. Partner Category Submissions

Best Use of TabPFN ($200)

Best Use of Render ($200)

I Built a Local-First Contract Q&A App That Cites the Exact PDF Page

What I built

Watch the demo

The hardest part was not simply connecting an LLM

1. Preserving physical-page citations

2. Handling scanned PDFs and tables

3. Refusing unsupported answers

What offline testing taught me

Why open innovation matters

Who could use this?

What's next?

devchallenge #hf26challenge #ai #opensource

I Asked AI a Question. Then It Told Me to Put My Phone Away.

What I Built

I Took It Outside

Demo

Code

TechGenDM / OpenField

OpenField is not an outdoor recommender or scavenger-hunt app. It is a local-AI “field study” engine that turns curiosity into a short real-world investigation.

OpenField 🌿

What is OpenField?

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

What I Learned

What's Next

My friend spent more time choosing a local AI model than building. So I built Hack Day Starter.

What I Built

Demo

Live App

Video Demo

Code

How I Built It

1. I didn't want another static "RAM → model" table

2. Model information needs to be treated as data, not truth

3. Chat and Agents are different starting points

Local Chat

Tool-Calling Agent

4. The generator doesn't use an LLM to generate the code

5. I learned that local AI has another failure mode: setup

6. I added safety boundaries around generation and tools

What Building This Taught Me

Handing It Over

Why Does Open Innovation Matter?

Prize Categories

Best Use of Gemma

2. What I Built: LeakLens (`// 03`)