DEV Community: Vicente G. Reyes

ScopeGuard: an open-weight model that tells freelancers when "quick one" means "paid one"

Vicente G. Reyes — Thu, 15 Oct 2026 09:11:27 +0000

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

What I Built

Every freelancer knows this message:

"Hey! Quick one: could you also add a shop page so we can sell merch? Shouldn't take long 🙏"

Is a shop page in the contract? You'd have to dig out the statement of work (SOW), find the clause, work out how many hours it is, and then write a reply that says no without souring a client you like. Most of us skip that, say "sure", and do the work for free. Do that a few times a month and it adds up to real money. That's scope creep.

ScopeGuard is a small web app that does the awkward part for you:

You save a client's SOW and your hourly rate. Paste it in, or import the PDF or Word file the client signed.
You paste in a client request from email, Slack, a ticket, or your call notes.
An open-weight model (gpt-oss-120b by default, served through Groq) gives you:
- a verdict: in scope, out of scope, or ambiguous
- the exact SOW clause it based that on
- an estimate of the extra hours
- a draft reply ready to send: a short confirmation if the work is covered, a polite change-order offer with a price if it isn't, or clarifying questions if the SOW is unclear

A dashboard adds up the scope creep caught across all your contracts. In other words, the billable work you would otherwise have done for free.

Who pays for it? Solo freelancers and small agencies on fixed-scope projects or retainers: developers, designers, copywriters, video editors. If ScopeGuard catches even one out-of-scope request a year, a $12/month subscription would pay for itself. And because a check on a shared open-weight model costs about a twentieth of a cent (numbers below), a $12 price leaves plenty of margin.

Demo

Live link: https://scopeguard.icvn.tech
Video Demo from Vidyard: https://share.vidyard.com/watch/7DrBCnxdrSMVdPe4GAkHLV

The flow in the demo:

New contract. Fill in the client and your rate, then paste the SOW or click Import from file to pull the text out of a PDF or .docx. You review the text before saving.
Contract page. The SOW stays pinned on the left ("What you agreed to"). On the right are the request form and a feed of checked requests that you can filter by verdict.
Each result card shows the verdict badge and the model's confidence. It also shows the quoted clause with a "Quote verified" or "Not found in SOW, double-check" badge, the hours and the change-order price, and the draft reply with a copy button. A footer lists the model, the latency, and the token counts.

Screenshots:

Code

reyesvicente / ScopeGuard

Scope-creep detector for freelancers, powered by a hosted open-weight model.

ScopeGuard

Scope-creep detector for freelancers, powered by a hosted open-weight model.

License: MIT

How it works

Save a client's statement of work (SOW) and your hourly rate.
Paste a client request (email, Slack, ticket, call notes).
An open-weight model (default: openai/gpt-oss-120b via Groq) returns a verdict (in scope / out of scope / ambiguous), quotes the SOW clause it relied on, estimates the extra hours, and drafts a reply.
ScopeGuard checks that the quoted clause really exists in the SOW, and fills in the change-order price itself (the model never does the arithmetic).

The dashboard totals the out-of-scope hours caught across all your contracts.

Guardrails

Constrained output. The request sends a JSON Schema as response_format, and every field is validated again in scopeguard/scope/services.py.
Code does the math. The model writes {{ESTIMATE}} where a price belongs; Python computes hours × rate.
Verified quotes. A cited clause that isn't…

View on GitHub

MIT-licensed. Django 6 + Django REST Framework on the backend, React 18 + Vite on the frontend, and an open-weight model behind an OpenAI-compatible API for inference.

How I Built It

The stack

Layer	Choice
Model	gpt-oss-120b (open weights, Apache 2.0) by default; any open model is one setting away
Inference	Groq, via the OpenAI-compatible `/chat/completions` API
Backend	Django + DRF, built from cookiecutter-django, PostgreSQL; `pypdf` and `python-docx` for contract import
Frontend	React 18 + Vite + TypeScript, TanStack Query, Zustand, React Hook Form + Zod, my own `ice-ds` neubrutalist component library
Observability	Sentry: errors, request traces, and AI agent spans for every scope check (model, tokens, latency)
Hosting	Render for everything: one Docker web service serves the React app and the API on `scopeguard.icvn.tech`, plus Postgres and Key Value

Why it isn't self-hosted (anymore)

The first version ran Gemma through Ollama as a container next to Django. That works well on a laptop. Then I priced hosting it: CPU-only inference for a small model with a context window big enough for a real SOW needed Render's Pro Plus plan, about $175 a month, before a single user signed up. For a $12 side hustle, that's backwards.

So inference moved to a hosted provider that serves open weights. The model is still open, but now someone else's GPUs are shared across thousands of apps, and I pay per token. Hosting ScopeGuard now costs about what any small Django app costs.

The client didn't need an SDK either way. Django talks to the API over plain HTTP with only the Python standard library, and the whole provider choice is three env vars:

LLM_BASE_URL=https://api.groq.com/openai/v1
LLM_MODEL=openai/gpt-oss-120b
LLM_API_KEY=gsk_...

I've pointed it at Hugging Face Inference Providers and at Groq. Together, OpenRouter, and vLLM or Ollama on your own hardware speak the same API, so they should take the same three variables, but I haven't tested them.

The switch between providers happened sooner than I planned. ScopeGuard started on Hugging Face, and partway through testing a check came back with this:

Model API returned 402: {"error":"You have no remaining credits. Purchase pre-paid credits to continue using Inference Providers. ..."}

The free monthly credit was gone. With a closed model, that's where the afternoon ends: pay up or rewrite the integration. Here, the same gpt-oss-120b weights are also served by Groq, so I changed the base URL and the key. It wasn't quite zero code: Groq rejected the first requests for two reasons (see the first gotcha below), and each was a one-line fix. Then the demo contract's requests came back right:

Client request	Verdict	Confidence	Cited clause	Time
"Could you also add a shop page so we can sell bags of our beans and some merch online?"	out of scope	0.98	5.1, quote verified	1.6 s
"Can we make sure cafés can book a tasting slot straight from the site? We already use Calendly for that."	in scope	0.98	2.3, quote verified	2.2 s

Each check used about 1,050–1,070 prompt tokens and 430–490 completion tokens. At Groq's listed price for this model (around $0.15 per million input tokens and $0.60–0.75 per million output), that's roughly $0.0005 a check.

Importing the contract instead of pasting it

Nobody keeps their SOW as plain text. It's the PDF the client signed or a Word doc with the scope in a table. So the contract form has an Import from file button that accepts PDF, .docx, TXT, and Markdown up to 10 MB.

The API reads the file, returns the text, and throws the file away. Only the text you review and save is kept. For documents that are often under NDA, not keeping a copy is the simplest privacy feature there is.

Two details mattered more than I expected:

