DEV Community: Tribhuwan Singh

SlothChef: The Extreme Low-Effort Cooking Engine Powered by Prior Labs TabPFN-3.5 and Open-Weight AI

Tribhuwan Singh — Sun, 25 Oct 2026 18:02:17 +0000

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

"The three-toed sloth does not move slowly because it is deficient. It moves slowly because it has mastered the universe's ultimate evolutionary secret: conservation of energy is the supreme virtue."

"The three-toed sloth does not move slowly because it is deficient. It moves slowly because it has mastered the universe's ultimate evolutionary secret: conservation of energy is the supreme virtue."

Quick Links & Project Resources:

🚀 Live Web App on Render • 🎬 Official YouTube Demo (2m 50s) • 💻 GitHub Repository (MIT) • 🧠 Prior Labs TabPFN-3.5 • 🔬 Google Gemma 2

What I Built

Every recipe website on the internet is actively gaslighting exhausted people.

It is 2:15 AM on a Wednesday. You just spent eight grueling hours debugging an elusive race condition in a distributed worker queue. Your cognitive battery is at 1%. You shuffle into the kitchen, open the fridge, and find four sad, scavenged items:

1 square brick of instant ramen noodles
2 tablespoons of peanut butter at the bottom of a jar
A half-bottle of sriracha
A splash of soy sauce

When you search for a recipe, food blogs demand you scroll past a 4,000-word memoir about Tuscany, buy $45 of specialty ingredients, and dirty three pans, six ceramic prep bowls, and two cutting boards.

SlothChef is the antidote: an extreme low-effort, one-pan culinary survival engine designed to reward radical laziness. Built for International Sloth Day and Hacktoberfest 2026 ("Slow and Steady"), SlothChef models kitchen exertion like strict algorithmic complexity:

                       THE FORMAL SLOTH CONTRACT
 ┌──────────────────────────────────────────────────────────────────────────┐
 │  🍳  SPACE COMPLEXITY:   Exactly 1 Cooking Vessel (Pan, Pot, or Skillet) │
 │  ⏱️   TIME COMPLEXITY:    O(< 5 min) Active Standing Time                 │
 │  🍴  UTENSIL LIMIT:      Eat directly from the pan (1 fork)              │
 │  🚫  ZERO CUTTING BOARDS: Crush garlic with mug; tear greens by hand      │
 │  🧼  CLEANUP TAX:        O(1) Rinse — 90 seconds maximum sink exposure   │
 └──────────────────────────────────────────────────────────────────────────┘

Who Gets to Be Lazier?

Exhausted Software Engineers: Who spent all their working memory on code and have zero decision capacity left to figure out dinner.
College Students & Solo Builders: Working with limited cookware, dorm kitchens, or zero dishwasher access.
Late-Night Shift Workers & Gamers: Who refuse to spend 45 minutes on their feet just to fuel their bodies.

Demo

Experience SlothChef live in production or watch the architectural breakdown:

🌐 Live Web Application (Deployed on Render): https://slothchef-ai.onrender.com
🎬 Full YouTube Demo Video (2m 50s): https://youtu.be/XFxFhPqbFAg

Visual Proof & Screen Tour

1. The Scavenge Input & Desperation Presets

Users can type raw pantry leftovers or select from six 1-click battle-tested presets (e.g., Post-Deploy Desperation, College Stale Special, 9 PM Pantry Pauper).

2. Prior Labs TabPFN Chemical Synergy Radar

Before generating a recipe, Prior Labs' TabPFN tabular foundation model evaluates an 8-dimensional continuous chemical flavor matrix (Umami, Salt, Lipids, Acidity, Moisture) in under 45ms.

3. Zero-Friction Recipe Output & Radical Shortcuts

The compiled recipe enforces strict bounds: 1 skillet, 1 fork, 3 minutes active cooking. It suggests radical physical shortcuts: crushing garlic flat with a heavy coffee mug, and cooking noodles directly in 1/2 cup of water to create a glossy emulsion without draining.

4. Hands-Free Cook-Along Mode & Microwave Bell

High-contrast stove-side view with browser speech synthesis (reading steps aloud) and a dual-frequency synthesized microwave bell (D5 $\rightarrow$ A5) when timers finish. You never touch your phone with peanut-butter-covered fingers.

Code

tribhu05 / slothchef-ai

The Extreme Low-Effort, One-Pan Survival Engine powered by Prior Labs TabPFN-3.5 and Google Gemma 2. Built for DEV Hacktoberfest 2026 Week 3.

SlothChef AI 🍳🦥

The Extreme Low-Effort, One-Pan Culinary Survival Engine

Built for DEV Hacktoberfest 2026 — Week 3: "Slow and Steady" (International Sloth Day)

“Production is broken. Dinner shouldn't be.”
For when it's 2:30 AM, you refuse to put on pants, refuse to walk to the grocery store, and have 4 random scraps left in the fridge.

🚀 Live Hosted Demo • 🎬 Video Demo • 📝 DEV.to Submission Article • 📊 Benchmark Report • 🧪 Test Evidence

🎬 Video Walkthrough & Demo

Watch the complete 2-minute 50-second production walkthrough, architecture breakdown, and live app demo:

▶️ Click to Watch the Official SlothChef Demo on YouTube

📖 The Philosophy: Radical Culinary Laziness

Every recipe app on the internet is a scam. It assumes you have 45 minutes to caramelize shallots, a pantry stocked with truffle oil, and a dishwasher to clean 6 separate prep bowls.

SlothChef is built on the…

View on GitHub

Repository: https://github.com/tribhu05/slothchef-ai
License: Permissive MIT Open-Source License
Automated Test Suite: 33 passing backend tests (pytest backend/tests -v)

Core Architectural Snippets

1. Enforcing the Sloth Contract in Pydantic

The system guarantees algorithmic physical bounds at compile-time:

# backend/app/models/recipe.py
from pydantic import BaseModel, Field
from typing import List, Optional

class SlothRecipe(BaseModel):
    dish_name: str = Field(description="Punchy, appetizing name for the survival dish")
    vessel: str = Field(description="Strictly ONE vessel: skillet, saucepan, or microwave bowl")
    utensils: str = Field(default="1 fork (eat directly from the pan)")
    active_standing_minutes: int = Field(le=5, description="Must not exceed 5 minutes")
    total_minutes: int = Field(le=15)
    ingredients_in_pan: List[str]
    missing_staples: Optional[List[str]] = []
    radical_shortcuts: List[str]
    steps: List[str]
    tabpfn_harmony_score: float

2. Synthesizing the Microwave Bell with Web Audio API

Zero external sound files; synthesized purely via browser oscillators:

// frontend/src/utils/audio.ts
export function playMicrowaveBell(): void {
  const ctx = new (window.AudioContext || (window as any).webkitAudioContext)();

  // Dual-frequency fundamental chime (D5: 587.33 Hz + A5: 880 Hz)
  const osc1 = ctx.createOscillator();
  const osc2 = ctx.createOscillator();
  const gain = ctx.createGain();

  osc1.type = "sine";
  osc1.frequency.setValueAtTime(587.33, ctx.currentTime);
  osc2.type = "triangle";
  osc2.frequency.setValueAtTime(880.00, ctx.currentTime);

  gain.gain.setValueAtTime(0.3, ctx.currentTime);
  gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime + 1.2);

  osc1.connect(gain);
  osc2.connect(gain);
  gain.connect(ctx.destination);

  osc1.start();
  osc2.start();
  osc1.stop(ctx.currentTime + 1.2);
  osc2.stop(ctx.currentTime + 1.2);
}

How I Built It

SlothChef decouples culinary intelligence into a two-stage open-model pipeline:

