DEV Community: Paulo Ricardo Engcompaulo

Study Trail Builder

Paulo Ricardo Engcompaulo — Fri, 23 Oct 2026 23:03:57 +0000

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

What I Built

Study Trail Builder turns any study topic into an ordered, beginner-to-advanced learning trail of videos. You type a topic — say "limits in calculus" — and you get back at least ten YouTube videos, sequenced and grouped into Basic, Intermediate, and Advanced, each shown as a title next to its link.

The tedious part of self-teaching from YouTube is not watching the videos — it is the curation that comes first. You search, skim a dozen results, guess which ones are beginner-friendly, figure out a sensible order, and only then start learning. Study Trail Builder does all of that boring groundwork for you: it searches, vets candidates by popularity signals, sequences them easiest-to-hardest, and splits them into three difficulty tiers. True to the Slow and Steady spirit, it rewards laziness by taking a slow, methodical chore off your plate so you can just press play and move at your own pace.

Who benefits: anyone picking up a new subject on their own — students, career switchers, the perpetually curious — who wants a ready-made path instead of a wall of search results.

The product's defining property is that it is never allowed to fail you. Artificial intelligence does the smart part (ordering and grouping), but every AI call is wrapped in a bounded timeout with a deterministic fallback, so a result always comes back.

Demo

Run it locally with Docker under WSL (see the ordered run steps below) and open http://localhost:8080.

Type a topic, submit, and the app returns a grouped trail. Links open in a new tab, so your trail stays put while you watch.

Code

All code lives in desafio4/ and is deliberately small — a Django backend, an Angular micro frontend, and a three-service Docker stack.

Backend (backend/trail/) — Django with plain JsonResponse views (no DRF for a single endpoint). The risky logic is pure and unit-testable; the network lives at the edges.

search.py — the yt-dlp wrapper. Runs a keyless ytsearchN: query, normalizes raw entries into Video records, and drops anything missing a title, URL, or positive duration.
ai.py — the Ollama client, prompt builder, and reply parser. Calls POST /api/generate with a bounded timeout and parses the id-to-level mapping; it never raises.
heuristic.py — the deterministic fallback. Orders candidates by views, then likes, then duration, with the video id as the final tie-break, and splits them into three tiers.
builder.py — the AI-first orchestration. Tries the AI ranking; if the result is unusable, it falls back to the heuristic. Either path produces the same shape.
views.py — the single POST /api/trail endpoint: validate the topic, search, build the trail, and serialize it Basic → Intermediate → Advanced.
tests/ — minimal pytest + Hypothesis property tests covering heuristic determinism and AI-reply parsing.

Frontend (frontend/src/app/) — a minimal single-view Angular standalone app.