Word tables. SOWs love tables ("Deliverable | Included? | Notes"). Reading only paragraphs silently drops them, so the extractor walks paragraphs and tables in document order.
Scanned PDFs. A scanned contract is just images, so there's no text to extract. Instead of saving an empty SOW, the import says so: "No text found in this file. Scanned PDFs aren't supported yet, so paste the text instead." Password-protected and damaged files get their own messages too.

Making a model reliable enough to send to a client

A model's reply ends up in an email to a paying client, so most of the engineering went into not trusting it more than necessary. Four decisions did most of the work.

1. Constrained JSON, not "please respond in JSON". The request sends a JSON Schema in response_format, and providers that support structured output constrain decoding to match it. The model cannot return a verdict outside the enum:

VERDICT_SCHEMA = {
    "type": "object",
    "properties": {
        "verdict": {"type": "string", "enum": ["in_scope", "out_of_scope", "ambiguous"]},
        "confidence": {"type": "number"},
        "reasoning": {"type": "string"},
        "cited_clause": {"type": "string"},
        "estimated_hours": {"type": "number"},
        "draft_reply": {"type": "string"},
    },
    "required": ["verdict", "confidence", "reasoning",
                 "cited_clause", "estimated_hours", "draft_reply"],
    "additionalProperties": False,
}

The service still validates every field afterwards. Confidence is clamped to 0–1, hours are clamped and rounded, and any unknown verdict marks the check failed rather than storing garbage.

2. Never let the model do the math. Language models are bad at arithmetic, and a wrong number on a change order damages your credibility with the client. So the prompt tells the model to write the literal token {{ESTIMATE}} wherever the price belongs, and Python fills it in:

def fill_estimate(reply: str, *, hours: Decimal | None, contract: Contract) -> str:
    """Prices are computed here, never by the model, so the math is always right."""
    if ESTIMATE_PLACEHOLDER not in reply:
        return reply
    cost = estimate_cost(hours=hours, contract=contract)
    if hours is None or cost is None or not cost:
        text = "a quote to follow"
    else:
        rate = f"{contract.hourly_rate:,.2f}/hr"
        text = f"{contract.currency} {cost:,.2f} ({hours.normalize():f} hours at {rate})"
    return reply.replace(ESTIMATE_PLACEHOLDER, text)

The model does the judgment ("about 12 hours of work"). Code does the arithmetic ("USD 960.00").

3. Check the model's quotes. The quoted clause is what makes a reply convincing ("per section 3, e-commerce isn't included"). It's also the part a model is most likely to make up. So every cited_clause is checked against the real SOW, ignoring whitespace and case:

def clause_in_sow(clause: str, sow_text: str) -> bool:
    """Guard against hallucinated citations: the quote must exist in the SOW."""
    if not clause:
        return False
    return _normalize(clause.strip("\"'“”")) in _normalize(sow_text)

If the quote isn't found, the UI says so with a warning badge instead of quietly showing an invented contract term. Ignoring whitespace also matters for imported contracts, because PDF text comes out with line breaks wherever the page wrapped.

4. Fail loudly, not with a 500. If the API is down, rejects the key, runs out of credits, times out, or returns broken output, the check is saved with verdict = failed and a readable error, and the card offers a Re-run button. That's exactly how the 402 above showed up: as a red card with the provider's message, not a crash.

Gotcha 1: "OpenAI-compatible" isn't one standard

Every provider says "OpenAI-compatible". My first two requests to Groq still failed, and neither failure was about the model.

First, a 403 with nothing but error code: 1010. That isn't Groq; it's Cloudflare in front of Groq, and 1010 means "your client's signature is blocked". My stdlib client sent urllib's default User-Agent: Python-urllib/3.14, which Cloudflare treats as a bot. The fix is one header:

USER_AGENT = "ScopeGuard/1.0 (+https://github.com/reyesvicente/ScopeGuard)"

Second, a 400 about the schema:

invalid JSON schema for response_format: 'scope_verdict':
`additionalProperties:false` must be set on every object

Groq's strict mode requires every object to forbid extra keys, which is also what OpenAI's strict structured outputs require. One more line in the schema, shown above.

Neither of these showed up in the mocked tests, because the mock never sees a User-Agent or validates a schema. If you build on "OpenAI-compatible" APIs so you can switch providers, run one real request against each provider before you trust it. The client also strips a markdown fence around the JSON and rejects anything that isn't a JSON object, as a guard in case another provider is looser than these two.

Gotcha 2: a "secure" default that broke every save

The first time I saved a contract through the React app, Django answered 403 Forbidden, and the form showed nothing at all.

Two bugs were stacked. The settings had CSRF_COOKIE_HTTPONLY = True, which sounds like hardening. But a single-page app has to read the CSRF cookie in JavaScript to send it back as the X-CSRFToken header, so every write went out with an empty token. Django's own docs say HttpOnly on the CSRF cookie gives no practical benefit, so I turned it off.

The second bug was why the failure was invisible. The 403 body was {"detail": "CSRF Failed: ..."}, and the frontend treated every key in the error object as a form field. There's no field called detail, so the message was dropped, and because "field errors" existed, the general error banner stayed hidden too. Now detail and non_field_errors always surface as a banner, and a CSRF failure fetches a fresh token and retries once.

The tests hadn't caught it because DRF's force_authenticate skips CSRF entirely. There's now a test that does what the browser does: load /api/users/me/, read the cookie, and send it back with the write.

One domain, one service