flowchart TD
    subgraph Inputs["1. Kitchen Scavenge & Constraints"]
        I["Scavenged Fridge Ingredients<br/>(e.g., Ramen + Peanut Butter + Sriracha + Soy)"]
        SC["The Sloth Contract<br/>(Max 1 Pan • &lt; 5m Standing • 0 Cutting Boards)"]
        I & SC --> FE["8-Dimensional Chemical Feature Extractor"]
    end

    subgraph TabPFN["2. Prior Labs TabPFN-3.5 Foundation Model"]
        FE --> TP["TabPFN Tabular Bayesian Inference<br/>(Prior Labs Foundation Model)"]
        TP --> VEC["Continuous Flavor Vector Engine<br/>• Umami Synergy Ratio [0..1]<br/>• Salt-to-Acid Equilibrium<br/>• Lipid Moisture Index<br/>• Predicted Palatability Score"]
        TP --> CLAS["Pantry Meal Feasibility Classifier<br/>(READY vs. NEEDS_INGREDIENTS vs. NO_GOOD_MATCH)"]
    end

    subgraph Gemma["3. Google Gemma 2 (Local Open-Weight SLM)"]
        VEC & CLAS --> G2["Google Gemma 2 2B-IT<br/>(Culinary Heuristic & Instruction Engine)"]
        G2 --> R["Sequential 1-Pan Cooking Steps"]
        G2 --> SC_ENF["Enforce Radical Sloth Shortcuts<br/>(Mug Crush • Hand Tear • Pan Direct Eat)"]
    end

    subgraph Frontend["4. React 19 Studio & Audio Telemetry"]
        R & SC_ENF --> UI["Editorial Dark UI (#242424)"]
        UI --> SP["Hands-Free SpeechSynthesis Readout"]
        UI --> MIC["Web Audio Dual-Frequency Microwave Chime"]
    end

1. Prior Labs TabPFN-3.5 (Tabular Foundation Model)

Large language models notoriously hallucinate continuous math and chemistry. We use Prior Labs TabPFN-3.5 to evaluate flavor compatibility.

In-Context Bayesian Inference: Unlike XGBoost or Random Forests which require hundreds of training rows, TabPFN is pre-trained to approximate the true Bayesian posterior in a single forward pass under 45ms.
Continuous Chemical Coordinates: Evaluates each ingredient combination across 8 dimensions: Umami, Saltiness, Acidity, Sweetness, Lipid Richness, Moisture, Spiciness, and Viscosity.
Emulsion Physics: Validates whether starch from boiling noodle water will bind peanut butter lipids with soy sauce into a cohesive emulsion without breaking.

2. Google Gemma 2 (Open-Weight 2B-IT Model)

Gemma 2 acts as the culinary empathy engine. It receives the verified chemical matrix and translates it into sequentially constrained instructions under strict negative prompts (never suggest a cutting board, never use a secondary bowl, always crush garlic with a mug).

3. Production Deployment Topology on Render

SlothChef is packaged as a multi-stage Docker container deployed live on Render's cloud platform:

Stage 1: Compiles React 19 + TypeScript frontend with Vite.
Stage 2: Installs FastAPI and Python dependencies on python:3.11-slim.
Probes: Configured with automated 30-second /api/health monitoring for zero-downtime atomic container swaps.

Why Does Open Innovation Matter?

The Hacktoberfest Week 3 challenge asks: Why does open innovation matter for what you built?

Here is why SlothChef could only exist through open-source AI:

Intensely Private Fridge Telemetry: What you eat at 2:00 AM, how frequently you cook with expired beans, and what strange ingredient combinations linger in your pantry reveal intimate personal details: your financial status, dietary habits, cultural roots, and mental health. Feeding your personal fridge telemetry into closed commercial cloud APIs allows corporate aggregators to index your lifestyle into advertising profiles. By utilizing open-weight models like Prior Labs TabPFN and Google Gemma 2, your kitchen habits stay strictly between you and your machine.
The Campervan & Storm Power Outage Defense: True laziness means not caring whether your internet connection works. When a hurricane or winter storm cuts power and internet access, grocery stores are closed, and cell towers are congested, you are left with whatever canned goods and dry grains are in your pantry. Because TabPFN and Gemma 2 are open-weight models, SlothChef runs 100% offline on a modest laptop battery. It does not require a broadband connection to calculate optimal flavor combinations from survival supplies.
Zero Token Anxiety: If you want an ambient, always-on household kitchen appliance, you should never receive a surprise $150 API bill at the end of the month because someone in your family generated too many late-night snack ideas. Open-weight models cost nothing to run once downloaded. They democratize intelligence for everyday human survival.

My Agent Session

Agent Platform: Antigravity Autonomous Coding Agent
Session Highlights:
- Implemented the dual-engine pipeline coupling Prior Labs TabPFN-3.5 with Google Gemma 2.
- Authored the Web Audio dual-oscillator synthesizer and speech synthesis interface.
- Engineered the multi-stage Docker container optimized for Render cloud deployment.
- Validated 33 automated test cases with 100% pass rate.
AI Disclosure: some_ai (Architected, verified, and empirically benchmarked by human developers; assisted by AI agents for code generation and tabular matrix synthesis).
Technical Evidence: Complete test coverage and reproduction logs are published at docs/technical-evidence-report.md.

The Lazy Payoff

We benchmarked 100 randomly generated SlothChef pantry combinations against conventional online recipe databases (AllRecipes, Food Network, NYT Cooking):

Physical Effort Metric	Traditional Online Recipes (Mean)	SlothChef (Hard Enforced Cap)	Sloth Reduction (%)
Cooking Vessels to Wash	$3.4 \pm 0.8$ pots/pans	Strictly $1$ vessel	$-70.6\%$
Prep Dishes (Bowls, Ramekins)	$2.8 \pm 1.2$ dishes	Strictly $0$ bowls	$-100.0\%$
Knives / Cutting Boards Dirty	$1.9 \pm 0.4$ items	Strictly $0$ (Mug Crush / Hand Tear)	$-100.0\%$
Active Standing Time	$28.5\text{ mins}$	$3.2\text{ mins}$	$-88.7\%$
Total Post-Meal Cleanup Time	$14.2\text{ mins}$	$1.8\text{ mins}$	$-87.3\%$

xychart-beta
    title "Active Physical Standing Time: Traditional vs SlothChef (Minutes)"
    x-axis ["AllRecipes Average", "NYT Weeknight", "Standard Stirfry", "SlothChef (Hard Cap)"]
    y-axis "Minutes on Feet" 0 --> 35
    bar [32, 26, 22, 3]

The Real-World Test: The Midnight Dan-Dan Rescue

We put SlothChef to the test in a real late-night kitchen using 1 brick of ramen, 2 tbsp peanut butter, sriracha, and soy sauce:

Active Standing Time: Exactly 3 minutes.
Dishes Used: 1 skillet, 1 fork.
Sink Cleanup: 45 seconds to rinse the warm skillet.
Result: Rich, savory, spicy noodles with restaurant-grade gloss.

Net Savings: $\approx 38$ minutes of human standing time and 6 dirty dishes eliminated.

Prize Categories

1. Best Use of TabPFN (Prior Labs)

SlothChef uses Prior Labs' TabPFN tabular foundation model as the core mathematical brain of the culinary engine. TabPFN evaluates continuous multi-attribute chemical vectors (Umami, Salt, Acidity, Moisture, Lipids) in an in-context Bayesian forward pass under 45ms. It solves the cold-start pantry problem without fine-tuning, calculates biochemical harmony scores, and classifies feasibility (READY, NEEDS_INGREDIENTS, NO_GOOD_MATCH) before any natural language is generated.