app.ts — the topic-entry component: one input (1–200 chars), submit, loading state, and client-side validation.
trail-view.component.ts — renders the three sections top-to-bottom, each video's title and link on the same row.
trail.service.ts — POSTs /api/trail with a 30-second client timeout.
nginx.conf — serves the static Angular build and reverse-proxies /api/* to the backend (same-origin, no CORS preflight).

docker-compose.yml — the three services: frontend (Angular + nginx), backend (Django + gunicorn), and ollama (the AI service), wired with depends_on and healthchecks.

How I Built It

The whole thing runs on an open-source stack with a locally hosted open-weight model at its core:

Django + gunicorn serve a single REST-style endpoint in a lightweight container.
yt-dlp searches YouTube with no API key — a ytsearchN: query with flat extraction returns titles, URLs, durations, and popularity counts without a paid developer account.
Ollama runs the open-weight llama3.2:1b model entirely on the host. It does two narrow jobs through short prompts to keep token counts low: (1) order the candidate videos basic-to-advanced, and (2) assign each one a Basic / Intermediate / Advanced level.
Angular + nginx make up the micro frontend — a static build served by nginx, which also proxies API calls to the backend.

Graceful degradation is the headline design decision. Every call into the AI layer is bounded by a 10-second timeout and guarded against connection failures, non-200 responses, and malformed output. On any failure — Ollama slow, down, or returning something unparseable — the backend silently routes to a deterministic heuristic that orders by view count, then like count, then duration. Both paths return the identical three-section shape, so the frontend never knows or cares which one ran. The AI makes the trail smarter; it is never a single point of failure. The app does not error out just because the model had a bad moment.

Why Does Open Innovation Matter?

Running an open-weight model locally instead of calling a closed, hosted API is what makes this project practical:

No per-call cost. Build as many trails as you like at zero marginal cost. For a free learning tool, metered API calls would be a non-starter.
Privacy by default. The topics you study never leave your machine. There is no third party logging what you are trying to learn.
Works offline. The model is local, and even if it is unavailable, the heuristic fallback keeps every trail working — no dependency on a paid cloud API staying up.
Swappable model. llama3.2:1b is the small default, but because it is just an Ollama model behind an env var, you can point the app at a larger open-weight model without touching the code.

An open approach wins here precisely because the valuable part — curating a learning path — is something you want to run cheaply, privately, and repeatedly. A closed API would push the intelligence, the cost, and your search history into someone else's cloud. Open weights plus a tiny footprint keep all of that on hardware you control.

My First User

Prize Categories

Run it with Docker under WSL

From the desafio4/ directory, under WSL:

# 1. Build and start all three services (frontend, backend, ollama)
docker compose up --build


![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/5r0nslnwogdvjhay8due.png)



# 2. In a second terminal, pull the model into the ollama service
#    (one time only; the model is cached on the ollama_data volume afterwards)
docker compose exec ollama ollama pull llama3.2:1b

# 3. Open the app
#    http://localhost:8080

The model download in step 2 is a one-time operation — it is cached on the ollama_data named volume and survives container restarts, so you only pull it once.

Configuration

The defaults work for a standard local run; none of these need to change.

Setting	Default	Purpose
`OLLAMA_URL`	`http://ollama:11434`	URL of the Ollama service inside the compose network.
`OLLAMA_MODEL`	`llama3.2:1b`	The open-weight model the backend asks to order and group videos.

Ports used by the stack:

Port	Service	Notes
`8080`	frontend (nginx)	The only port you open in a browser → `http://localhost:8080`.
`8000`	backend (gunicorn)	Published for debugging; nginx proxies to it internally.
`11434`	ollama	The AI service; the backend talks to it over the compose network.

OLLAMA_URL and OLLAMA_MODEL are set as environment variables on the backend service in docker-compose.yml; override them there if you want to point at a different Ollama host or model.

Example

"I want to learn about Python"

GITHUB

Neighbor Partner

Paulo Ricardo Engcompaulo — Mon, 12 Oct 2026 22:26:20 +0000

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

What I Built

Neighbor Partner is a tiny web app that helps independent local shops find each other and cross-promote.

Every neighborhood is full of small businesses that are not competitors but could easily send each other customers: a bakery and a bookstore, a gym and a café, a florist and a photographer. The problem is discovery. Owners are busy running their shops and rarely know who is one block over, let alone which of those neighbors complements their business instead of competing with it.

Neighbor Partner solves that. A shop owner registers their shop in seconds (name, segment, target audience, neighborhood), browses the public list of registered shops, and opens any shop to see up to three AI-ranked non-competing partner suggestions in the same neighborhood. For any pair, one click generates a short promotional blurb they can drop straight into a window sign, a flyer, or an Instagram post.

Who benefits: local shop owners who want more foot traffic without an ad budget, and the neighborhoods that keep more of their trade local. It is the kind of lightweight tool a neighborhood association, a co-working space, or a chamber of commerce could host for its members for almost nothing.

The core safety rule — never suggest a competitor — is enforced in SQL (same neighborhood, different segment) before the AI ever sees the data. The model only reorders a candidate set that is already guaranteed to be safe.

Demo

Run it locally with Docker (see the run steps below) and open http://localhost:5000.

On first start the app seeds a handful of example shops across two neighborhoods (Old Town and Riverside), each with multiple segments, so partner suggestions and promo blurbs work immediately without any manual setup.

Code

All code lives in desafio3/ and is deliberately small — three Python modules, three templates, one stylesheet, and a two-service Docker stack:

app.py — Flask routes and app factory; orchestrates the DB and AI layers, validates the registration form, renders pages.
db.py — SQLite lifecycle: schema init, first-run seeding, and queries. Owns the non-competing candidate query (neighborhood = ? AND segment != ? AND id != ?).
ai.py — Ollama client. suggest_partners() ranks pre-filtered candidates; generate_promo() writes a short blurb. Both apply a 30s timeout and fall back to local heuristics, and neither ever raises.
templates/ — base.html, index.html (shop list + registration form), suggestions.html (partner cards + promo).
static/style.css — one small responsive stylesheet.
Dockerfile + docker-compose.yml — the web + ollama services.

How I Built It

The whole thing is built on an open-source stack with a locally hosted model at its core:

Flask serves the pages and handles form submissions, run under gunicorn in the container.
SQLite stores shops in a single file persisted on a Docker named volume, so data survives restarts with zero database server to manage.
Ollama runs the open-weight llama3.2:1b model entirely on the host. It is small enough to fit on a Raspberry Pi with 4 GB of memory, which is exactly the kind of cheap, always-on box a neighborhood group could afford. ai.py talks to it over HTTP (POST /api/generate, stream: false).

The model does two narrow jobs with short prompts to keep token counts low on modest hardware:

Rank partners — given a selected shop and a numbered list of already-filtered candidates, return the ordered ids of the best up to three, matched on segment complementarity and related target audience.
Write a promo blurb — given two shop names and segments, return one or two short English sentences promoting the collaboration.

Graceful degradation is the headline design decision. Every call into ai.py is wrapped in a cascade of error handling covering timeouts, connection failures, non-200 responses, and malformed JSON. Each failure routes to a local, deterministic heuristic:

If ranking fails, the pre-filtered candidates are ordered heuristically (shared/related target audience, then name) and capped at three.
If blurb generation fails, a template combines the two names, segments, and neighborhood into a usable sentence.

Both paths return the same shape to the routes, so the UI renders identically whether the text came from the model or the fallback. The practical result: on a slow or offline Pi, the app never shows an error page — registration, browsing, suggestions, and promos all keep working. The AI makes the output smarter; it is never a single point of failure.

Why Does Open Innovation Matter?

Running an open-weight model locally instead of calling a closed, hosted API changed what this project could be:

Privacy by default. Shop details and partnership ideas never leave the owner's own hardware. There is no third party logging who is pairing with whom.
It runs on a Raspberry Pi. llama3.2:1b fits in 4 GB of memory, so a neighborhood association can self-host the whole thing on a sub-$100 box. A closed API would push the intelligence into someone else's cloud and someone else's pricing.
No per-call cost. Suggestions and promo blurbs are generated as often as owners like, with zero marginal cost. For a free community tool, metered API calls would be a non-starter.
It works offline. Flaky connectivity does not break it — the model is local, and even if the model itself is down, the heuristic fallbacks keep every feature usable.

Open weights plus a tiny footprint are what let a genuinely useful AI feature live on cheap, private, offline-capable hardware. That is the difference between a tool a neighborhood can actually own and one it merely rents.

My First User

Prize Categories

Run it on a Raspberry Pi (4 GB) with Docker

From the desafio3/ directory:

# 1. Build and start the web + ollama services
docker compose up --build

# 2. In a second terminal, pull the model into the ollama service (one time; cached afterwards)
docker compose exec ollama ollama pull llama3.2:1b

# 3. Open the app
#    http://localhost:5000

The ollama service caches the pulled model on a named volume, and the SQLite database is persisted on its own named volume, so both survive container restarts. The app runs on port 5000.

Repository

GITHUB

Game Night Scoreboard

Paulo Ricardo Engcompaulo — Sat, 10 Oct 2026 20:40:54 +0000

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

What I Built

The Board Game Scoreboard is an interactive electronic scoreboard for board game nights, built for Challenge 2 of Hacktoberfest 2026 with the "Touch Grass" theme (getting people off their screens and into the real world playing together). I made it for my group of friends, who get together to play Uno, dominoes, checkers, and cards, but always waste time arguing over which game to start with and jotting points on scraps of paper that get lost in the mess. The app solves that by organizing the session into simple steps and keeping the scoreboard for the whole night: the group checks off the games they own, registers the players, sets how much each game is worth, records the results as matches wrap up, and, at the end, determines the Winner of the Day complete with a certificate. The approach is deliberately minimalist about screen time: the app is just the organizer and the scoreboard, so the focus stays on the real game, at the table, among people.

Demo

There's no public deployment, because the project is meant to run entirely on the group's own machine, without relying on the internet. To try it out, just clone the repository, go into the touch_grass folder, and bring everything up with docker compose up: in a few seconds the frontend is available at http://localhost:8080 and the local AI service responds at http://localhost:11434. From there, just follow the six steps right in the interface, in English. (Placeholder for a short video demonstrating a game night end to end.)

Code

The full source code is in the touch_grass directory of this repository. The frontend is plain JavaScript (ES modules), HTML, and CSS, organized into pure-logic modules (validation, catalog, players, scoring, suggestion, scoreboard, results, state) along with tests using Vitest and fast-check. The runtime infrastructure lives in the Dockerfile and docker-compose.yml, which define exactly two services: the frontend and the AI service.

How I Built It

The core piece that makes the project work is an open-source AI: a lightweight open-weight model (for example, llama3.2) served by Ollama, running locally in a Docker container alongside the frontend. From the games the group selected and the number of people present, the app builds a prompt and asks the model for a suggested order of matches for the night. The whole project is built around that suggestion, but with graceful degradation as a design principle: if Ollama is unavailable, slow, or returns an error, the app cancels the call after a timeout and falls back to a sequence generated locally in JavaScript that covers each selected game at least once. That way, the AI's intelligence enriches the experience when it's available, and the local fallback ensures game night never stalls because of it.

Why Does Open Innovation Matter?

The open-source approach works best here precisely because game night happens at someone's living room table, often without reliable internet. With an open-weight model running locally via Ollama, the app keeps working offline, without depending on any external API. The session data — player names, games, and scores — stays in the browser's localStorage and in the calls to the local service, remaining on the user's machine instead of traveling to third-party servers, which preserves the group's privacy. And since there's no closed API in the way, there's no per-request cost or usage limits: anyone can spin up the project and use it freely. A closed API wouldn't make this possible without a permanent connection, without cost, and without giving up data privacy.

Example

Repository GITHUB

GITHUB

Trigonometry Visualizer

Paulo Ricardo Engcompaulo — Mon, 05 Oct 2026 00:07:35 +0000

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

What I Built

I built Trigonometry Visualizer, a small Flask web app for my friend Marina, who recently went back to school and has been struggling to connect the trigonometry formulas in her textbook to what they actually look like. She kept telling me that y = sin(x) was just a string of symbols until someone drew the curve for her.

So the app does exactly that. The Learner picks one of five concepts — sine, cosine, tangent, right triangle, or unit circle — either from a dropdown or by typing it in, and the app renders a matplotlib figure with the mathematical formula embedded right in the picture. She can download any figure as a PNG to paste into her notes, and she can ask for a plain-English explanation of the concept generated by a local AI model. The whole thing is intentionally minimal and English-only, built to be genuinely useful for one person learning the basics rather than a sprawling math suite.

The core promise is graceful degradation: the figure, formula, and download always work even when the AI explainer is slow or offline, so a flaky model never gets in the way of studying.

Demo

Run it locally with Docker:

docker compose up

Then open http://localhost:5000, choose a concept (try "sine" or " Unit Circle " — input is case- and whitespace-insensitive), view the figure and formula, click Download to save the PNG, and click Explain for a plain-English walkthrough.

A short screen recording of the render → download → explain flow will be attached to the DEV post.

Code

The full source lives in the desafio1/ project folder:

app.py — Flask routes: GET / (page), GET /render?concept=X[&download=1] (PNG), GET /explain?concept=X (JSON explanation)
concepts.py — the five-concept registry with normalization and validation
renderer.py — matplotlib Agg draw functions that embed each formula in the figure
explainer.py — the Ollama client that degrades gracefully on any failure
docs.py — validator for this very submission file
templates/, static/ — the HTML/CSS/JS frontend
Dockerfile, docker-compose.yml — the two-service (web + ollama) stack

SUPPORTED = ["sine", "cosine", "tangent", "right triangle", "unit circle"]

The GitHub repository can be embedded directly in the DEV post.

How I Built It

The explanation feature is powered entirely by open-source AI: a local Ollama service running the open-weight llama3.2 model. The Flask web service talks to the ollama service over the docker-compose network at http://ollama:11434, posting the selected concept and its formula to /api/generate with stream: false.

Everything runs on your own machine — no third-party API keys, no cloud calls, no data leaving the container network. The explainer.py module wraps the call with a 30-second timeout and catches every failure mode (timeout, connection error, non-200 status, malformed JSON), returning a friendly "explanation unavailable" message instead of ever crashing. That way the open model enriches the experience when it's up, and the app stays fully usable when it isn't.

The rest of the stack is deliberately lean: Python 3.12, Flask for routing, matplotlib (Agg backend) for headless figure rendering, and requests for the Ollama client — all wired together bottom-up so each module is independently testable.

Why Does Open Innovation Matter?

Open innovation is what made this project possible as a weekend build for a single friend. Using an open-weight model through Ollama meant I could ship an AI tutor that costs nothing to run, needs no API key, and keeps a student's questions entirely on her own machine. A closed API would have added a billing account, rate limits, and a privacy footprint — all overkill for one person learning trig at her kitchen table.

More than cost, open models let me design for graceful degradation on my own terms: because the model runs locally and is swappable, I control the timeout, the fallback behavior, and even which model to pull. If llama3.2 is too heavy on an older laptop, swapping in a smaller open model is a one-line change. That kind of transparency and substitutability is exactly what open innovation unlocks — the app belongs to the people running it, not to a vendor's roadmap.

My Agent Session

I built this spec-first with Kiro: requirements → design → tasks, then implemented each module in dependency-wave order. The agent session covering the build will be linked from the DEV post.

Result: GITHUB

Prize Categories

Build for a Friend
Best use of a local, open-weight model (Ollama / llama3.2)