The first deploy split the app: the React build on Vercel at scopeguard.icvn.tech, and the API on Render at api.scopeguard.icvn.tech. To keep the browser off two origins (CORS with credentials, shared cookie domains, more CSRF configuration), vercel.json rewrote /api/*, /accounts/*, and /static/* to the API host. It worked, but it was two platforms, two DNS records, and a proxy hop for every request. Django also thought it was on the api. host, so the account adapter had to rewrite links in verification and password-reset emails to the public domain.

The production Docker image already had a Node stage that builds the frontend into Django's static files, and a view that serves index.html for the app's routes. So I dropped Vercel and pointed scopeguard.icvn.tech straight at the Render service. Now there's one deploy, one origin, and no proxy.

One gotcha: Render's own domains already sit behind Cloudflare, so my Cloudflare CNAME has to be DNS only. With the orange-cloud proxy on, Cloudflare refuses to proxy to another Cloudflare IP and shows Error 1000: DNS points to prohibited IP.

Tracing the agent with Sentry

A scope check is one agent step: build a prompt from the SOW, call the model, validate the structured verdict, check the quote, and draft the reply. When a check is slow or wrong, I want to know which part went wrong, so each check is traced in Sentry as two nested spans that follow Sentry's AI agent conventions:

gen_ai.invoke_agent wraps the whole check and records the verdict, whether the cited clause was found in the SOW, and where the request came from. A failed check marks the span as an error.
gen_ai.chat wraps the model call and records the model, input and output tokens, and latency. Sentry's AI Agents view turns those into per-model latency and token charts.

with sentry_sdk.start_span(op="gen_ai.chat", name=f"chat {settings.LLM_MODEL}") as span:
    span.set_data("gen_ai.request.model", settings.LLM_MODEL)
    result = _chat_json(system=system, user=user, schema=schema)
    span.set_data("gen_ai.usage.input_tokens", result.prompt_tokens)
    span.set_data("gen_ai.usage.output_tokens", result.completion_tokens)

The spans deliberately leave out prompts and replies. SOWs are often under NDA, so the trace says how a check went without storing what the contract says. Sentry is optional: with no SENTRY_DSN, the spans do nothing.

Tests

The scope app has 37 tests:

the model client: request shape, auth and User-Agent headers, fenced JSON, non-JSON output, missing key, HTTP errors
contract import: PDF, Word tables, text encodings, scanned and damaged files, unsupported types, size limits
services: unique slugs, verdict storage and pricing, hallucinated quotes, unknown verdicts, the model server being down
the API: auth, the response envelope, per-user privacy, pagination, filtering, re-runs
the browser's real CSRF flow

Five more cover running behind a host that isn't the public one: the email link rewriting, and a write arriving with one host but another origin. The single-domain deploy doesn't need them today, but they keep the split setup an option. The network is mocked, so the tests run in seconds in CI with no API key. Ruff and mypy are clean. The mocks are also why the two Groq bugs got through: only a real request found them.

Why Does Open Innovation Matter?

Moving off self-hosting changed where the model runs. It didn't change why it's an open model.

1. No lock-in on the most important part. The model and the provider are three env vars. If a provider raises prices, rate-limits me, runs out of free credits, or shuts down, I move to another one that serves the same weights, and the verdicts don't change underneath my users. That isn't hypothetical: it happened during this build. It took two env vars and two one-line fixes, and the fixes now work for every provider. With a closed model, there is one vendor, and when it deprecates a model version, your product's behavior changes on their schedule.

2. Privacy has an exit. A freelancer's SOWs and client messages are often under NDA. Uploaded contract files are never stored. Today the default model host is a shared provider, which is the right trade for a $12 product. But because the weights are open, a freelancer or agency that can't send contracts to a third party can run the same model on their own hardware with vLLM or Ollama, point LLM_BASE_URL at it, and get the same app. A closed API can only promise not to train on your data.

3. Competition keeps the pricing honest. Every check sends the entire SOW as context, so the heaviest users (long contracts, chatty clients) cost the most to serve. Open weights mean many providers serve the same model and compete on price per token. That keeps a check around a twentieth of a cent today, and the 30/hour per-user throttle caps the worst case.

4. Room to specialize. "Is this billable?" is a niche judgment that general-purpose models handle with generic caution. The next feature on my list is letting users correct a verdict, and every correction would be a labeled example. Open weights mean those examples could fine-tune a model that's better at this one task than a much bigger general model. You can't do that with a closed model.

The honest trade-off: hosted inference means contracts leave your server by default. ScopeGuard is upfront about that, and the open model is what makes "run it yourself" a real option instead of a promise.

Prize Categories

Best Use of a .tech Domain: It's live on scopeguard.icvn.tech.
Best Use of Sentry Agent Tracing: Every scope check is traced as a gen_ai.invoke_agent span with a nested gen_ai.chat span. The trace records the model, tokens, latency, and the verdict, but not the contract text.
Best Use of Render: The whole product runs on Render: the React front end and Django API in one Docker web service, plus Postgres and Key Value. The service is the agent's runtime: it builds the prompt from the SOW, calls the open-weight model, validates the structured verdict, and drafts the change order.

Is SaaS dead? Are we just building software for ourselves?

Vicente G. Reyes — Mon, 12 Oct 2026 10:58:49 +0000

I saw a post on X a few days ago that says SaaS is dead and we just build software for ourselves. What's your take on this? Kinda realized it as real since I just built GiggleGigs initially for others but then realized I should use it since I have free time.

Tala: Free Audio-to-Text for My Designer Friend (No Signup, No Credit Card)

Vicente G. Reyes — Sat, 03 Oct 2026 08:10:14 +0000

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

What I Built

Paolo, a designer I work with, asked me a simple question:

"Do you know an app that turns audio into text that doesn't make me sign up or put in a credit card?"

I couldn't name one. Every tool I knew wanted an account, a "free trial" that asked for a card up front, or had a monthly minutes cap. Paolo just wanted to drop in a recording of a client call or a voice memo and get the words back.

So I built Tala (Tagalog for note or record). It does one thing:

Audio in. Text out. No signup, no card, no catch.

Upload or record: drag in a voice memo, meeting, or interview (mp3, m4a, aac, wav, ogg, webm, even mp4 video), or record in the browser and play it back before sending.
~100 languages: auto-detected, including Tagalog/Filipino, which matters for us. There's also a one-click translate to English option.
Exports: copy the text, or download plain text, SRT, or WebVTT. Paolo can drop the subtitle files straight into video edits.
Timestamps toggle: see when each line was said.
A private link instead of a signup: every transcript gets a hard-to-guess URL, and your browser remembers the ones you made.
Optional accounts: if you want your transcripts on every device, sign up with an email and password to get a searchable My transcripts history. It's never required to transcribe. Forgot-password emails a one-time reset link.
Self-destructing data: the audio is deleted the moment it's transcribed. The text deletes itself after 72 hours, or right away with Delete now.

Demo

🌐 Try it live: tala.vicentereyes.org. No signup, just drop in a file.

▶️ Watch the demo video

The flow is three screens:

Home: drop a file or hit Record now, pick a language (or leave it on auto-detect), and click Turn it into text.
Progress: you land on your private link right away. It shows Preparing audio, then a live progress bar with an estimate of the time left. You can close the tab and come back.
Transcript: copy, download TXT/SRT/VTT, toggle timestamps, or delete it.

Code

The full source is on GitHub: github.com/reyesvicente/tala. Run it locally with Docker and npm by following the README.

reyesvicente / tala

Tala — audio to text, no signup

Free audio/video → text transcription. No signup needed, no credit card. Built for Paolo for the DEV Hacktoberfest Weekend Challenge ("Build for a Friend").

Open-weight model: OpenAI Whisper via faster-whisper (CTranslate2, int8 on CPU). No third-party AI API is called.
Privacy: audio is deleted the moment it's transcribed; transcripts self-destruct after RETENTION_HOURS (default 72). Access is by unguessable link only.
Upload a file or record in the browser · auto-detect ~100 languages · translate to English · export TXT / SRT / WebVTT.

Using Tala

1. Add your audio

On the home page, pick one:

Upload a file: drag it onto the box, or click to browse. Most audio and video formats work mp3, m4a, aac, wav, flac, ogg, webm, mp4, mov, and more. Max 100 MB.
Record now: click Start recording, allow…

View on GitHub

How I Built It

The open-source AI at the core: Whisper

The model is OpenAI's Whisper, an open-weight speech recognition model, run through faster-whisper. faster-whisper reimplements Whisper on CTranslate2, so it runs on a plain CPU with int8 quantization. No GPU and no external API.

React (Vite) ──/api──▶ FastAPI ──▶ PostgreSQL
                         │
                         └─▶ worker thread ──▶ faster-whisper (local CPU)

Backend: FastAPI + SQLAlchemy 2 + Alembic + PostgreSQL

POST /api/transcriptions streams the upload to disk in 1 MB chunks, enforcing the size limit without holding the file in memory. It saves a pending row and immediately returns 202 with the slug.
One in-process worker thread runs Whisper on one file at a time, so a CPU-heavy model doesn't overload the machine. On startup, unfinished jobs go back into the queue, so a restart doesn't lose anyone's work.
The audio file is deleted in the same step that saves the transcript, and also when a job fails. A periodic purge removes expired transcripts.
Optional accounts use server-side sessions: the browser holds an httpOnly cookie, the database stores only a SHA-256 of it, and passwords are hashed with Argon2. Logging out ends the session on the server, and resetting a password logs out every device. Forgot-password answers the same way whether or not the email exists, and reset links arrive through Resend.
Rate limits on login, sign-up and password resets: 5 failed logins lock that email for 15 minutes, and blocked requests get a 429 with Retry-After.
The tests swap Whisper for a fake transcriber, so all 35 tests, from uploads to the full password-reset flow, run in seconds.

Frontend: React 18 + Vite + TypeScript

TanStack Query polls the transcript every 1.5 seconds only while it's pending or processing, then stops.
Zustand (persisted) stores the "made in this browser" list, so people who never sign up still keep track of their transcripts.
MediaRecorder handles in-browser recording, picking whatever codec the browser supports. The backend decodes all of them through PyAV.
The UI is built with ice-ds, my neubrutalist component library.

Deployment: Render. One Docker image builds the React app, installs the API, and bakes the Whisper model in at build time. FastAPI serves the frontend and the API from one origin, and the container never contacts the model hub at runtime. A render.yaml Blueprint defines the whole stack: a Docker web service running Whisper on CPU (1 CPU, 2 GB) plus Render Postgres, both in Singapore, close to Paolo. Every push to main redeploys automatically, and the live site is at tala.vicentereyes.org.

What testing on a real recording taught me

My first test was an 11-second clip, and it worked well. Then I tried a real 70-minute Tagalog meeting recording, and two things broke.

1. It was far too slow. The progress bar barely moved. I benchmarked a 3-minute slice of the recording on my 4-core laptop:

Settings	Speed
Sequential decoding, beam 5 (my original settings)	0.6× real time
Sequential decoding, beam 1	0.7× real time
Batched decoding (`BatchedInferencePipeline`), batch 8, beam 1	3.8× real time

Batched decoding first uses voice-activity detection to cut the audio into speech chunks, then decodes several chunks at once. Switching to it took the full 70-minute file from about 2 hours to 13 minutes. I also added a Preparing audio stage and a time-left estimate, so a long job no longer looks frozen.

2. Whisper hallucinated. On hard audio, small Whisper models get stuck in loops, and the transcript filled up with lines like ngayon ngayon ngayon … and kakakakaka…. One unbroken loop was so long it pushed the page wider than the screen. Batched mode decodes at a single temperature, so Whisper's usual retry-on-repetition fallback never runs. I added:

a decoder repetition_penalty
a small cleanup step that collapses repeated phrases and in-word loops (sa-ma-ma-ma-ma → sa-ma), drops segments that are just ..., and merges duplicate lines
CSS so long strings wrap instead of overflowing

On that meeting, the cleanup cut the transcript from 5,458 words to 1,425. That tells you how much of it was noise.

The honest result: the cleanup removes junk, but the default base model still struggles with Taglish conversation. Because the model is open, fixing that is a config change rather than a vendor negotiation: WHISPER_MODEL=small or large-v3-turbo trades speed for accuracy.

One more bug: the first real transcription failed with open() got an unexpected keyword argument 'metadata_errors'. faster-whisper 1.2.1 passes an argument that PyAV 19 removed. Pinning av==15.1.0 fixed it, and the failure path worked as designed: the job was marked failed, the user saw a clear message, and the audio was still deleted.

Why Does Open Innovation Matter?

The whole idea of Tala, no signup and no credit card, only works because the model is open.

It costs nothing per minute. Hosted speech-to-text APIs bill per minute of audio. A free product built on one needs an account to rate-limit you, or a card to bill you, which is exactly the friction Paolo wanted to avoid. With Whisper running on my own server, the cost is the server, so a free tool with no strings attached actually works.

The audio never leaves a machine I control. Paolo's recordings are client calls and design reviews. With a closed API, every file goes to a third party under their retention policy. With Tala, the audio is decoded on the server it was uploaded to and deleted minutes later. I can promise that because I can read every line of code it passes through.

I could open it up and fix it. When Tala was too slow on long files, I didn't wait for a provider to ship a faster tier. I benchmarked decoding strategies on my own laptop and switched to batched inference: 6× faster in an afternoon. When it hallucinated on Tagalog, I could see exactly why (no temperature fallback in batched mode) and add guards. A closed API is a black box: you get what it returns.

I can swap models freely. tiny for a cheap host, large-v3-turbo for accuracy. It's one environment variable, with no lock-in and no deprecation emails. If Tagalog accuracy is still not good enough, the weights are open, so fine-tuning is an option.

It runs on a laptop. The local dev setup is the full product. No API keys, and no internet after the model downloads once. Anyone can clone the repo and run their own private transcriber.

Where closed is better: hosted APIs run on GPUs, so long files finish faster, and they offer speaker labels. On a modest CPU, an hour of audio takes a while. For Paolo's usual 5–15 minute memos and calls, that trade-off is fine.

My Agent Session

I built Tala pair-programming with Claude Code: scaffolding, the benchmark that found the batched-decoding speedup, and debugging the hallucination loops all happened in that session.

Prize Categories

Best Use of Render: Render is Tala's AI runtime. The open-weight Whisper model runs inside a Render web service, with Render Postgres for jobs and transcripts, all defined in a one-file Blueprint.

Thanks for reading, and if you need audio turned into text, no signup required. 🎧

[FOR HIRE] Full-stack developer, 2 build slots open for November

Vicente G. Reyes — Sun, 27 Sep 2026 16:55:47 +0000

If you want something live before the year ends, November is the last good month to start. December disappears into the holidays.

I'm Vicente, a freelance developer since 2018. I've shipped 25 client projects for businesses in the UK, US, and Australia, including 11 production Shopify stores.

What I can take on in November:
→ Shopify stores: new builds, rebuilds, and pre-sale fixes ahead of 11.11 and 12.12
→ WordPress sites: business sites, WooCommerce, and cleanup of slow or broken installs
→ Web apps: Django + React for SaaS, dashboards, internal tools, and custom platforms

Portfolio: vicentereyes.org

Only 2 slots, so both projects get my full attention. Book a call at https://calendly.com/vicentereyes, or DM me your site link or idea and I'll reply within 24 hours with how I'd approach it.

GiggleGigs: A Job Board That Actually Uses AI Where It Helps

Vicente G. Reyes — Tue, 22 Sep 2026 16:57:43 +0000

Most job boards are glorified spreadsheets with a search bar. GiggleGigs isn't. It's a two-sided marketplace — "Find Work. Hire Talent." — built to close the gap between "I posted a job" and "I hired someone good," using AI at exactly the three points where it saves real time: writing the posting, writing the application, and screening the results.

Here's what's actually under the hood, and why it's worth a look.

The Problem It Solves

Job boards fail in a predictable way: employers post vague listings because writing a good one is tedious, candidates send generic applications because tailoring one is tedious, and then the employer drowns in a stack of applications that all look the same. Nobody's time gets saved — the tedium just moves downstream.

GiggleGigs attacks all three steps at once:

Companies write a two-sentence prompt and GiggleGigs' AI job-description writer expands it into a full posting with requirements, budget framing, and structure.
Seekers get an AI-drafted, job-specific cover letter instead of copy-pasting the same one everywhere — and can even upload a resume during onboarding and have Gemini auto-fill their entire profile (name, bio, skills, headline, links, experience) in seconds.
Companies then use an AI application screener that match-scores and summarizes every applicant against the job's actual requirements, so reviewing 40 applications doesn't mean reading 40 applications.

That's the pitch: less busywork on both sides of the transaction, and a marketplace that gets more useful the more people use it.

What's Actually Built

This isn't a prototype — it's a full production-shaped Django + React application with a genuinely deep feature set:

For job seekers

Skill/location/budget/timeline-filtered job search
One-click applications with optional resume upload (PDF/DOC/DOCX, validated server-side)
AI cover letter generation and AI resume-parsing onboarding
Real-time application tracking across a five-stage pipeline (Pending → Reviewing → Interviewed → Hired/Rejected/Withdrawn)
Application withdrawal, favorited jobs, and a daily digest email of new jobs matching your skills

For companies

Full job posting management (hourly or fixed price, detailed requirements)
A filterable, sortable applicant dashboard with live hiring-pipeline stats
AI-powered candidate search and AI match-scoring per applicant
Star-rating feedback to candidates, resume downloads, and team invitations for multi-seat company accounts
Credit-based billing via PayPal to unlock posting and candidate contact

Platform-wide

Real-time notifications over WebSockets (Django Channels + Daphne ASGI) — no polling, no refresh
JWT auth plus django-allauth for email/social login
Celery + Redis background processing with Celery Beat and Flower for monitoring
Content moderation tooling for jobs, companies, and users
A full analytics dashboard for staff on jobs and user activity
An API-first backend (Django REST Framework, OpenAPI schema via drf-spectacular) behind a React 18 + Vite SPA

Every one of these shipped incrementally and is live in the codebase today — this is a v1.7 product with a real changelog, not a feature wishlist.

The Business Model Is Already Wired In

GiggleGigs isn't just feature-complete — it's monetization-complete. Companies post their first two jobs a month for free (liquidity first, revenue second), and then convert through one of:

$29 single-post unlock — the low-commitment first purchase, for a company that just got applicants and wants to actually contact them
Starter ($49/mo) — for companies hiring regularly
Growth ($99/mo) — adds full candidate search
Annual plans at two months free

That progression — free listing → paid contact unlock → subscription — is a deliberate sequencing choice: liquidity (seekers applying) has to exist before employers will ever pay, so the free tier isn't a loss leader, it's the engine that makes the paid tier valuable at all.

Why the Engineering Choices Matter

A few decisions stand out as the kind that pay off later rather than look impressive now:

Services layer, not fat views — business logic lives outside the DRF views, which keeps the API surface thin and testable.
Proxy user model (Company / Seeker / Employee subtypes) instead of bolting role flags onto a single User table — cleaner permissions, cleaner queries.
Consistent { data, message, errors } API envelope across every endpoint, which makes the frontend's error handling and loading states uniform instead of ad hoc per-page.
Docker-only local workflow — Postgres, Redis, Django, Celery, Channels, and MailHog all come up together with one command, so "works on my machine" isn't a category of bug here.
Real-time built on Channels from day one, not retrofitted — notifications, status changes, and messaging all ride the same WebSocket infrastructure.

None of this shows up in a demo GIF, but it's the difference between a project that can take on its next ten features and one that needs a rewrite to get there.

Try It

GiggleGigs is a working, self-hostable job board and marketplace — clone it, docker compose -f local.yml up, and you have Postgres, Redis, Celery, Channels, and MailHog running together in one shot. If you're evaluating job-board platforms, building a niche talent marketplace, or just want to see AI applied to hiring in a way that removes tedium instead of adding a chatbot nobody asked for, it's worth a look.

Find work. Hire talent. Skip the busywork.

I'm the dev who messes shit up on Figma. I'm sorry. I do not do it on purpose.

Vicente G. Reyes — Mon, 21 Sep 2026 14:40:16 +0000

12 sections, 3.5 hours. Thank God for Claude MCP, Shopify MCP and Figma MCP. 👆

Vicente G. Reyes — Mon, 21 Sep 2026 11:49:38 +0000

The CI/CD Pipeline That Was Lying to Us: A Deploy Debugging Story

Vicente G. Reyes — Tue, 01 Sep 2026 13:10:03 +0000

I had a GitHub Actions workflow called Deploy to DigitalOcean. It had been sitting in the repo for weeks, fully wired up — SSH action, secrets references, the works. And yet every single time I shipped a backend change, I still had to SSH into the droplet and run git pull by hand.

I hadn't stopped to ask why until I actually went looking. It turned out the pipeline wasn't broken in any one obvious way — it was broken in six small, unrelated ways, stacked on top of each other, each one hiding the next. This is the story of digging through all of them, in the order I actually found them.

Act 1: The Deploy Job That Never Ran

The setup looked correct on paper. deploy.yml was gated like this:

on:
  workflow_run:
    workflows: ['CI']
    branches: ['main']
    types: [completed]

jobs:
  deploy:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}

Reasonable: only deploy if CI passed. So the first thing worth checking wasn't the deploy job at all — it was whether CI had ever passed on main.

gh run list --workflow=ci.yml --limit 5

Every single row: failure. Every deploy run: skipped. The deploy pipeline wasn't broken — it was doing exactly what it was told, gating correctly on a CI workflow that had never once gone green on main. I hadn't connected those dots because the failures and the missing deploys lived in two different tabs of the Actions UI.

Act 2: Two Bugs Wearing One Trenchcoat

gh run view <run-id> showed two jobs failing for completely unrelated reasons.

The linter job died immediately:

The specified python version file at: .python-version doesn't exist.

.python-version was sitting right there in the repo root. Except it wasn't — it was in .gitignore, left over from a pyenv boilerplate line nobody had questioned. actions/setup-python's python-version-file input needs the file to actually exist in the checkout, and a gitignored file never reaches CI no matter how real it looks on disk locally.

The frontend job died differently:

Error: [vitest-pool]: Failed to start forks worker for test files ...
Caused by: TypeError: webidl.util.markAsUncloneable is not a function

That error has nothing to do with my test code. ci.yml pinned node-version: '20', but jsdom@30 (a Vitest dependency) requires:

"engines": { "node": "^22.22.2 || ^24.15.0 || >=26.0.0" }

Node 20 doesn't have markAsUncloneable — jsdom needs it. Every frontend test run was crashing before a single test file even executed. The actual backend test suite (pytest) had been passing this entire time; it was just outvoted by two infrastructure bugs with nothing to do with the code being tested.

Fix: un-ignore .python-version, commit it. Bump node-version to '22'. Two-line diff, two root causes eliminated.

Act 3: The Debt That Was Always There

Pushed the fix, watched CI run again. pytest and frontend went green. linter failed again — different reason this time:

black....................................................................Failed
- hook id: black
reformatted job_board/jobs/services.py

isort....................................................................Failed
- hook id: isort
Fixing job_board/jobs/services.py

djLint formatting for Django.............................................Failed
- hook id: djlint-reformat-django
1 file was updated.

Formatting drift had been quietly accumulating in three files — a multi-line import that black wanted split, a .envs file missing a trailing newline, an index.html <meta> tag that djLint wanted wrapped. None of it mattered locally because nobody had pre-commit wired into their git hooks. It only mattered in CI, which is exactly where it had been failing, unnoticed, this whole time.

The fix here was almost mechanical: CI's own hook output is the diff. Applied it verbatim rather than re-deriving it — no ambiguity about what "correctly formatted" means when the formatter already told you.

Act 4: The Flaky Cache and the Duplicate Runs

Two more small papercuts surfaced once real CI runs were flowing:

A cache backend race. PR-triggered builds started intermittently failing with:

Error: cannot parse bake definitions: ERROR: failed to solve:
failed to load cache key: repository does not contain ref refs/pull/166/merge

This is a known docker/bake-action + GitHub Actions cache quirk: a PR's merge ref gets recomputed (or invalidated) if the PR updates or merges while the cache backend is still resolving it. It never affected the push-triggered run on main — the one that actually gates deploy — but it left a false red X on every promotion PR. Buildx's GHA cache backend has a purpose-built escape hatch for exactly this:

django.cache-from=type=gha,scope=django-cached-tests,ignore-error=true

ignore-error=true degrades a cache-restore failure to a cache miss instead of failing the whole job.

Duplicate CI runs. With both pull_request: branches: [main] and push: branches: [main] as triggers, every promotion ran the exact same commit through CI twice — once when the PR opened, again the instant it merged. Since deploy only ever cares about the post-merge state of main, the fix was to drop the pull_request trigger entirely and let push do the only job that mattered.

While in there, I also pulled the frontend lint/test job out of backend CI altogether — the frontend deploys through Vercel, which already runs its own build/lint pipeline as a separate PR check. There was no reason a frontend typo should ever gate a DigitalOcean backend deploy, so frontend/** also got added to paths-ignore — a frontend-only commit no longer triggers a backend rebuild at all.

Act 5: CI Was Finally Green. Deploy Still Failed.

For the first time, CI showed success on a push to main. And for the first time, Deploy to DigitalOcean actually ran instead of showing skipped. It failed in 12 seconds:

ssh.ParsePrivateKey: ssh: no key found
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain

gh secret list --repo <org>/<repo>

Zero rows. DO_HOST, DO_USERNAME, DO_SSH_KEY, DO_PORT — none of them existed. The workflow had been referencing four secrets that had simply never been created. CI passing had done its job; it just exposed the next layer down.

Act 6: Two SSH Gotchas

Setting these up surfaced two mistakes worth writing down because they're both easy to make and easy to misdiagnose.

Gotcha 1 — ssh-copy-id from inside the box. Trying to install a public key onto the droplet while already SSH'd into that droplet doesn't work: ssh-copy-id opens a new outbound connection back to the same host to install the key, but that connection has no valid key to authenticate with yet. Classic chicken-and-egg. Once you're already sitting in a shell on the target machine, skip ssh-copy-id and just append directly:

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Gotcha 2 — mangled secret content. Even after the public key was trusted server-side, the deploy still failed with the exact same ssh: no key found error. The private key had been set as a GitHub secret via a string interpolation (--body "...") rather than a direct file redirect, which had silently collapsed the multi-line PEM block. The fix is to never let anything touch the formatting:

gh secret set DO_SSH_KEY --repo <org>/<repo> < ~/.ssh/id_ed25519

Redirecting the raw file guarantees byte-for-byte fidelity, including the -----BEGIN/END----- lines and every internal newline that a shell string would otherwise eat.

Act 7: Right Key, Wrong Directory

With auth finally working, the deploy script actually reached the droplet and ran — into a new error:

err: bash: line 1: cd: /home/***/apps/gigglegigs: No such file or directory
err: fatal: not a git repository (or any of the parent directories): .git
err: open /home/***/production.yml: no such file or directory