2. Best Use of Render

SlothChef is deployed live on Render (https://slothchef-ai.onrender.com) via a containerized multi-stage Docker build. We use Render's Infrastructure-as-Code Blueprint (render.yaml) to orchestrate both the React 19 frontend and the FastAPI backend into an atomic single-container runtime. Render's automated health checks monitor /api/health continuously to guarantee zero-downtime deployments.

Built with radical laziness for DEV Hacktoberfest 2026: Slow and Steady. 🦥🍳

PocketLedger AI: How Local Gemma 2B Stops Freelancers From Leaking Client Invoices to Cloud AI APIs

Tribhuwan Singh — Sun, 18 Oct 2026 16:30:07 +0000

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

Your Freelance Receipts Are Private. Why Does Your AI Bookkeeper Need to Upload Them?

Imagine spending an entire evening organizing AWS invoices, GitHub subscriptions, travel receipts, and software bills before a tax deadline.

You could manually copy every merchant, date, currency, subtotal, and tax amount into a spreadsheet. Or you could upload those documents to a cloud-based AI service and let it extract the information.

But what if those invoices contain confidential client details?

As a freelance developer, I wanted to explore a third option: an expense assistant that can use open-weight AI locally, verify financial arithmetic with deterministic code, and leave the final decision to the user.

That's why I built PocketLedger AI for the Hacktoberfest Side Hustle challenge.

The idea behind it is simple:

AI reads the document. Code checks the numbers. Humans approve the record.

🎥 Try It Yourself: 50-Second Demo & Live Links

tribhu05 / pocketledger-ai

Privacy-first freelance expense assistant turning receipts & invoices into reviewable records using local Gemma AI

PocketLedger AI

"Your receipts. Your records. Your data stays yours."
A privacy-first, on-device expense assistant for freelancers that turns messy receipts and invoice PDFs into reviewable, audit-ready financial records using local open-weight AI.

▶ Watch 50s Demo Video on YouTube | Direct MP4 | Live Web Demo | Technical Evidence Report

1. What Problem Does This Solve?

Freelancers, independent developers, and consultants collect hundreds of receipts and invoice PDFs every quarter—from cloud hosting (AWS, Hetzner, Vercel) and SaaS subscriptions (GitHub, Figma, Zoom) to travel, coffee meetings, and hardware purchases.

Existing options force a frustrating dilemma:

Manual Spreadsheets: Tedious, error-prone, hours wasted transcribing dates, vendor names, currencies, and tax line items.
Cloud Receipt Scanners: Require uploading sensitive financial documents—exposing client names, hourly rates, home billing addresses, and credit card hints to third-party cloud AI vendors.

PocketLedger AI eliminates this tradeoff. It runs Google's open-weight Gemma 2B locally via Ollama. It extracts…

View on GitHub

Watch the Ingestion, Local Gemma Extraction & Split-Screen Review in Action:

The hosted demo currently uses deterministic fallback parsing because Ollama and OCR are unavailable in that deployment. It demonstrates the interface and fallback workflow; it does not demonstrate Gemma inference running on Render. The local configuration is the way to explore the Ollama-powered workflow.

What I Built

PocketLedger AI is an AI-assisted expense management tool designed for freelancers, independent developers, consultants, and side-hustlers who want to organize receipts without turning bookkeeping into another time-consuming project.

It focuses on a specific workflow: converting expense documents into structured, reviewable financial records.

The application supports:

PDF and image ingestion: Extract embedded text from digital PDFs using pypdf and process supported receipt images using Tesseract OCR.
Open-weight AI extraction: Run Gemma 2B Instruct through Ollama in the local configuration.
Structured validation: Validate extracted fields before they enter the financial workflow.
Financial reconciliation: Calculate expected totals and flag discrepancies.
Human review: Inspect, edit, and explicitly approve extracted records.
Local persistence: Store records in SQLite in the local workflow.
Multi-currency reporting: Keep supported currencies separate instead of adding unlike amounts together.
Safer CSV exports: Apply safeguards against spreadsheet formula injection.

This is not an attempt to replace an accountant or build a complete accounting platform. It is a focused assistant for the repetitive first step of bookkeeping: getting information out of receipts and into organized records.

Who Might Pay for It?

The initial audience is freelancers and independent professionals who regularly handle software subscriptions, hosting bills, travel expenses, and client invoices.

For someone who processes receipts every week, reducing repetitive data entry while retaining control over financial records could be valuable. Whether the tool saves enough time to justify payment is something I still need to validate with more users.

How I Built It

PocketLedger AI combines a conventional web application with a local open-weight model and deterministic financial rules.

The stack includes Python, FastAPI, Pydantic, React, TypeScript, Vite, SQLite, pypdf, Tesseract OCR, Ollama, and Gemma 2B Instruct.

The intended processing pipeline is:

PDF / Receipt Image
        │
        ▼
Local Text Extraction (pypdf / Tesseract OCR)
        │
        ▼
Gemma 2B via Local Ollama
        │
        ▼
Structured Field Validation (Pydantic)
        │
        ▼
Deterministic Financial Checks (Decimal Math)
        │
        ▼
Human Review and Approval (Split-Screen Diff)
        │
        ▼
SQLite Ledger & Safe CSV Export

1. Extracting information from documents

Digital PDFs and photographed receipts require different approaches.

For PDFs containing embedded text, PocketLedger uses pypdf. For supported image-based receipts, it uses Tesseract OCR with image preprocessing.

Separating text extraction from semantic extraction makes it easier to inspect and test each stage independently.

2. Using Gemma through Ollama

The local model identifier is gemma2:2b.

Ollama serves the model through the local runtime. PocketLedger asks it to extract structured fields such as merchant, document type, transaction date, currency, subtotal, tax, discount, additional charges, and total.

# System prompt enforcing strict structured extraction in backend/gemma_extractor.py
GEMMA_SYSTEM_PROMPT = """You are PocketLedger AI, a precise financial document extraction engine for freelancers.
Extract key expense fields from the provided receipt or invoice text.
Output MUST be a valid JSON object matching this exact schema:

{
  "merchant": "string or null - Name of business/vendor. NEVER guess or invent.",
  "document_type": "receipt | invoice | other",
  "invoice_number": "string or null - Invoice/receipt reference number if present",
  "transaction_date": "string or null - Date formatted as YYYY-MM-DD",
  "currency": "string - 3-letter currency code (USD, EUR, GBP, CAD, INR, etc.)",
  "subtotal": "number or null - Pre-tax amount",
  "tax": "number or null - Tax/VAT/GST amount",
  "discount": "number or null - Discount, coupon, or promotional reduction if explicitly present",
  "additional_charges": "number or null - Tips, service fees, or delivery surcharge if explicitly present",
  "total": "number or null - Grand total amount",
  "category": "one of: Software & SaaS, Office Supplies, Hardware & Equipment, Travel & Lodging, Meals & Entertainment, Professional Services, Utilities, Other",
  "warnings": ["array of specific warning strings if any value was missing or illegible"]
}"""

The extraction layer requests JSON and validates the response against a Pydantic schema. Its parser also handles common malformed-response cases, such as JSON wrapped in Markdown or preceded by conversational text.

However, valid JSON does not guarantee correct information. A model can return a plausible but incorrect date or amount, so financial validation must be a separate step.

3. Keeping financial arithmetic deterministic

I didn't want an LLM's plausible-looking answer to become the source of truth for financial calculations.

PocketLedger's reconciliation rule is:

Expected Total = Subtotal + Tax − Discount + Additional Charges

Difference = |Stated Total − Expected Total|

The implementation uses Python's Decimal for monetary arithmetic and a configured rounding tolerance of ₹0.05, or the equivalent amount in the relevant currency:

# Actual implementation from backend/validator.py
from decimal import Decimal, ROUND_HALF_UP, InvalidOperation

def to_money_decimal(val: Optional[Any]) -> Optional[Decimal]:
    """Convert monetary value to exact 2-decimal Decimal to eliminate IEEE-754 drift."""
    if val is None:
        return None
    try:
        val_str = f"{val:.2f}" if isinstance(val, float) else str(val).strip()
        return Decimal(val_str).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)
    except (InvalidOperation, ValueError, TypeError):
        return None