deploy.yml assumed the checkout lived at ~/apps/gigglegigs. It didn't — a quick ls ~ on the droplet showed the actual clone sitting at ~/GiggleGigs. That path had apparently been copy-pasted from a different project's deploy config and never actually validated, because the workflow had never gotten far enough to hit it before. One-line fix, and the deploy script finally ran start to finish: build, collectstatic, migrate, up -d, all green.

Act 8: The First Real Deploy Broke the Site

Two minutes after that first fully green deploy, the admin's user list started returning 502 Bad Gateway. The instinct is to panic here — first automated deploy, and the site's down? But the logs told a much less dramatic story:

django-1  | PostgreSQL is available
django-1  | 186 static files copied to '/app/staticfiles', 538 post-processed.
django-1  | [2026-09-01 12:48:17 +0000] [1] [INFO] Starting gunicorn 21.2.0
django-1  | [2026-09-01 12:48:17 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000

Gunicorn didn't finish booting — Postgres wait, collectstatic, worker fork — until 12:48:17. The 502 was timestamped 12:48:16. One second earlier. Nothing crashed; I'd just refreshed the admin during the exact window where docker compose up -d had already killed the old django container and the new one wasn't listening yet.

That's not really a bug in the app — it's a gap in the deploy setup. Traefik here uses the static file provider, routing unconditionally to http://django:5000 with zero awareness of container readiness:

services:
  django:
    loadBalancer:
      servers:
        - url: http://django:5000

Every deploy, without exception, would keep hitting this same window. The right fix is an active health check so Traefik stops sending traffic to a container until it's actually answering:

services:
  django:
    loadBalancer:
      servers:
        - url: http://django:5000
      healthCheck:
        path: /healthz/
        hostname: api.example.com
        interval: '5s'
        timeout: '3s'

Two things worth calling out about that config. First, /healthz/ didn't exist — it needed to be a genuinely trivial, unauthenticated view (no DB touch, no auth, just 200 OK), because coupling infra health to a real business endpoint means a permissions change or a slow query silently takes your health check down with it. Second, hostname isn't optional: without it, Traefik's health check request sends Host: django (the internal service name), and ALLOWED_HOSTS — quite correctly — rejects that as a DisallowedHost, returning 400 and making Traefik think the container is permanently unhealthy. Setting hostname to the real public domain makes the health check's request indistinguishable from real traffic, from Django's point of view.

While already in production.yml, I added restart: unless-stopped to every long-running service (everything except the one-off backup container). Without it, a droplet reboot — a DigitalOcean maintenance window, a crash, anything — leaves every container down until someone notices and SSHes in to bring them back up manually. unless-stopped means Docker brings them back on its own the moment the daemon starts.

What Actually Was Wrong, All Together

Laid out in one place, the full list is almost funny:

A gitignored file broke Python setup in CI
A pinned Node version was two majors behind what a dependency required
Formatting drift had been silently failing lint for who knows how long
A GHA cache backend race gave false negatives on PR checks
CI ran twice per promotion for no reason
Zero deploy secrets existed
A private key got mangled by shell interpolation
The deploy script's target directory was simply wrong
Traefik had no way to know when a container wasn't ready yet
Nothing would restart itself after a reboot

No single one of these was hard to fix once found. What made this a slog was that each bug hid the next one — CI had to go green before deploy secrets could even matter; deploy secrets had to work before the wrong directory path could surface; the deploy had to actually succeed before the Traefik timing gap became visible at all. A pipeline with ten small breakages in series doesn't look like ten breakages. It looks like one big wall, and the only way through it is to fix the outermost failure, rerun, and see what the next layer reveals.

Takeaway

If your "automated" deploy still requires someone to manually pull and rebuild, don't assume the deploy job itself is broken — check whether the thing gating it has ever actually succeeded. A pipeline that's silently and permanently gated behind a red CI run looks, from a distance, exactly like a pipeline that doesn't exist. The fix isn't usually one big rewrite. It's peeling one failing layer at a time until the thing underneath finally gets a chance to run — and then trusting the next error message, however unrelated it looks, to point at the next real problem.

Side project deployed https://www.gigglegigs.com/ tomorrow is devops and SEO day!

Vicente G. Reyes — Mon, 31 Aug 2026 13:26:16 +0000

gigglegigs.com

What do you think is better, a free period or a freemium?

Vicente G. Reyes — Sun, 30 Aug 2026 05:47:21 +0000

Your App Center List Is Not a Security Audit

Vicente G. Reyes — Fri, 28 Aug 2026 05:10:02 +0000

I opened Ubuntu's App Center, scrolled through ~90 installed packages, and asked the obvious question: is any of this malware?

The list looked suspicious in all the wrong ways. A font package last updated nine years ago. A dozen unlabeled GStreamer plugins with generic gray icons. Something called BRLTTY I had no memory of installing. Plenty of surface area for paranoia.

None of it turned out to matter, and the reason is worth writing down: App Center is a package browser, not an inventory. It shows you the two sources it manages — the Ubuntu archive and the Snap Store — and nothing else. Every path an attacker would actually use to get code onto a developer workstation is invisible to it.

This is the audit I ran instead, and what each command is actually good for.

Reading the GUI correctly first

Two things I had wrong at a glance.

"Updated 9 years ago" is not neglect. That's the package version date. (URW)++ Core Font Set 20200910-8, TeXInfo, BRLTTY — these are frozen-by-design dependencies pulled in by other packages. A font metric file doesn't need a 2026 release to be safe.

Gray placeholder icons are not unsigned packages. They mean no AppStream metadata or .desktop file. Most are libraries that were never meant to appear in a launcher. A few, as I found later, are a real (and benign) finding.

Neither observation tells you anything about integrity. For that you need the actual tooling.

1. Snap publishers

snap list

for s in $(snap list | awk 'NR>1{print $1}'); do
  snap info "$s" | grep -E '^(name|publisher)'
done

The publisher column is the entire point. Snap uses two markers:

Marker	Meaning
`✓`	Verified publisher — identity confirmed by Canonical
`✪`	Starred — a trusted community maintainer

On my machine: 21 snaps, all marked. Canonical for the base and GNOME runtimes, mozilla✓ for Firefox, bitwarden✓ (8bit Solutions LLC), spotify✓. The three starred ones were Discord and ffmpeg-2404 from Snapcrafters, and Pinta from James Carroll — the legitimate upstream maintainers in both cases.

An unmarked publisher on a snap claiming to be a well-known app is the thing to look for. There weren't any.

2. Third-party APT repositories

This is the real risk vector, and it's the one App Center will never show you.

grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Seven results, all using signed-by= with a dedicated keyring — which is the modern, correct form. The deprecated apt-key approach trusts a key for every repo on the system; signed-by scopes it to one. If you see repos without it, that's worth fixing regardless of whether anything is compromised.

Six were immediately recognizable: Docker, GitHub CLI, Heroku, Cloudflare WARP, mise, and the Ulauncher PPA. The seventh was truncated in my terminal and read, in part, antigravity-repo-key.gpg ... us-central1-apt.pkg.dev/projects/antigra....

Unfamiliar name, Google Cloud infrastructure hostname. Exactly the shape of thing that deserves thirty seconds of verification rather than a shrug.

It's Google's Antigravity IDE. Google's official Linux download page publishes that repo verbatim — same keyring path, same Artifact Registry host, same project. Confirmed, but confirming the URL is only half the check.

3. Verifying the signing key

A repo URL you recognize means nothing if the key trusting it was swapped.

gpg --show-keys --fingerprint /etc/apt/keyrings/antigravity-repo-key.gpg

pub   rsa2048 2021-05-04 [SC]
      35BA A0B3 3E9E B396 F59C  A838 C0BA 5CE6 DC63 15A3
uid   Artifact Registry Repository Signer <artifact-registry-repository-signer@google.com>

Full-length match against the published fingerprint, and a single pub key with no extra subkeys smuggled into the file. Compare all 40 characters — matching the last eight is a known-weak check that collision attacks have historically defeated.

One nuance that matters. This is Google's shared Artifact Registry signing key. It signs every public AR apt repo, not just Antigravity's. So the fingerprint proves "Google Artifact Registry published this" — it does not prove "the Antigravity team published this." The trust boundary is the repository path. Verify both halves or you've verified neither.

4. Binary integrity

This is the command that actually answers the malware question.

sudo apt install debsums
sudo debsums -s

debsums recomputes the checksum of every file installed from a .deb and compares it against what the package shipped. -s prints only problems. If something had patched a system binary, this is where it surfaces.

My output — three lines, all of the same kind:

debsums: missing file /usr/share/applications/btop.desktop (from btop package)
debsums: missing file /usr/share/applications/org.flameshot.Flameshot.desktop
debsums: missing file /usr/share/applications/org.gnome.SystemMonitor.desktop

Missing is not modified, and the distinction is the whole finding. Zero checksum mismatches means not one binary or library on the system differs from what Ubuntu published. What's missing is three launcher entries — which is also why those three showed gray placeholder icons back in the GUI. Almost certainly an app-grid cleanup I did and forgot. Malware adds .desktop files for persistence; it has no reason to delete them from unrelated packages.

sudo apt install --reinstall btop flameshot gnome-system-monitor

One caveat: not every package ships checksums, so debsums coverage is good but not total. Add sudo debsums -ca to list modified config files, which is a separate and noisier category.

5. Running services and persistence

systemctl list-units --type=service --state=running
ls -la ~/.config/autostart/ /etc/systemd/system/

Thirty-four running services, every one accounted for: Docker and containerd, warp-svc matching the Cloudflare repo, ClamAV daemon and freshclam, and the usual GNOME and systemd stack. Autostart held two entries, both mine.

The /etc/systemd/system/ listing had a detail I liked seeing:

avahi-daemon.service -> /dev/null
cups.service -> /dev/null
libvirtd.service -> /dev/null

Symlinking a unit to /dev/null is masking — a stronger form of disable that can't be overridden by another unit's dependencies. Past-me hardening the box and leaving a legible trace of it.

What this audit does not cover

Every check above is scoped to the package layer. That layer came back clean, and it's also not where compromise on a developer machine tends to originate.

The paths that stay invisible to all of it:

Language package managers — npm -g, pip, cargo install, go install. Typosquats and compromised maintainer accounts are a live and recurring problem here, and postinstall scripts run with your privileges.
curl | bash installers — no signature, no manifest, no uninstall path, nothing for debsums to compare against.
Editor and IDE extensions — VS Code marketplace extensions run with full user permissions and are minimally reviewed.
Agentic coding tools — anything with filesystem write access and an autonomous execution loop. This is the newest item on the list and the one with the least established review culture around it. That is the sensible next audit. The system package layer is the part with actual cryptographic guarantees behind it — signed repos, verified publishers, reproducible checksums. Everything above it is running on trust.

The runbook

# Snap publishers — every entry should be ✓ or ✪
snap list
for s in $(snap list | awk 'NR>1{print $1}'); do
  snap info "$s" | grep -E '^(name|publisher)'
done

# Third-party APT repos — all should use signed-by=
grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

# Verify any unfamiliar repo key against its published fingerprint (all 40 chars)
gpg --show-keys --fingerprint /etc/apt/keyrings/<name>.gpg

# Binary integrity — the check that matters
sudo apt install debsums && sudo debsums -s

# Persistence and running services
systemctl list-units --type=service --state=running
ls -la ~/.config/autostart/ /etc/systemd/system/

Five minutes end to end. Worth running on any machine you build client work on, if only to replace a vague sense of unease with an actual answer.

Why I Couldn't Access My Own Site (But My Phone Could): A Cloudways Auto-Ban Story

Vicente G. Reyes — Mon, 24 Aug 2026 13:12:24 +0000

I sat down to work on Rev6 and couldn't load the site. Not a slow load, not an SSL warning — nothing. The browser just spun until it gave up. My first assumption was the usual suspect: the server was down.

Then I checked my phone, on the same Wi-Fi. Rev6 loaded instantly.

That one detail sent me down a much longer rabbit hole than I expected — and the actual cause had nothing to do with my laptop, my router, or even my ISP.

The Setup

Rev6 is hosted on Cloudways, which provisions on top of DigitalOcean. DNS resolved fine — the domain pointed to the correct droplet IP. So this wasn't a broken domain or expired DNS record. The problem was specifically about reaching that IP.

The Failed Attempts

I went through the usual network debugging checklist, and every single one came back clean:

Ping and curl to the server — both hung and eventually timed out on ports 80, 443, and even 22 (SSH). Not "connection refused," just total silence, as if the packets vanished.
General internet sanity check — Google, GitHub, Cloudflare all loaded instantly. So this wasn't a broken connection, just this one destination.
Local firewall (ufw/iptables/nftables) — checked the full ruleset, OUTPUT policy was ACCEPT, no rule matched the server's IP or any DigitalOcean range.
VPN or proxy — none active, no http_proxy/https_proxy env vars, no tunnel interfaces.
MAC-based router filtering — randomized my Wi-Fi adapter's MAC address entirely. Still blocked.
Hostname-based filtering — some routers key parental-control rules off the DHCP hostname instead of the MAC. Disabled hostname broadcasting, renewed the lease. Still blocked.
The router itself — logged into the ONT admin panel and checked every filtering section: IP Filter, MAC Filter, WLAN MAC Filter, Parental Control, Device Access Control. All disabled, all empty.

At this point every layer between my laptop and my ISP was confirmed clean. Whatever was blocking the connection wasn't local.

The Clue That Cracked It

The "works on my phone" comparison turned out to be misleading. When I checked my phone's actual public IP (via whatismyip.com), it came back as a completely different address in a different range than my laptop's real ISP-assigned IP — a sign that Brave's VPN feature was tunneling all my phone's traffic elsewhere. My phone was never a fair comparison; it simply wasn't taking the same path to the internet.

The real breakthrough came from testing the connection from a network entirely outside my ISP. From there, the request to the server didn't time out — it came back as an active refusal. That's a meaningfully different signal:

From my home connection: total silence — no response at all
From an outside network: an explicit "connection refused"

Silence usually means something in the path is dropping packets. An active refusal means the packets arrived, and something on the other end responded. That distinction pointed the investigation away from my network entirely and toward the server side.

The Real Issue: Cloudways Had Auto-Banned My IP

Cloudways includes a Bot Protection feature — AI-driven heuristics and CAPTCHA challenges meant to keep malicious bots off the server. It's a genuinely useful feature. It's also fully automated, which means it can ban a legitimate visitor without any human ever reviewing the decision.

Under Server → Security → Firewall, there's a blacklist table showing banned IPs, the country they're associated with, and the reason. Searching my own IP directly returned nothing — but filtering by country (Philippines) surfaced it immediately:

IP	Purpose	TTL	Country	Event
(my IP)	black	1 week from now	Philippines	Blacklisted for CAPTCHA failure

My own home IP had been silently banned for a full week after failing a CAPTCHA challenge — almost certainly an automated bot check I never even saw, triggered while browsing my own site.

The Fix

From the same Firewall screen:

Search for the banned IP (or filter by country if the exact IP search comes up empty)
Open the ⋮ actions menu on that row
Remove/delete the blacklist entry

Access was restored immediately — no server restart, no DNS changes, nothing else required.

Takeaway

When a site is unreachable but DNS resolves and the rest of the internet works fine, don't assume it's your network just because another device on the same Wi-Fi can get through — verify that device is actually taking the same path out to the internet first. A background VPN can make an "it works on my phone" comparison completely meaningless.

And when the destination is a managed host like Cloudways, remember that automated bot/security protections can ban you just as easily as an actual attacker. If everything on your end checks out clean, check the host's own security dashboard before assuming there's a deeper network problem — the block might already be sitting there in plain sight, just filed under "security."