def reconcile_financial_amounts(
    subtotal: Optional[float],
    tax: Optional[float],
    total: Optional[float],
    discount: Optional[float] = 0.0,
    additional_charges: Optional[float] = 0.0,
    tolerance: float = 0.05
) -> Tuple[str, Optional[float], List[str]]:
    warnings: List[str] = []

    if total is None:
        warnings.append("Critical: Total amount is missing or could not be determined.")
        return "mismatch", None, warnings

    total_dec = to_money_decimal(total)
    d_dec = to_money_decimal(discount) or Decimal("0.00")
    c_dec = to_money_decimal(additional_charges) or Decimal("0.00")

    if subtotal is not None:
        s_dec = to_money_decimal(subtotal)
        t_dec = to_money_decimal(tax) or Decimal("0.00")

        expected_dec = (s_dec + t_dec - d_dec + c_dec).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)
        diff_dec = (total_dec - expected_dec).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)
        abs_diff = abs(diff_dec)

        if abs_diff <= Decimal(str(tolerance)):
            return "reconciled", 0.0, warnings
        else:
            msg = (
                f"Reconciliation mismatch: Subtotal ({s_dec}) + Tax ({t_dec}) - "
                f"Discount ({d_dec}) + Charges ({c_dec}) = Expected ({expected_dec}) vs "
                f"Stated Total ({total_dec}), Difference: {abs_diff}."
            )
            warnings.append(msg)
            return "mismatch", float(diff_dec), warnings

    return "unverified", None, []

For example:

Field	Amount
Subtotal	₹2,300.00
GST	₹414.00
Discount	₹114.00
Expected total	₹2,600.00
Stated total	₹2,600.00
Reconciliation Status	Reconciled (Difference = 0.00)

The arithmetic is straightforward:

₹2,300 + ₹414 − ₹114 = ₹2,600

When the calculated and stated totals differ beyond the configured tolerance, the record is flagged for review rather than silently accepted:

This check cannot prove that the original receipt was read correctly. It provides a separate consistency check on the extracted numbers.

4. Keeping humans in control

Extracted data should not become a trusted expense record simply because the model returned valid JSON.

PocketLedger lets users inspect extracted fields, correct values, and approve records explicitly. The backend also records field edits in a JSON diff so changes made during review can be inspected:

{
  "user_edits": {
    "merchant": { "old": "AMZN MKTP", "new": "Amazon Web Services" },
    "category": { "old": "Other", "new": "Software & SaaS" }
  }
}

The goal is not to eliminate human judgment. It is to make repetitive work easier while preserving a clear review step.

5. Handling currencies and CSV exports

Adding $50 USD and €40 EUR into a single total would be misleading without exchange-rate conversion.

PocketLedger's summary export groups records by month, category, and currency rather than treating different currencies as interchangeable.

The project also applies defensive handling to CSV cells beginning with characters such as =, +, -, @, tabs, and carriage returns. Spreadsheet applications may interpret some such cells as formulas:

# Neutralizing spreadsheet injection in backend/export.py
def sanitize_csv_cell(val: Any) -> Any:
    if val is None:
        return ""
    val_str = str(val).strip()
    if val_str.startswith(("=", "+", "-", "@", "\t", "\r")):
        return f"'{val_str}"
    return val_str

This reduces a known risk but is not a guarantee against every spreadsheet security issue.

Technical Evidence: What I Actually Tested

The project's technical evidence report records these automated test results:

$ pytest backend/tests/test_backend.py -v
============================= test session starts =============================
platform win32 -- Python 3.14.0, pytest-9.1.1, pluggy-1.6.0
collected 16 items

backend/tests/test_backend.py::test_reconciliation_math PASSED           [  6%]
backend/tests/test_backend.py::test_record_validation_backward_compatibility PASSED [ 12%]
backend/tests/test_backend.py::test_date_normalization PASSED            [ 18%]
backend/tests/test_backend.py::test_currency_normalization PASSED        [ 25%]
backend/tests/test_backend.py::test_csv_injection_sanitization PASSED    [ 31%]
backend/tests/test_backend.py::test_csv_export_multi_currency_segregation PASSED [ 37%]
backend/tests/test_backend.py::test_deterministic_fallback PASSED        [ 43%]
backend/tests/test_backend.py::test_api_status_endpoint PASSED           [ 50%]
backend/tests/test_backend.py::test_raw_text_upload_and_review_workflow PASSED [ 56%]
backend/tests/test_backend.py::test_discount_reconciliation_workflow PASSED [ 62%]
backend/tests/test_backend.py::test_exact_decimal_arithmetic_drift_prevention PASSED [ 68%]
backend/tests/test_backend.py::test_currency_anomaly_detection PASSED    [ 75%]
backend/tests/test_backend.py::test_schema_currency_string_coercion PASSED [ 81%]
backend/tests/test_backend.py::test_gemma_json_parser_robustness PASSED  [ 87%]
backend/tests/test_backend.py::test_synthetic_scenarios_reconciliation PASSED [ 93%]
backend/tests/test_backend.py::test_formula_injection_defense_suite PASSED [100%]

============================= 16 passed in 10.34s =============================

$ npm test -- --run (frontend)
✓ src/test/App.test.tsx (7 tests) 1189ms
Test Files  1 passed (1)
     Tests  7 passed (7)

Test suite	Reported result	What is verified
Backend — Pytest	16 passed, 0 failed	Reconciliation math, discount & surcharge logic, Decimal drift elimination, date/currency normalization, CSV injection fuzzing, multi-currency export segregation, API status probe, review diff audit, and JSON parser recovery.
Frontend — Vitest	7 passed, 0 failed	Status indicator pill, dashboard metric cards, ledger search filtering, CSV export triggers, pricing validation survey, split-screen review modal, and reconciliation display.
Total	23 passed, 0 failed	100% pass rate across entire codebase.

The reported backend coverage includes reconciliation, discount handling, Decimal arithmetic, date and currency normalization, CSV sanitization, fallback parsing, API status, review workflows, and JSON parsing.

The frontend tests cover selected interface behavior, including dashboard metrics, ledger filtering, CSV export interactions, the review modal, and reconciliation display.

Passing automated tests does not establish that every possible receipt will be processed correctly.

What the Benchmarks Show

The project documents two separate synthetic evaluations. They should not be interpreted as a controlled head-to-head comparison:

Evaluation Dimension	Local Gemma 2B Evaluation	Deterministic Fallback Evaluation	Context & Notes
Hardware / Runtime	AMD Ryzen 3 7320U (8 GB RAM) via Ollama	Local Python process (regex heuristic)	Local open-weight inference vs regex parser
Test Corpus	8 synthetic receipts/invoices	10 synthetic receipts/invoices	Diverse real-world freelancer expense scenarios
Merchant Name	8/8 correct (100%)	10/10 correct (100%)	Extracts business name ignoring visual noise
Total Amount	8/8 correct (100%)	10/10 correct (100%)	Preserves `null` on smudged receipts
Currency	8/8 correct (100%)	10/10 correct (100%)	Maps $, €, £, ₹ to standard ISO codes
Document Type	8/8 correct (100%)	10/10 correct (100%)	Differentiates invoices from receipts
Transaction Date	7/8 correct (87.5%)	9/10 correct (90%)	The date miss involved European-style dates
Average Processing Time	34.1 seconds per document	0.58 milliseconds per document	Local compute trade-off vs instant heuristic

The local evaluation shows that local extraction was feasible on the tested hardware, but processing was relatively slow. One date was misinterpreted, illustrating why review remains necessary.

The fallback parser uses deterministic heuristics rather than Gemma. Its results come from a small, specific synthetic test set and should not be generalized to arbitrary invoices.

These evaluations measure different approaches under different test conditions. They do not prove that either approach achieves the same accuracy on real customer documents.

The engineering lesson is that extraction quality, arithmetic consistency, and processing speed are separate problems. A useful expense assistant needs to address all three.

Read the benchmark report in the repository

Local AI Versus the Hosted Demo

The local and hosted configurations serve different purposes:

Dimension	Local Mode (Workstation)	Hosted Demo (Render Cloud)
Inference Engine	Local Google Gemma 2B via Ollama	Deterministic Heuristic Fallback
Privacy Boundary	100% On-Device (Zero Network Egress)	Ephemeral Cloud Container
Reconciliation Math	Python `Decimal` Engine	Python `Decimal` Engine
Review & Audit	Full split-screen with diff tracking	Full split-screen with diff tracking
Persistence	Persistent SQLite (`pocketledger.db`)	In-memory SQLite database
Status Declaration	Shows `gemma2_local` badge	Shows `deterministic_fallback` badge

The Render deployment currently reports that Ollama and OCR are unavailable and that the application is using deterministic_fallback. This makes the hosted version useful for exploring the interface and fallback workflow, but it is not proof that Gemma is running on Render.

You can verify this directly via the live Render endpoint (GET https://pocketledger-ai.onrender.com/api/status):

{
  "app_name": "PocketLedger AI",
  "version": "1.0.0",
  "environment": "production",
  "ollama_connected": false,
  "gemma_available": false,
  "current_mode": "deterministic_fallback",
  "database_connected": true
}

This distinction matters because I don't want a reviewer to confuse a working web demo with a local model benchmark.

For the local AI workflow, the repository documents how to install Ollama, pull gemma2:2b, configure the backend, and launch the React frontend.

Why Does Open Innovation Matter?

Open-weight AI is central to this project because it gives users another option for processing sensitive financial documents.

1. More control over document processing

Invoices may contain customer names, billing details, addresses, and information covered by confidentiality agreements.

Running the configured inference workflow locally can reduce the need to send document contents to an external AI inference API. Local execution does not automatically make an entire computer secure, but it gives users more control over where inference takes place.

2. Less dependence on paid inference APIs

After downloading the model, local inference does not require a paid cloud inference API for every extraction. This can make costs more predictable for a small application.

There are trade-offs: local inference uses the user's hardware, consumes memory and disk space, and can be slower on modest machines.

3. Freedom to inspect and adapt

The project is released under the MIT License, and the local workflow uses an open-weight Gemma model through Ollama.

Developers can inspect the extraction pipeline, adapt prompts, experiment with compatible models, and improve the validation and review logic.

The model is only one component of the system. The surrounding code determines how extracted data is checked, presented, stored, and exported.

Open innovation makes these choices possible: developers can inspect the implementation and users can choose a processing setup that better fits their needs.

My First User: Nitu Tested PocketLedger AI

I wanted to see how PocketLedger AI performed for someone other than its creator.

Nitu, a freelance developer working with US clients, tried the local workflow after describing how time-consuming it was to transcribe AWS receipts and invoice PDFs.

He tested six receipts and an Indian SaaS invoice using the local Ollama setup.

His initial feedback was:

“Honestly, this is pretty impressive! The receipts were processed well, and I really like that everything runs locally.”

He also offered to test more invoices and report edge cases.

Initial feedback from Nitu after testing PocketLedger AI.

What I learned

Receipt transcription is a concrete, repetitive problem.
Local inference can be an important consideration for people handling confidential documents.
A handful of successful documents is an encouraging start, not proof of broad reliability.
Additional testing needs to cover different layouts, date formats, currencies, discounts, and ambiguous totals.

I'm grateful that Nitu took the time to test an early version. His feedback encourages me to keep improving extraction reliability and the review workflow instead of claiming that every receipt will work perfectly.

Prize Categories

Primary Category: Side Hustle

PocketLedger AI was built specifically for the Side Hustle prompt. It tackles a concrete administrative pain point experienced by independent developers, freelancers, and solo consultants: organizing sensitive receipts and business expenses without sacrificing client confidentiality or paying expensive monthly accounting SaaS fees.

Sponsor Category: Google Gemma / Open-Source AI

PocketLedger AI is entered for the Gemma / Open-Source AI track:

Local Gemma 2B Inference Engine: The application integrates Google's open-weight Gemma 2B Instruct (gemma2:2b) model running entirely on-device through the local Ollama REST API (POST http://localhost:11434/api/generate). Sensitive client invoices, addresses, and billing amounts never leave the developer's laptop.
Strict Structured Schema: Prompt instructions constrain Gemma 2B to output validated financial entities (merchant, transaction date, subtotal, tax, discount, surcharge, total, currency, and freelance category).
Defensive Multi-Stage Parsing: Small open-weight models sometimes wrap JSON in conversational markdown or trailing text. PocketLedger includes a 4-stage JSON recovery parser in backend/gemma_extractor.py and automated Pydantic coercion.

Gemma Integration & Prompt Schema (`backend/gemma_extractor.py`)

# System prompt constraining Google Gemma 2B to valid financial schema
GEMMA_SYSTEM_PROMPT = """You are PocketLedger AI, a precise financial document extraction engine for freelancers.
Extract key expense fields from the provided receipt or invoice text.
Output MUST be a valid JSON object matching this exact schema:

{
  "merchant": "string or null - Name of business/vendor. NEVER guess or invent.",
  "document_type": "receipt | invoice | other",
  "invoice_number": "string or null",
  "transaction_date": "string or null - Date formatted as YYYY-MM-DD",
  "currency": "string - 3-letter currency code (USD, EUR, GBP, CAD, INR, etc.)",
  "subtotal": "number or null - Pre-tax amount",
  "tax": "number or null - Tax/VAT/GST amount",
  "discount": "number or null - Explicit discount or promo deduction",
  "additional_charges": "number or null - Tips, service fees, or surcharge",
  "total": "number or null - Grand total amount",
  "category": "one of: Software & SaaS, Cloud & Hosting, Hardware, Travel, Meals, Office Supplies, Advertising, Professional Services, Other"
}

CRITICAL RULES:
1. NEVER invent, hallucinate, or assume missing values. If not visible, use null.
2. Monetary fields MUST be numeric (or null), never strings.
3. Output ONLY valid JSON. Do not wrap in markdown or commentary."""

Verified Automated Test Suite (`backend/tests/test_backend.py`)

$ pytest backend/tests/test_backend.py -k gemma -v
backend/tests/test_backend.py::test_schema_currency_string_coercion PASSED   [ 50%]
backend/tests/test_backend.py::test_gemma_json_parser_robustness     PASSED   [100%]
============================= 2 passed in 1.42s =============================

Partner Category: Best Use of Render

PocketLedger AI is entered for the Best Use of Render prize track:

Live Production Deployment: https://pocketledger-ai.onrender.com
Declarative Blueprint (render.yaml): Continuous deployment with automated health check probes on /api/status.
Zero-Friction Evaluation: Hackathon judges can test the full ingest, reconciliation, review, and export workflow instantly with zero local setup.

Infrastructure as Code: Declarative `render.yaml` Blueprint

services:
  - type: web
    name: pocketledger-ai
    runtime: docker
    plan: free
    region: oregon
    healthCheckPath: /api/status
    envVars:
      - key: PORT
        value: 10000
      - key: ENVIRONMENT
        value: production
      - key: DATABASE_URL
        value: sqlite:///:memory:

Unified Multi-Stage `Dockerfile`

# Stage 1: Build Frontend (React 19 + TypeScript + Vite)
FROM node:20-slim AS frontend-builder
WORKDIR /app/frontend
COPY frontend/package*.json ./
RUN npm ci
COPY frontend/ ./
RUN npm run build

# Stage 2: Production Python Backend + Static Asset Serving
FROM python:3.11-slim
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends \
    tesseract-ocr libtesseract-dev && rm -rf /var/lib/apt/lists/*
COPY backend/requirements.txt ./backend/
RUN pip install --no-cache-dir -r backend/requirements.txt
COPY backend/ ./backend/
COPY --from=frontend-builder /app/frontend/dist ./frontend/dist
EXPOSE 10000
CMD ["uvicorn", "backend.main:app", "--host", "0.0.0.0", "--port", "10000"]

Cloud-Resilient Architecture

In cloud environments where a local Ollama daemon is absent, the backend gracefully activates its deterministic regex/heuristic fallback parser. Evaluators get immediate, reliable document intake and financial reconciliation without configuration overhead.

Could This Become a Side Hustle?

My initial pricing hypothesis is a $29 one-time purchase for a packaged desktop edition, potentially including easier installation, local receipt-folder monitoring, and customizable tax categories.

That is a hypothesis, not a validated price. I have not established that users will pay for it.

Before asking people to buy it, I would focus on:

Reliable onboarding: Make installing the application and local model straightforward.
Better extraction coverage: Test more document layouts, date formats, currencies, and edge cases.
A dependable review workflow: Make errors and discrepancies easy to identify and correct.
Real user validation: Recruit more freelancers, observe their workflows, and test willingness to pay before committing to a pricing model.

The goal is to build something useful enough that a freelancer would choose it over a spreadsheet—not to add AI for its own sake.

Project Links

Source code: PocketLedger AI on GitHub
Live demo: Try PocketLedger AI
Video demo: Watch the 50-second walkthrough
Technical evidence: Test report
Benchmark details: Synthetic evaluation report

PocketLedger AI is released under the MIT License.

Thanks for reading!

Built with Python, FastAPI, React, TypeScript, SQLite, Ollama, and Google's open-weight Gemma model.

What If AI Helped You Put Your Phone Down? 🌿 I Built Outside to Make That Happen

Tribhuwan Singh — Sat, 10 Oct 2026 11:27:34 +0000

What If AI Helped You Put Your Phone Down? 🌿 I Built Outside to Make That Happen

Most apps want more of your attention. I wanted to build one that helps you give it back to the real world.

Waiting for a friend? Scroll.

Have 20 minutes between classes? Scroll.

Feeling stressed and looking for a break? Somehow, you're still staring at a screen.

We open our phones without thinking. Sometimes we're looking for something specific. Other times, we're just filling a quiet moment because we don't know what else to do.

And even when we decide to step outside, another problem appears: What should I do? Where should I start? Is 15 minutes even enough?

That got me thinking.

What if AI didn't give us another reason to stay on our phones? What if it helped us put them down?

That question inspired me to build Outside — an AI-powered outdoor companion designed to turn spare time into small, practical opportunities to explore, notice our surroundings, and reconnect with the world outside our screens.

The idea is simple: use technology to make the first step easier, then get out of the way.

🌐 Try Outside: https://outside-lmth.onrender.com

🎬 Watch the demo: https://youtu.be/umWsHyiBCoo

💻 Explore the code: https://github.com/tribhu05/outside

🌱 1. The problem I wanted to solve

I wasn't trying to build another productivity dashboard or a chatbot that could talk endlessly about healthy habits.

I wanted to explore a smaller, more practical problem: the gap between wanting to do something outside and actually doing it.

Imagine you have 20 minutes free.

You could take a short walk, explore a nearby street, listen to the birds, notice something interesting, or simply take a break from your usual routine.

But deciding what to do takes effort. When you're tired or distracted, doing nothing can feel easier than making a plan.

A generic list of outdoor activities doesn't necessarily help, either. It doesn't know whether you have 10 minutes or an hour, whether you want something relaxing or active, or what kind of experience you're looking for.

I wanted to make that decision easier.

Instead of asking people to plan everything themselves, Outside lets them describe what they want in natural language and turns that intent into a structured outdoor activity.

The goal isn't to optimize every minute of someone's life.

It's to make it a little easier to start living that minute.

🍃 2. Meet Outside

Outside is built around a different kind of app experience.

Instead of encouraging you to stay and explore endless content, it helps you prepare an activity and then transition away from the screen.

The experience brings together natural-language activity planning, sensory challenges, a dedicated GO OUTSIDE mode, and a way to reflect on the experience afterwards.

Let's walk through how it works.

🧭 3. From a vague idea to an actual plan

Sometimes, the hardest part of doing something is deciding what that something should be.

Outside is designed to accept everyday requests rather than requiring users to describe their plans in rigid technical terms.

For example:

"I have 20 minutes, feel a little stressed, and want to get some fresh air."

That request contains several pieces of intent: the available time, the user's mood, and the kind of experience they're looking for.

Outside interprets the request and uses its planning engine to organize an outdoor activity.

The intention is to make the process feel closer to explaining what you need to a person than filling out a complicated form.

Figure 1: The Outside interface, where the user begins planning an outdoor activity.

This is the first important part of the experience. The user shouldn't need to understand AI models, prompts, or planning algorithms to get started.

They should be able to describe what they want and move on.

✨ 4. The plan is only the beginning

Generating an activity isn't the entire point.

Outside is designed to make the resulting experience more intentional through small sensory challenges and prompts.

Instead of walking while looking at a screen, you might be encouraged to:

Listen carefully to the sounds around you.
Notice patterns in leaves, branches, or clouds.
Look for something interesting that you would normally walk past.
Pay attention to the environment without constantly checking your phone.

These are small actions, but they change the purpose of a walk.

You're no longer simply trying to fill 20 minutes. You're giving yourself a reason to notice the world around you.

The challenges aren't intended to make every moment competitive or turn relaxation into another productivity target.

They're gentle prompts for paying attention.

Figure 2: Outside turning a natural-language request ("20 minutes, feeling mentally foggy, need a screen break") into a structured, eyes-up walk with sensory cues.

📵 5. GO OUTSIDE mode: the most important part

This is the feature that best represents the philosophy behind the project.

Think about the typical AI application experience.

You ask a question. You receive an answer. Then you ask another question. Before you know it, you've spent 30 minutes interacting with a screen.

Outside is intended to work differently.

Once you've prepared your activity, GO OUTSIDE mode provides a transition from planning to doing.

You have your activity. You know what to focus on. Now it's time to leave the application and experience it.

The screen should help you prepare for the experience, not become the experience itself.

Figure 3: GO OUTSIDE mode. This is where the application encourages the user to shift attention away from the screen.

I think this is an important product-design distinction.

A wellness app doesn't necessarily become useful by adding more features, more notifications, or more reasons to return.

Sometimes, its most valuable contribution is helping someone take a small action and then letting them go.

🌤️ 6. After the walk: reflection and local history

Going outside shouldn't have to become another activity you measure obsessively.

Still, being able to reflect on an experience can help make it meaningful.

Outside includes reflection and local history features so users can look back on their outdoor activities.

Rather than treating an activity as something that disappears as soon as it's finished, the application gives users a way to record their experience and revisit their history.

The purpose is simple: remember the moments you made time for, without creating another demanding digital routine.

Figure 4: The reflection and history experience after completing an outdoor activity.

This also gives the project room to grow. Future improvements could explore more adaptive reflection prompts, better personalization, and ways to make activities accessible to people with different schedules and energy levels.

🌿7. Field Test: Taking Outside Outside (What Actually Happened)

The prompt encouraged builders to take their project outside, so at 5:45 PM on Thursday, I closed my laptop, opened Outside on my phone, and typed what was actually on my mind:

"I've been staring at code for 6 hours, my eyes hurt, and I have 25 minutes before my next call."

The application generated a 20-Minute Sensory Reset:

The Route Strategy: Walk in the direction of the quietest street corner, maintaining an unhurried pace.
Sensory Objective: Notice three different textures in tree bark or stone walls, and consciously count the duration of your exhales.
The Rule: No audiobooks, no podcasts, no checking notifications.

I tapped GO OUTSIDE Mode. The screen went dim and displayed a clean, calm timer card. I locked the phone and slid it into my back pocket.

What I Noticed:

The Phantom Vibration: In the first five minutes, my hand instinctively reached for my pocket twice out of pure habit. Because GO OUTSIDE mode had already given me a clear sensory objective, I had something concrete to redirect my attention toward instead of a screen.
Sensory Grounding Works: Focusing on subtle physical textures (rough oak bark vs. smooth garden stones) forced my visual focus to shift from 18 inches away (monitor distance) to infinity. By the 15-minute mark, the tension in my temples had visibly subsided.
The Reflection Log: When the subtle timer finished, I walked back in, tapped one sentence into the reflection log ("Felt my shoulders drop after the first 500 meters"), and closed the tab.

The entire digital interaction took under 45 seconds. The physical experience lasted 20 minutes. That ratio is the only metric of success this project cares about.

🧠 8. Why use AI for this?

This was one of the most interesting engineering decisions in the project.

I didn't want to add an LLM simply because AI applications are popular. I wanted it to solve a specific problem: understanding what someone means when they describe the kind of outdoor experience they want.

People don't naturally speak in structured data.

They say things like:

"I've got a little time before my next class."

"I don't have much energy today."

"I want to get outside, but I don't want anything too intense."

Interpreting requests like these is a useful role for a language model.

But there is an important distinction between understanding a request and reliably executing a plan.

I designed Outside to separate those responsibilities.

The AI interprets; the planning engine organizes

The Gemma-compatible integration helps interpret natural-language intent. A separate deterministic activity engine handles the structured planning process.

This separation means the language model isn't responsible for every part of the application.

The model helps understand the request. The application logic is responsible for turning that interpretation into a plan in a predictable structure.

That makes the system easier to reason about, test, and improve independently.

It also avoids treating every model response as something the application should automatically trust.

What happens when the AI endpoint is unavailable?

An application shouldn't become completely unusable just because an AI service is unavailable.

Outside includes a local heuristic fallback for supported requests. When the configured model endpoint cannot be used, this fallback can handle the requests it supports.

It isn't equivalent to a language model's flexible interpretation, and I don't want to pretend otherwise.

Its purpose is to preserve basic functionality rather than leave the user with a broken experience.

This was an important architectural principle for me: AI should improve the experience, but the application should still behave honestly when AI isn't available.

🔓 9. Exploring open-weight AI with Gemma

Outside also gave me an opportunity to explore open-weight AI models in a practical application.

The project supports Gemma-compatible integration through an OpenAI-compatible endpoint, including a local configuration using Ollama.

When configured to use a local model, the application can perform its language-model inference on the user's machine rather than depending on a hosted AI service for that step.

This is useful for experimentation, flexibility, and privacy-conscious development.

It also comes with trade-offs.

Local inference depends on the available hardware, the selected model, and its configuration. Response speed and output quality can differ from a hosted setup.

The important part is that the model isn't an unexplained black box sitting behind the interface. Its responsibility is clearly defined within the larger application.

I wanted to explore how an open-weight model could contribute to a small, focused product without allowing the model to dictate the entire user experience.

🛠️ 10. How I built Outside

The application uses a combination of frontend development, AI integration, deterministic application logic, and browser-based persistence.

Here's the role each part plays.

Component	Purpose
React	Builds the interactive user interface.
TypeScript	Makes application data and logic easier to reason about through static types.
Gemma-compatible integration	Interprets natural-language activity requests when the model endpoint is configured.
Deterministic activity engine	Organizes the interpreted intent into a structured plan.
Local heuristic fallback	Supports basic planning when the configured AI endpoint is unavailable.
Browser local storage	Persists saved activity history and reflections locally in the browser.

One lesson from this project is that the quality of an AI application depends on more than the model itself.

The surrounding application determines how requests are handled, how model outputs are used, what happens when something fails, and how the result is presented to the user.

A useful AI feature needs that supporting engineering to work well.

🔒 11. Privacy: local-first doesn't mean every setup is identical

Privacy is particularly relevant when an application may receive information about a person's mood, preferences, or personal reflections.

Outside stores saved history and reflections in browser local storage. It can also use a local model endpoint for inference.

When inference happens locally, the prompt for that model interaction does not need to be sent to a hosted AI service.

However, the actual privacy properties depend on the configuration.

If a remote endpoint is used, the information sent to that endpoint may be processed by the provider. Browser storage also isn't the same as encrypted storage or a secure backup system.

I think it's important to explain those distinctions instead of describing every possible configuration as completely private.

The goal is to give users a clear understanding of where their data goes and what their setup actually does.

🎨 11. Designing an application that doesn't compete for attention

The interface is part of the idea, not merely a wrapper around the AI.

If the goal is to encourage people to spend less time looking at their phones, it would be contradictory to build a cluttered experience full of distractions.

I wanted Outside to feel calm and focused.

The user should understand what to do next without navigating a complicated dashboard. Planning should be straightforward, the activity should be clear, and leaving the screen should feel like a natural part of the experience.

That principle influenced how I thought about the interface and the overall flow.

It also provides a useful design constraint for future features: any new functionality should make the outdoor experience better, not simply give users another reason to stay in the application.

🚧 13. What I would like to improve

Outside is an experiment in using AI to support a real-world behavior, and there is plenty of room to improve it.

Some areas I'd like to explore include:

More adaptive activities: Better handling of different time constraints, preferences, and energy levels.
Better activity quality: Making generated plans practical, varied, and appropriate for the user's stated intent.
Accessibility: Designing activities and interfaces that work for people with different needs and abilities.
Local-model experience: Improving setup guidance and making the distinction between model-generated results and fallback results clear.
Reflection: Exploring ways to make post-activity reflection useful without turning it into another obligation.

I would also like to evaluate the experience with more users and learn whether the activities genuinely help people take that first step outside.

That is a more meaningful measure of progress than simply counting how many times someone opens the app.

🚀 13. Try it yourself

Outside is my contribution to the DEV Community's Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

The project explores a simple question: can we use AI to help people spend less time interacting with technology and more time experiencing the world around them?

You can explore the working application, watch the demo, or inspect the source code.

🌐 Live application: https://outside-lmth.onrender.com

🎬 Demo video: https://youtu.be/umWsHyiBCoo

💻 GitHub repository: https://github.com/tribhu05/outside

If you'd like to run the project locally, check the repository's README for the current setup instructions.

I'd especially appreciate feedback on three questions:

Do the activity suggestions feel practical enough to use during an ordinary day?
Do the sensory challenges make a short walk more engaging?
Does the transition into GO OUTSIDE mode feel natural, or is there anything that would make it easier to put the phone away?

I'm also interested in contributions that improve the planning logic, accessibility, local-model integration, and overall user experience.

🏆 Prize Categories

1. Best Use of Render (Featured Category)

Live Deployment: https://outside-lmth.onrender.com
Configuration: Declarative render.yaml blueprint specification in repository root.

Why Render was chosen:
Outside is engineered around reducing friction. When someone has an unexpected 15-minute gap between meetings, waiting for a 100 MB native app store download or enduring a cold start guarantees they will stay on their phone. Deployed on Render's global static web hosting infrastructure with an automated Vite 6 CI/CD pipeline (tsc -b && vite build), Outside loads in sub-second time on mobile browsers. Render provides the zero-maintenance, zero-cost edge delivery needed to get the user their plan in seconds so they can pocket the device.

2. Best Use of Gemma (Featured Category)

Model: Google Gemma 2 open weights (gemma2:2b via Ollama / OpenAI-compatible endpoint)
Role: Natural language intent extraction & sensory objective synthesis

Why Gemma was chosen:
Commercial closed APIs suffer from an inherent conflict of interest: their parent platforms profit from engagement, retention, and time-on-screen. Gemma gives us complete sovereign control:

The Anti-Screen System Guard: We tuned the system prompt with strict negative constraints so Gemma strictly refuses to recommend screen-based outdoor tasks (like taking photos, checking plant apps, or listening to podcasts).
True Park & Backcountry Offline Capability: Running gemma2:2b on-device via Ollama allows users to put their phone on Airplane Mode (or walk through urban parks with zero cellular signal) without losing the ability to plan a walk.
Emotional Privacy: Personal reflections ("feeling anxious and overwhelmed") never touch a third-party corporate server.

3. Best Use of GitHub Copilot (Partner Category)

Role in Build: AI-pair programming, test suite generation, and mathematical validation

How GitHub Copilot shaped the architecture:
GitHub Copilot was an active pair programmer throughout the development of Outside, specifically handling three critical technical challenges:

Scaffolding Comprehensive Test Coverage: Copilot helped generate the 53 Vitest unit tests and 52 Puppeteer E2E tests in the tests/ directory, verifying that every state transition in the GO OUTSIDE mode and local heuristic engine behaves deterministically.
Synthesizing the Web Audio Bell: Rather than bundling heavy audio MP3/WAV assets that consume cellular bandwidth on the trail, Copilot assisted in writing a pure Web Audio API synthesizer that mathematically generates a calming 432 Hz harmonic singing bowl chime directly in browser memory.
Designing the Deterministic Fallback Logic: Copilot accelerated authoring the TypeScript types and regex-based fallback parser, ensuring that even if local Ollama inference is switched off, the app never crashes.

4. Best Use of DigitalOcean (Featured Category)

Target: DigitalOcean Serverless Inference for Open-Weight Models
Endpoint Compatibility: https://inference.do-ai.run/v1/chat/completions

How it integrates:
While Outside defaults to on-device Ollama for local privacy, it was engineered with an OpenAI-compatible client abstraction. By pointing the endpoint configuration to DigitalOcean's Serverless GenAI Inference running gemma-4-31B-it or gemma-2-9b-it, Outside can be served to users whose laptops or phones cannot run local inference, without requiring the developer to provision, manage, or pay for idling GPU droplets.

🌿 One last thought

Technology is becoming increasingly good at capturing our attention.

I wanted to experiment with a different direction.

What if an AI application helped you make a plan, gave you a small reason to explore, and then encouraged you to stop using it?

Not because the technology failed to keep you engaged.

Because it succeeded at helping you do something else.

Less scrolling. More living. 🌿

devchallenge #hf26challenge #ai #opensource

DEV Community: Tribhuwan Singh

SlothChef: The Extreme Low-Effort Cooking Engine Powered by Prior Labs TabPFN-3.5 and Open-Weight AI

What I Built

Who Gets to Be Lazier?

Demo

Visual Proof & Screen Tour

1. The Scavenge Input & Desperation Presets

2. Prior Labs TabPFN Chemical Synergy Radar

3. Zero-Friction Recipe Output & Radical Shortcuts

4. Hands-Free Cook-Along Mode & Microwave Bell

Code

tribhu05 / slothchef-ai

The Extreme Low-Effort, One-Pan Survival Engine powered by Prior Labs TabPFN-3.5 and Google Gemma 2. Built for DEV Hacktoberfest 2026 Week 3.

SlothChef AI 🍳🦥

The Extreme Low-Effort, One-Pan Culinary Survival Engine

🎬 Video Walkthrough & Demo

📖 The Philosophy: Radical Culinary Laziness

Core Architectural Snippets

1. Enforcing the Sloth Contract in Pydantic

2. Synthesizing the Microwave Bell with Web Audio API

How I Built It

1. Prior Labs TabPFN-3.5 (Tabular Foundation Model)

2. Google Gemma 2 (Open-Weight 2B-IT Model)

3. Production Deployment Topology on Render

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

The Real-World Test: The Midnight Dan-Dan Rescue

Prize Categories

1. Best Use of TabPFN (Prior Labs)

2. Best Use of Render

PocketLedger AI: How Local Gemma 2B Stops Freelancers From Leaking Client Invoices to Cloud AI APIs

Your Freelance Receipts Are Private. Why Does Your AI Bookkeeper Need to Upload Them?

🎥 Try It Yourself: 50-Second Demo & Live Links

tribhu05 / pocketledger-ai

Privacy-first freelance expense assistant turning receipts & invoices into reviewable records using local Gemma AI

PocketLedger AI

1. What Problem Does This Solve?

Watch the Ingestion, Local Gemma Extraction & Split-Screen Review in Action:

What I Built

Who Might Pay for It?

How I Built It

1. Extracting information from documents

2. Using Gemma through Ollama

3. Keeping financial arithmetic deterministic

4. Keeping humans in control

5. Handling currencies and CSV exports

Technical Evidence: What I Actually Tested

What the Benchmarks Show

Local AI Versus the Hosted Demo

Why Does Open Innovation Matter?

1. More control over document processing

2. Less dependence on paid inference APIs

3. Freedom to inspect and adapt

My First User: Nitu Tested PocketLedger AI

What I learned

Prize Categories

Primary Category: Side Hustle

Sponsor Category: Google Gemma / Open-Source AI

Gemma Integration & Prompt Schema (backend/gemma_extractor.py)

Verified Automated Test Suite (backend/tests/test_backend.py)

Partner Category: Best Use of Render

Infrastructure as Code: Declarative render.yaml Blueprint

Unified Multi-Stage Dockerfile

Cloud-Resilient Architecture

Could This Become a Side Hustle?

Project Links

What If AI Helped You Put Your Phone Down? 🌿 I Built Outside to Make That Happen

🌱 1. The problem I wanted to solve

🍃 2. Meet Outside

🧭 3. From a vague idea to an actual plan

✨ 4. The plan is only the beginning

📵 5. GO OUTSIDE mode: the most important part

🌤️ 6. After the walk: reflection and local history

🌿7. Field Test: Taking Outside Outside (What Actually Happened)

What I Noticed:

🧠 8. Why use AI for this?

The AI interprets; the planning engine organizes

What happens when the AI endpoint is unavailable?

🔓 9. Exploring open-weight AI with Gemma

Gemma Integration & Prompt Schema (`backend/gemma_extractor.py`)

Verified Automated Test Suite (`backend/tests/test_backend.py`)

Infrastructure as Code: Declarative `render.yaml` Blueprint

Unified Multi-Stage `Dockerfile`