DEV Community: Vicente G. Reyes

My first freelance client paid me $5. Here's what I'd tell myself at that stage.

Vicente G. Reyes — Thu, 29 Oct 2026 14:15:54 +0000

My first paid freelance job was a $5 mixing gig on Fiverr.

I'd been recording myself and my band for practice. At some point I figured someone might pay for that, so I listed a gig, landed one, and delivered in 5 days. After that I ghost-produced a hardstyle track for a client in Europe.

Then the audio work dried up. I could mix, but buyers were scarce.

So I stepped sideways. I paired what I'd studied in college (computer science) with a platform businesses were actually paying for: Shopify. I started doing Shopify development in 2019, landed an agency gig in 2020 building stores from the ground up, and since 2018 I've shipped 37 client projects, including 11 production Shopify stores.

Looking back, the skill was never the hard part. Everything around the skill was. Here are the five things I'd tell myself at the $5 stage.

1. You probably already have something sellable

Most people waiting to "learn enough" to freelance are already sitting on a skill: editing videos for their friends, designing posters for their org, fixing the family computer, mixing their band's demos.

The question isn't "am I good enough?" It's "who already pays for this, and what do they pay for?" List what you do for free, then look for where businesses pay for the same outcome.

2. Sell an outcome, not a skill

"I do video editing" is a skill. "I turn your raw Zoom recordings into three 60-second clips for Reels, delivered in 48 hours" is an offer.

A client can say yes to an offer. A skill makes them do the work of figuring out what they're buying.

3. Say what you can't do yet

This one felt backwards to me at first. When you're new, the instinct is to say yes to everything.

What actually builds trust is being specific about your gaps, then pointing to adjacent evidence: "I haven't built a subscription store yet, but here's a store I built with a custom checkout flow." Clients have been burned by people who overpromised. Honesty stands out.

4. Scope before you start, every time

Most freelancer horror stories come down to one thing: nobody wrote down what "done" means.

Before any work starts, write a short Scope of Work:

what's included
what's not included
how many revisions
the timeline
what happens if the client wants more It doesn't need to be a 10-page contract. One page beats a handshake every time.

5. Don't price like a hobbyist forever

$5 was fine for a first gig. It got me a review and proof that someone would pay. But plenty of freelancers get stuck at their first price because raising it feels scary.

Treat your first rate as temporary. Every few projects, raise it for new clients. The ones who leave over a small increase usually weren't the ones keeping you afloat anyway.

The playbook

I turned all of this into a full guide: From Hobby to Hired: The First-Client Playbook.

It's an 18-page PDF with 8 chapters covering the skill audit, packaging a service, building proof, finding clients, pricing, scoping, getting paid (written PH-first, but useful anywhere), and growing to steady income.

It also includes:

6 copy-paste AI prompts, including one that interviews you and drafts a Scope of Work from your answers
A fill-in Scope of Work template
A Skill Audit worksheet It's for beginners who want their first paying client, not for freelancers who are already booked out.

👉 Get it on Gumroad · More about the playbook

What was your first paid gig, and what did you charge? Drop it in the comments. I'd love to hear where everyone started.

From Side Projects to Your First Paying Client: A Practical Guide for Developers

Vicente G. Reyes — Tue, 27 Oct 2026 10:00:15 +0000

Most developers stuck before their first client don't have a skills problem.

You've built the side projects. You know your framework. You could probably ship what a small business needs in a few weeks. What's missing is everything around the code: knowing what to offer, where clients come from, what to charge, and how to keep a project from swallowing your evenings.

My first client was a mixing engineering client on Fiverr for $5 which lasted for 5 days. Small budget but it is what it made me work from home/freelance.

Here's the path broken into six steps.

1. Pick one offer a stranger understands in ten seconds

"I'm a full-stack developer" describes you. It doesn't tell anyone what they can buy.

Clients buy outcomes, so turn your skills into one specific offer:

❌ "I do React, Django, Tailwind and some DevOps"
✅ "I build fast booking websites for small clinics"
✅ "I turn your spreadsheet workflow into a simple web app"

Narrow feels risky, but it's what makes you easy to recommend. You can widen the offer once people are paying you.

Try this: finish the sentence "I help [who] get [result] by [what you build]." If a non-developer friend can't repeat it back, simplify it.

2. Make your portfolio sell, not just exist

A portfolio of tutorial clones says "I can follow along". A portfolio aimed at clients says "I can solve your problem".

Show fewer, better projects. Three relevant projects beat twelve unrelated ones.
Hide what doesn't match your offer. The to-do app and the weather app can go.
Write each project up as a short case study: the problem, what you built, and the result. Even a side project can say "built to solve X, handles Y".
Put a clear next step on every page: "Need something like this? Let's talk."

3. Find your first lead (it probably isn't a job board)

Job boards and freelance marketplaces are crowded and push prices down. First clients more often come from people who already know or trust you:

Your existing network: former coworkers, classmates, family businesses, local shops you already buy from.
Communities you're already in: Discord servers, local dev groups, industry forums for the niche you picked in step 1.
Showing your work in public: posting what you build, like this article, puts you in front of people before you ever pitch them.

When you reach out, keep it short and specific:

Hi [name], I noticed [specific thing, e.g. your booking form is a Google Form]. I build [your offer] and could [specific improvement] in about [timeframe]. Want me to send a quick example of how that would look?

Specific beats clever. Point at a real problem you noticed.

4. Price without panic

Your first price will feel wrong whatever you pick. Some guardrails:

Price the project, not your hours. A fixed price for a defined scope is easier for the client to say yes to, and it rewards you for working efficiently.
Work out your floor. Estimate the hours, multiply by the lowest hourly rate you'd accept, and add a buffer for revisions and communication.
Don't compete on cheap. The lowest price attracts the clients who are hardest to work with.
Raise it on the second client. The first project is partly paying for your learning. Don't lock that price in forever.

5. Write a one-page proposal and protect yourself

You don't need a 20-page document. One page with these sections is enough:

The problem, in the client's own words
What you'll deliver, as a specific list
What's not included, which is just as important
Timeline and milestones
Price and payment terms, for example 50% upfront and 50% on delivery

Then make sure your agreement covers the clauses that prevent most scope creep:

How many revision rounds are included
How new requests are handled ("quoted separately as a change request")
When ownership of the code transfers (usually on final payment)

6. Deliver so one client turns into three

The first project isn't just income. It's your first testimonial and your first referral source.

Communicate more than feels necessary: short weekly updates, even when nothing is blocked.
Hand over properly: a short guide, credentials, and a walkthrough call.
Ask for a testimonial and a referral while they're happy, right after launch: "Do you know anyone else who'd find this useful?"

A happy first client who introduces you to two people is worth more than any marketplace profile.

Want the full playbook?

I turned all of this into From Hobby to Hired: The First-Client Playbook, a practical PDF with more detail on each step, the outreach scripts, and the proposal structure.

It's ₱499 / $12 during launch (regular ₱799 / $19), with an instant download after payment.

👉 Get the playbook

If you've already landed your first client, I'd love to hear how it happened in the comments. And if you're still working toward it, which step feels hardest right now?

Zero-Downtime Django Deploys on One Small Droplet

Vicente G. Reyes — Tue, 27 Oct 2026 02:36:39 +0000

GiggleGigs is a job board I run: Django + DRF on the backend, React + Vite on the front (on Vercel), Celery for background work, all in Docker Compose on a single 2 GB DigitalOcean droplet, with Traefik in front and Cloudflare in front of that.

In the last post I moved image builds off the droplet and into GitHub Actions. That stopped deploys from freezing the server. It didn't stop them from taking the site down.

Why 99.99% means deploys can't cause any downtime

99.99% uptime allows about 4.3 minutes of downtime a month.

I measured a normal deploy with a loop that requested the API every 5 seconds: about two minutes of no available server from Traefik. I deploy several times a day. At that rate, a single morning of deploys would use up the month's budget.

So "faster deploys" wasn't the goal. The goal was deploys with no downtime at all, which left the 4.3 minutes for things I can't control.

Measure first

Everything below is based on one simple measurement: a loop on my laptop that requested the API's health endpoint every 5 seconds while a deploy ran, plus a request to a site that's always up (google.com) on each tick as a control:

while true; do
  echo "$(date -u +%T) $(curl -s -o /dev/null -m 5 -w '%{http_code}' https://api.example.com/healthz/) $(curl -s -o /dev/null -m 5 -w '%{http_code}' https://www.google.com/)"
  sleep 5
done >> uptime.log

The control column matters. My own connection dropped twice during the day, and without the control those drops would have looked like site outages.

Why a deploy went down

The old deploy ran docker compose up -d, which:

stops the only Django container,
starts a new one,
whose start script runs collectstatic before gunicorn starts listening.

Traefik had nothing to send requests to until step 3 finished. That's two minutes.

Step 1: Collect static files when the image is built

collectstatic doesn't need a database or real secrets. It only needs the settings module to import. So it now runs in the Dockerfile, which runs in CI, with placeholder env vars that exist only for that RUN step:

# Collect static files at build time so a new container starts
# serving in seconds. Production settings need these env vars to import,
# but collectstatic never uses them, so placeholders are enough.
RUN DJANGO_SETTINGS_MODULE="config.settings.production" \
  DJANGO_SECRET_KEY="build-only" \
  DATABASE_URL="postgres://build:build@localhost:5432/build" \
  # ...the rest of the required settings...
  python manage.py collectstatic --noinput

The start script went from about 25 lines to one:

exec /usr/local/bin/gunicorn config.wsgi --bind 0.0.0.0:5000 --chdir=/app \
  --timeout 90 --graceful-timeout 90 --no-control-socket

A new container now passes its healthcheck in 13–20 seconds on my laptop and about 43 seconds on the droplet, instead of about two minutes.

One surprise: I also tried running django-compressor's compress at build time, and it failed with No 'compress' template tags found. None of my templates use it. It must have been switched off in production, or the old start script would have crashed. Moving work into the build is a good way to find steps that never did anything.

Step 2: A healthcheck, and a second container

Then a rolling deploy: start a second Django container on the new image, wait until it's healthy, and only then stop the old one. The new container gets a Docker healthcheck on the existing /healthz/ endpoint:

django:
  image: ghcr.io/you/app-django:${IMAGE_TAG:-latest}
  command: /start
  healthcheck:
    test:
      - CMD
      - python
      - -c
      - "import urllib.request; urllib.request.urlopen(urllib.request.Request('http://localhost:5000/healthz/', headers={'Host': 'api.example.com'}), timeout=3)"
    interval: 5s
    timeout: 5s
    retries: 3
    start_period: 60s
  stop_grace_period: 90s

The image has no curl, so the check uses Python. The Host header has to be one of ALLOWED_HOSTS, and /healthz/ has to be in SECURE_REDIRECT_EXEMPT, or the check gets a 301 and fails.

The deploy script uses Compose's --scale and --no-recreate flags, which most people never touch:

old_container=$(docker compose ps --quiet django)
docker compose run --rm django python manage.py migrate
docker compose up --detach --no-deps --no-recreate --scale django=2 django
new_container=$(docker compose ps --quiet django | grep --invert-match "${old_container}")
# ...poll `docker inspect --format '{{.State.Health.Status}}'` until healthy...
docker stop --timeout 90 "${old_container}"
docker rm "${old_container}"
docker compose up --detach --no-deps --no-recreate --scale django=1 django

If the new container never becomes healthy, the script removes it and exits non-zero. The old container keeps serving, and the deploy shows as failed in GitHub Actions.

I rehearsed it locally: the production image behind Traefik, 4 parallel request loops, two deploys in a row. 5,624 requests, all 200. A deliberately broken image was rejected while the old container kept serving. I shipped it.

The first live deploy still dropped requests

Production disagreed:

Time (UTC)	API	Control
08:16:33 → 08:17:12	`503` ×3, `000` ×1	200
08:17:30 → 08:17:46	`521` ×4	200

The 521s were expected. That's Cloudflare reporting that Traefik was restarting for its own config change, once. The 503s were not expected. They happened while the new Django container was starting, which was exactly the part the rolling deploy was supposed to handle.

Reproducing it locally

The local rehearsal had passed because my laptop is fast, and a new container there is ready almost as soon as it starts. The droplet is slow. Compose can limit a container's CPU, so I ran the rehearsal again with Django capped to 0.3 CPU:

django:
  cpus: "0.3"

That reproduced it right away:

Time	Result
16:37:25–36	4 requests hung for 10 seconds and timed out
16:37:47	35 instant `503`s

Two bugs, one cause

My Traefik config routed to Django through a single URL:

services:
  django:
    loadBalancer:
      servers:
        - url: http://django:5000
      healthCheck:
        path: /healthz/
        interval: '5s'
        timeout: '3s'

django is a Docker DNS name. With two containers running, it resolves to both, including the one that's still booting. Gunicorn accepts connections before its worker is ready, so:

Requests that reached the new container waited in its queue and hung.
Traefik's health probe also reached the new container sometimes, timed out, and marked the whole django server down, old container included. That's no available server, the 503s.

The Docker healthcheck I'd added only told the deploy script when the new container was ready. Traefik never saw it.

Step 3: Route only to healthy containers

Traefik's Docker provider solves this directly: it skips containers whose Docker healthcheck is still starting or unhealthy. So Django is now discovered through labels instead of a hardcoded URL:

django:
  labels:
    - traefik.enable=true
    - traefik.http.services.django.loadbalancer.server.port=5000

traefik:
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock:ro

# traefik.yml
http:
  routers:
    web-secure-router:
      rule: 'Host(`api.example.com`)'
      service: django@docker   # from the labels above
providers:
  file:
    filename: /etc/traefik/traefik.yml
  docker:
    exposedByDefault: false

The router, TLS and middlewares stay in the file provider. Only the service moved.

A word on that socket mount: :ro makes the socket file read-only, but it doesn't limit the Docker API, so Traefik can still do anything Docker can. If Traefik were ever compromised, so is the host. On a single box I own, I accepted that. A Docker socket proxy that only allows container listings is the stricter option.

With the Docker provider, the 503s and the startup hangs were gone. In the slow-CPU rehearsal, 6 failures were left, all at the moment the old container stopped.

Step 4: Drain before you stop

docker stop sends SIGTERM, and gunicorn stops accepting connections. But Traefik still sees the old container as healthy until it exits, so for a few seconds it keeps sending requests to a server that's refusing them.

The fix is to take the container out of rotation before sending SIGTERM. Traefik already follows the healthcheck, so the healthcheck becomes the off switch:

healthcheck:
  test:
    - CMD
    - python
    - -c
    - "import os, sys, urllib.request; os.path.exists('/tmp/draining') and sys.exit(1); urllib.request.urlopen(...)"

And in the deploy script:

sleep 5                                         # let Traefik pick up the new container
docker exec "${old_container}" touch /tmp/draining
# ...poll until Docker reports it unhealthy...
sleep 5                                         # let Traefik drop it
docker stop --timeout 90 "${old_container}"     # gunicorn finishes in-flight requests

By the time gunicorn gets SIGTERM, nothing new is being sent to it, and the 90-second grace period lets requests already in flight finish. My gunicorn --timeout is 90 seconds because some requests wait on an LLM.

The rehearsal, with the CPU capped

Setup	Requests	Failed
DNS routing + Traefik health probe	1,639	39 (35 × 503, 4 × 10 s hangs)
Docker provider	2,847	6 (all when the old container stopped)
Docker provider + drain, 5 rollouts in a row	12,957	0

A gunicorn 26 surprise

While reading container logs I found this on every start:

[ERROR] Control server error: [Errno 13] Permission denied: '/nonexistent'

Gunicorn 26 added a control socket, which defaults to a path under $HOME. cookiecutter-django's django system user doesn't have a home directory. Nothing broke, but --no-control-socket turns it off.

The transitional deploy

The first deploy of this change was still messy. It had to be: the Traefik that was running was the old one, with DNS routing, and the old Django container had no drain logic.

Time (UTC)	What happened
09:44:57–09:45:10	503s during startup (old Traefik, old routing)
09:45:45 → 09:47:23	Drain step waited out its limit; the old container's healthcheck had no drain check
09:47:26–09:47:38	521/525 while Traefik restarted on its new config

If you change how traffic is routed, the deploy that ships the change runs on the old routing. Plan for one bad deploy, and don't measure that one.

Result

The next deploy was the first to run entirely on the final setup. It was an ordinary backend change: a query fix for the Browse Jobs page.

Time (UTC)	Step
09:55:41	Deploy job starts on the droplet (pull, small image builds, migrate)
09:56:36	New Django container starts next to the old one
09:57:24	New container healthy; old one starts draining
~09:58:14	Old container stopped; Celery and Flower restart
09:58:34	Deploy job done

And the uptime loop:

Window	API probes	Failed	Control
Deploy job, 09:55:41 → 09:58:34	44	0	all 200
Before, during and after, 09:54 → 10:00	64	0	all 200

Zero failed probes, and no Traefik restart, because nothing in its config changed.

For comparison, the morning's deploy on the original setup had about two minutes of no available server, and the transitional deploy had 8 failed probes across three bursts.

To be clear about what that measures: one probe every 5 seconds can't see a blip shorter than 5 seconds. The rehearsal fills that gap. There, two request loops ran continuously against Django capped to 0.3 CPU, and 12,957 requests across five rollouts had zero failures. Together, the two give me confidence the rollout itself no longer drops requests.

The deploy job went from 1m 47s to 2m 53s. The extra minute is mostly waiting for the new container to become healthy and for the old one to drain. That's an easy trade for no downtime.

What 99.99% still needs

Zero-downtime deploys take the biggest planned cause of downtime out of the budget. Several things are still left:

An independent monitor. My curl loop was fine for watching a deploy, but to claim 99.99%, you need something that checks every minute, all month, from outside your own network.
Backward-compatible migrations. The old container keeps serving while the new migrations run. Adding a column is fine. Renaming or dropping one needs two deploys: first ship code that stops using it, then remove it.
One host is still one host. A hypervisor reboot, a kernel update or running out of memory will take the site down, and rolling deploys can't help with that. On a single droplet you can avoid causing downtime yourself, but you can't guarantee against it.

Takeaways

Measure with a control. Otherwise your own Wi-Fi shows up as site downtime.
Rehearse on hardware as slow as production. A container that starts quickly will hide every timing bug. cpus: "0.3" found mine in one run.
Routing to a DNS name isn't the same as routing to healthy containers. Docker DNS includes containers that are still starting.
A Docker healthcheck only helps if your proxy reads it. Traefik's Docker provider does; a hardcoded URL doesn't.
Drain before SIGTERM. Take the old container out of rotation first, then stop it.
The deploy that changes routing runs on the old routing. Expect one rough deploy.
Move work to build time. It makes containers start faster and shows you which steps never did anything.

GiggleGigs is a job board for gig and contract work: gigglegigs.com.

Stop Building Docker Images on Your 2 GB Droplet

Vicente G. Reyes — Mon, 26 Oct 2026 10:03:52 +0000

GiggleGigs is a job board I run: Django + DRF on the backend, React + Vite on the front, Celery for background work, all in Docker, on a single 2 GB DigitalOcean droplet.

Deploys were the cookiecutter-django default: GitHub Actions SSHes into the droplet, runs git pull, then docker compose build, then restarts everything. It's simple, and it worked fine right up to the first time it didn't.

The problem: the droplet was also the build server

Most deploys only change application code, so Docker reuses the cached pip layer and the build finishes quickly. But any change to requirements/*.txt invalidates that layer, and the droplet then has to rebuild every wheel from scratch.

On 2 GB of RAM, that's dangerous. One build compiled psycopg-c from source, ran the box out of memory, and froze it so completely that SSH stopped responding. I had to power-cycle it from the DigitalOcean dashboard.

My quick fixes:

Added 2 GB of swap.
Switched to psycopg[binary] so nothing compiled from source.
Raised the SSH action's command_timeout to 30 minutes, because full rebuilds could outlast the default 10.

That helped, but it treated the symptom. Then I moved the project from Python 3.11 to 3.14 and updated 16 dependencies in one go. That changed the base image and every pin, so the droplet had to download a new Python image and reinstall the whole dependency tree while also serving production traffic. I forgot to stop the containers first, so all I could do was watch and hope.

It survived. But "it survived" isn't a deploy strategy. A server's job is to run the app, and building images is a separate job that belongs on a separate machine.

The goal

Build the Django image on GitHub's runners, which have plenty of RAM and cost nothing for this.
Push it to GitHub Container Registry (GHCR).
Have the droplet pull the image and restart. No compiling there.
Make rollbacks one command.
Keep changes to the compose file small. It's the file I least want to get wrong.

Step 1: One image instead of four

Like most cookiecutter-django projects, my production.yml had four services built from the same Dockerfile, each with its own image name:

django:
  build:
    context: .
    dockerfile: ./compose/production/django/Dockerfile
  image: job_board_production_django
  command: /start

celeryworker:
  build:
    context: .
    dockerfile: ./compose/production/django/Dockerfile
  image: job_board_production_celeryworker
  command: /start-celeryworker

# ...same again for celerybeat and flower

They're the same image. Only the command is different. So now all four point at a single registry image:

django:
  # Built and pushed by the Deploy workflow; the droplet only pulls it.
  # Roll back with: IMAGE_TAG=<commit sha> docker compose -f production.yml up -d
  image: ghcr.io/reyesvicente/gigglegigs-django:${IMAGE_TAG:-latest}
  build:
    context: .
    dockerfile: ./compose/production/django/Dockerfile
  command: /start

celeryworker:
  image: ghcr.io/reyesvicente/gigglegigs-django:${IMAGE_TAG:-latest}
  command: /start-celeryworker

I kept build: on django only. If GHCR is ever down, I can still run docker compose build django on the droplet as a last resort. The other three just reuse the image.

${IMAGE_TAG:-latest} is the rollback hook. Normally it resolves to latest, and setting it to an older commit SHA pins every service to that build.

Step 2: Build and push in GitHub Actions

The deploy workflow already ran after CI passed on main. It's now two jobs: build runs on a GitHub runner, and deploy SSHes into the droplet.

name: Deploy to DigitalOcean

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

concurrency:
  group: deploy-production
  cancel-in-progress: false

env:
  IMAGE: ghcr.io/reyesvicente/gigglegigs-django

jobs:
  build:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout the commit CI tested
        uses: actions/checkout@v7
        with:
          ref: ${{ github.event.workflow_run.head_sha }}

      - uses: docker/setup-buildx-action@v4

      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push the Django image
        uses: docker/build-push-action@v7
        with:
          context: .
          file: ./compose/production/django/Dockerfile
          push: true
          tags: |
            ${{ env.IMAGE }}:latest
            ${{ env.IMAGE }}:${{ github.event.workflow_run.head_sha }}
          labels: org.opencontainers.image.source=https://github.com/${{ github.repository }}
          cache-from: type=gha,scope=django-production
          cache-to: type=gha,scope=django-production,mode=max

Some of these lines matter more than they look.

Gotcha #1: `workflow_run` doesn't check out what CI tested

A workflow triggered by workflow_run runs in the context of the default branch. A plain actions/checkout gives you the current tip of main, which isn't necessarily the commit CI just approved. If two merges land close together, you could build and ship code CI never saw.

ref: ${{ github.event.workflow_run.head_sha }} pins the build to the exact commit that passed. I use the same SHA as the second image tag, so every image traces back to a tested commit.

Gotcha #2: Private repo, private package

GiggleGigs is a private repo, so the GHCR package is private too. The org.opencontainers.image.source label links the package to the repo, so the repo's workflows get access to it.

If the first pull fails with denied, open the package's settings on GitHub, go to Manage Actions access, and give the repo Read access. You only do that once.

The cache

cache-from and cache-to with type=gha store BuildKit layers in the GitHub Actions cache. A push that only changes app code reuses the pip layer, the same way the droplet's local cache used to. The difference is that a requirements change now gets rebuilt on a machine that can handle it.

Step 3: The droplet only pulls

  deploy:
    runs-on: ubuntu-latest
    needs: build
    permissions:
      contents: read
      packages: read

    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.2.5
        env:
          GHCR_USER: ${{ github.actor }}
          # Short-lived: GITHUB_TOKEN expires when this job ends.
          GHCR_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          host: ${{ secrets.DO_HOST }}
          username: ${{ secrets.DO_USERNAME }}
          key: ${{ secrets.DO_SSH_KEY }}
          envs: GHCR_USER,GHCR_TOKEN
          command_timeout: 15m
          script: |
            set -e
            cd ~/GiggleGigs
            git pull origin main
            echo "$GHCR_TOKEN" | docker login ghcr.io -u "$GHCR_USER" --password-stdin
            docker compose -f production.yml pull django celeryworker celerybeat flower
            docker logout ghcr.io
            docker compose -f production.yml build postgres traefik awscli
            docker compose -f production.yml run --rm django python manage.py migrate
            docker compose -f production.yml up -d
            docker image prune -f

No long-lived registry token on the server

The droplet logs in to GHCR with the workflow's own GITHUB_TOKEN, which appleboy/ssh-action passes through via envs. That token expires when the job ends. The script also runs docker logout straight after the pull, so no credential is left in ~/.docker/config.json.

I didn't need to create a personal access token or store a new secret.

Why `git pull` still runs

The image contains the code, but the droplet still needs the current production.yml and the Traefik config, and those come from the repo.

Gotcha #3: Don't push your Postgres image

My first idea was to push every image, including postgres, traefik and awscli. These are cookiecutter's small wrapper images: FROM postgres:17 plus a few maintenance scripts copied in.

The problem is that a rebuilt image can get a new digest even when nothing in it changed. When docker compose up -d sees a different image, it recreates the container. That would restart the database on every deploy, for nothing.

So those three still build on the droplet. They don't install anything, they're cached, and they finish in seconds without using much memory. When their Dockerfiles haven't changed, Docker reuses the same image and the containers keep running.

Gotcha #4: Overlapping deploys

Earlier, two merges landed close together and two deploys ran up -d at the same time. Compose left containers with hash-prefixed names like 3f2a…_gigglegigs-django-1, and the next deploy failed with "container name already in use".

The concurrency group at the top of the workflow queues deploys instead:

concurrency:
  group: deploy-production
  cancel-in-progress: false

cancel-in-progress: false matters. Cancelling a deploy halfway through a migration is worse than waiting for it to finish.

A step I deleted

The old script had this:

docker compose -f production.yml run --rm django python manage.py collectstatic --noinput

It runs in a throwaway container. staticfiles/ isn't a volume, so the collected files disappear when that container exits. Meanwhile the container's /start script runs collectstatic again anyway, before gunicorn starts. The step cost time on every deploy and did nothing.

Cleaning up

docker image prune -f removes the dangling images each deploy leaves behind. On a small droplet, old image layers fill the disk quietly until a deploy fails for lack of space.

After the first deploy with the new setup, the old locally built images aren't tagged as dangling, so remove them by hand once:

docker rmi job_board_production_django job_board_production_celeryworker job_board_production_celerybeat job_board_production_flower

Rollbacks

Every image is tagged with its commit SHA, so rolling back is one command on the droplet:

cd ~/GiggleGigs && IMAGE_TAG=<commit sha> docker compose -f production.yml up -d

Before, rolling back meant checking out an old commit on the server and rebuilding. That's the same memory-hungry build I'm trying to avoid, at the worst possible time.

Checking it before merging

Before this reached main:

docker compose -f production.yml config --images showed the four app services resolving to the GHCR image, and IMAGE_TAG=abc123 switched all four to :abc123. Postgres, Traefik, Redis and awscli were unchanged.
actionlint passed on both workflow files.
The production image had already been built and checked locally with production settings during the Python 3.14 upgrade, so the Dockerfile itself was known to work.

The first deploy

I merged to main and timed it. A loop on my laptop also hit the API every 5 seconds, so I could see exactly when the site went down and when it came back.

Step	Where	Time
Build the image and push it to GHCR	GitHub runner	2m 49s
Pull, migrate, `up -d`, prune	Droplet	1m 47s

The GHCR pull worked the first time. The source label linked the package to the repo, so I didn't need to change any access settings.
Postgres, Traefik and Redis kept running. Their small images rebuilt from cache to the same image, so Compose left those containers alone. Only the four app containers were recreated.
The droplet never built a wheel. Its whole job came down to pulling the image and restarting containers. On a requirements change, the expensive part now runs on GitHub's runner instead of next to production traffic.
docker image prune -f reclaimed 0 B. That's expected on the first run, since the old images are still tagged under their old names. That's why the manual docker rmi above is needed once.

What this doesn't fix

This removes the risk of the droplet freezing during a build. It doesn't remove the downtime during the restart.

My uptime loop got its last good response at 07:34:28 UTC. The API answered again at 07:36:24, so the site was down for about two minutes.

When Compose replaces the Django container, Traefik has nothing to route to until the new one is ready. My /start script runs collectstatic and django-compressor's compress before gunicorn starts listening, and during that time Traefik answers with a plain no available server. Moving the build to CI doesn't touch any of that, because it all happens after the new container starts.

Now that the image is built in CI, the fix is straightforward: run collectstatic and compress at build time, so the image ships with its static files ready and /start only has to start gunicorn. After that comes a real zero-downtime switch with a healthcheck, starting the new container before stopping the old one. That's for another post.

Takeaways

Your production server shouldn't also be your build server. On a small box, one requirements change can turn a deploy into an outage.
Pin workflow_run builds to head_sha. Otherwise you can ship a commit CI never tested.
One Dockerfile should mean one image. Point every service that shares it at the same tag.
Tag by commit SHA. Rollbacks become a single up -d with no rebuild.
Use the workflow's own token to log in on the server, and log out after pulling.
Don't push images whose digest will change for no reason. Recreating Postgres on every deploy is a bad trade.
Remove steps that don't do anything. A throwaway-container collectstatic only looks useful.

GiggleGigs is a job board for gig and contract work: gigglegigs.com.

Moving a Django App from Mailgun to Amazon SES

Vicente G. Reyes — Mon, 26 Oct 2026 02:55:14 +0000

GiggleGigs is a job board I run: Django + DRF on the backend, React + Vite on the front, Celery for background work, all in Docker. It sends the usual transactional email: verification, password resets, application updates, messages, and a daily job alert digest for seekers.

All of that went through Mailgun's free tier, which caps you at 100 emails a day. That was fine until it wasn't. As the seeker count grew, the daily digest alone could eat the whole quota, and every new signup needs a verification email on top of that.

So I moved to Amazon SES. This post covers what that took, including a few gotchas that cost me time.

The goal

Swap the email transport from Mailgun to SES (SESv2 API).
Send from my own domain, with a custom MAIL FROM subdomain.
Handle bounces and complaints properly. SES watches your bounce and complaint rates closely, and you get put on review if they climb.
Keep Mailgun one env var away, so a rollback needs no code change.
No change to templates or email content. Transport swap plus suppression handling, nothing else.

Step 1: The AWS side

In the SES console, in the region you'll send from:

Verify your sending domain as an identity with Easy DKIM, then add the three CNAME records at your DNS provider.
Set a custom MAIL FROM domain on a subdomain. That's one MX record and one SPF TXT record. Your Return-Path then aligns with your domain instead of amazonses.com, which helps DMARC.
Request production access. New SES accounts start in the sandbox, where you can only send to verified addresses. Do this early, because approval isn't instant.

You get two nice emails when DNS checks out: "DKIM setup SUCCESS" and "Custom MAIL FROM Domain Setup SUCCESS". Then it's time to write code.

Step 2: Choosing the provider with an env var

The project already used django-anymail, which made this mostly a configuration change. To make the provider testable without loading all of production.py (Sentry, Redis, S3, and so on), I put the choice in a small helper:

# config/email_providers.py
from django.core.exceptions import ImproperlyConfigured

SES_BACKEND = "anymail.backends.amazon_ses.EmailBackend"
MAILGUN_BACKEND = "anymail.backends.mailgun.EmailBackend"


def email_provider_settings(env):
    provider = env("EMAIL_PROVIDER", default="ses").strip().lower()

    if provider == "ses":
        return SES_BACKEND, {
            "AMAZON_SES_CLIENT_PARAMS": {
                "region_name": env("SES_REGION"),
                "aws_access_key_id": env("SES_ACCESS_KEY_ID"),
                "aws_secret_access_key": env("SES_SECRET_ACCESS_KEY"),
            },
            "AMAZON_SES_CONFIGURATION_SET_NAME": env("SES_CONFIGURATION_SET", default=None),
            "WEBHOOK_SECRET": env("ANYMAIL_WEBHOOK_SECRET"),
        }

    if provider == "mailgun":
        return MAILGUN_BACKEND, {
            "MAILGUN_API_KEY": env("MAILGUN_API_KEY"),
            "MAILGUN_SENDER_DOMAIN": env("MAILGUN_DOMAIN"),
        }

    raise ImproperlyConfigured(f'EMAIL_PROVIDER must be "ses" or "mailgun", got "{provider}"')

A few deliberate choices:

Dedicated SES credentials. The app already has AWS keys for S3 media storage. Separate variable names mean a least-privilege, SES-only IAM user, and no chance of one set quietly picking up the other.
WEBHOOK_SECRET has no default. If it's missing in production, the app fails at startup instead of serving an unauthenticated webhook.
Rollback is EMAIL_PROVIDER=mailgun and a restart.

In production.py it's a single line:

EMAIL_DELIVERY_BACKEND, ANYMAIL = email_provider_settings(env)
EMAIL_BACKEND = "notifications.email_backends.SuppressionFilterBackend"

EMAIL_BACKEND isn't SES directly. More on that in a moment.

Gotcha #1: The `[amazon-ses]` extra wouldn't install

The obvious change was django-anymail[mailgun] → django-anymail[amazon-ses]. The Docker build failed with a pip ResolutionImpossible.

In anymail 15.x, the amazon-ses extra pulls in boto3 and amazon-s3-encryption-client-python. That second package requires cryptography>=48, which clashed with the rest of my dependency tree. It's only used for encrypted inbound mail stored in S3, which I don't receive. Anymail imports it lazily, so I skipped the extra and installed plain django-anymail plus a pinned boto3 instead.

I also moved anymail from production.txt to base.txt. Tests use Anymail's test backend, and the webhook URLs need to import in every environment.

Step 3: Bounces, complaints, and a suppression list

SES reports bounces and complaints through SNS. Anymail has a tracking webhook that receives those SNS notifications, turns them into normalized events, and fires a tracking signal.

First, mount the URLs:

# config/urls.py
path("anymail/", include("anymail.urls")),

Then a small model to remember who not to email:

class EmailSuppression(models.Model):
    class Reasons(models.TextChoices):
        BOUNCED = "bounced", _("Bounced")
        COMPLAINED = "complained", _("Complained")

    email = models.EmailField(_("Email"), unique=True)
    reason = models.CharField(_("Reason"), max_length=20, choices=Reasons.choices)
    event_payload = models.JSONField(_("Event Payload"), default=dict, blank=True)
    created_at = models.DateTimeField(_("Created At"), auto_now_add=True)

And a receiver:

@receiver(tracking)
def suppress_bounced_and_complained(sender, event, esp_name, **kwargs):
    handle_tracking_event(event)

Gotcha #2: Anymail calls every SES bounce "bounced"

I only wanted to suppress hard bounces (address doesn't exist). A full mailbox or a temporary DNS failure is a transient bounce and shouldn't lock someone out for good.

Anymail normalizes both kinds to event_type="bounced" with reject_reason="bounced". The difference only shows up in the raw SES payload, so you have to check it there:

def is_hard_bounce(event):
    esp_event = event.esp_event if isinstance(event.esp_event, dict) else {}
    return esp_event.get("bounce", {}).get("bounceType") == "Permanent"


def handle_tracking_event(event):
    if not event.recipient:
        return None
    payload = event.esp_event if isinstance(event.esp_event, dict) else {}

    if event.event_type == "complained":
        return record_suppression(event.recipient, EmailSuppression.Reasons.COMPLAINED, payload)

    if event.event_type == "bounced":
        if is_hard_bounce(event):
            return record_suppression(event.recipient, EmailSuppression.Reasons.BOUNCED, payload)
        logger.info("Ignoring non-permanent bounce for %s: %s", event.recipient, event.description)

    return None

Complaints always suppress. Someone hitting "Report spam" is the clearest signal you'll get.

Gotcha #3: The webhook host

My first draft pointed the SNS subscription at the main domain. But the main domain serves the React SPA; Django lives on a separate API subdomain behind the reverse proxy. The subscription URL has to target whichever host actually reaches Django, at Anymail's /anymail/amazon_ses/tracking/ path, with the basic-auth credentials embedded in the URL.

Check your reverse proxy before you paste a URL into SNS. Also leave raw message delivery off, because Anymail expects the SNS envelope.

Gotcha #4: 401, not 400

I wrote a test asserting that a request with no basic auth gets a 400. It got a 401. That's on purpose: SNS doesn't send credentials up front. It only retries with them after a 401 challenge. A webhook that answered 400 there would never receive a single notification. Wrong credentials still get a 400. Anymail also auto-confirms the SNS subscription once the auth checks out.

Step 4: Enforcing suppression in one place

Emails go out from all over the codebase: allauth (verification, password reset), a notification helper, job alerts, team invitations, billing receipts. Adding if is_suppressed(email) to each one would be fragile. Someone adds a new email next month, and suppression silently stops applying to it.

Instead I wrapped the real backend:

class SuppressionFilterBackend(BaseEmailBackend):
    def __init__(self, fail_silently=False, **kwargs):
        super().__init__(fail_silently=fail_silently)
        self.delivery = get_connection(settings.EMAIL_DELIVERY_BACKEND, fail_silently=fail_silently, **kwargs)

    def open(self):
        return self.delivery.open()

    def close(self):
        return self.delivery.close()

    def send_messages(self, email_messages):
        if not email_messages:
            return 0
        if not suppression_bypassed():
            email_messages = filter_suppressed_messages(email_messages)
            if not email_messages:
                return 0
        return self.delivery.send_messages(email_messages)

filter_suppressed_messages runs one query for all recipients across a batch, removes suppressed addresses from to/cc/bcc, and drops any message left with no recipients. Every send_mail() call in the project now honors the list without knowing it exists.

The exception: requests the user explicitly made

Here's a case I didn't want to get wrong. Say someone's mailbox was full last month, or they clicked "spam" by accident. Now they're suppressed and trying to reset their password. Silently dropping that email locks them out of their own account.

So emails the user explicitly requests (a password reset, or clicking "resend verification email") still go out. The automatic verification email sent at signup does not. I used a ContextVar, so the decision is made where the request is handled, not inside the mail layer:

_bypass_suppression = ContextVar("email_suppression_bypass", default=False)


@contextmanager
def allow_suppressed_recipients():
    token = _bypass_suppression.set(True)
    try:
        yield
    finally:
        _bypass_suppression.reset(token)

# PasswordResetRequestAPIView
with allow_suppressed_recipients():
    form.save(request)

allauth sends these emails synchronously inside the request, so the context variable is still set when the backend runs.

Step 5: Staying under the SES send rate

SES gives every account a maximum send rate (emails per second). The job alert digest used to be one Celery task looping over every seeker and sending inline. A rate_limit on that task would throttle the task, not the emails it sends.

So the digest task now creates each seeker's in-app notification and queues one email task per seeker:

BULK_EMAIL_TASK_OPTIONS = {
    "rate_limit": settings.EMAIL_BULK_SEND_RATE,  # e.g. "10/s", read from an env var
    "autoretry_for": (Exception,),
    "retry_backoff": 60,
    "retry_backoff_max": 60 * 60,
    "max_retries": 5,
}


@shared_task(**BULK_EMAIL_TASK_OPTIONS)
def send_job_alert_email(notification_id, email_subject, email_context):
    notification = Notification.objects.select_related("recipient").filter(pk=notification_id).first()
    if notification is None:
        return False
    return send_notification_email(
        notification,
        email_subject,
        email_template="notifications/email/job_alert.html",
        email_context=email_context,
        fail_silently=False,
    )

It's still one email per seeker covering all their matches, never one email per job, and a test enforces that. Celery applies rate_limit per worker, not globally. With one worker that's effectively a global limit; with several, divide the rate between them.

Gotcha #5: Django's test runner replaces your email backend

My suppression tests passed for the webhook and failed for the backend. Emails to suppressed addresses were landing in mail.outbox anyway.

Django's setup_test_environment() (which pytest-django calls) forces EMAIL_BACKEND to locmem, whatever your test settings say. My wrapper never ran. The fix is an autouse fixture:

# conftest.py
@pytest.fixture(autouse=True)
def email_backend(settings):
    # Django's test setup forces EMAIL_BACKEND to locmem, which would bypass
    # the suppression filter. Restore it; it delivers to Anymail's test
    # backend (EMAIL_DELIVERY_BACKEND), which still fills mail.outbox.
    settings.EMAIL_BACKEND = "notifications.email_backends.SuppressionFilterBackend"

with this in the test settings:

EMAIL_DELIVERY_BACKEND = "anymail.backends.test.EmailBackend"

The test settings also define a throwaway WEBHOOK_SECRET, so the webhook tests can send valid and invalid basic auth.

Anymail's test backend still appends to mail.outbox, so all 344 existing tests passed unchanged.

What the tests cover

The provider toggle picks the SES or Mailgun backend, and rejects unknown values or a missing webhook secret.
Real SNS-shaped payloads posted to the webhook: a permanent bounce suppresses, a complaint suppresses, a transient bounce doesn't.
The webhook rejects missing auth (401) and wrong auth (400).
The backend removes suppressed recipients, drops messages with none left, and respects the explicit-request bypass.
A password reset still reaches a suppressed address.
Job alerts skip suppressed seekers (the in-app notification still arrives) and send one digest per seeker.

360 tests pass, and coverage stayed at 85%.

Checking it before deploy

Before deploying, I built the production image and loaded the production settings with dummy SES credentials, to confirm the chain resolves to the suppression wrapper, then Anymail's SES backend, then a sesv2 boto3 client, without sending anything.

After deploy, the real check is Django's built-in sendtestemail management command, run inside the production container with your own inbox as the recipient.

Takeaways

Treat the swap as config if you can. django-anymail made changing providers mostly a settings change. Putting the choice behind a testable function made it a safe one.
Handle bounces and complaints from day one. SES will hold you to it, and a suppression list is about 100 lines of code.
Enforce rules at the transport layer, not at every call site. A backend wrapper covers email paths you haven't written yet.
Read your library's normalization. "bounced" didn't mean "hard bounce".
Keep a rollback. Mailgun stays configured for a week of clean SES sending, then it goes.

GiggleGigs is a job board for gig and contract work: gigglegigs.com.

Case Study: Making My Portfolio Loud (Without Making It Slow)

Vicente G. Reyes — Sat, 24 Oct 2026 02:11:23 +0000

My portfolio worked fine. That was the problem.

It was a tidy neubrutalist site: yellow, cyan and green cards, thick black borders, hard drop shadows, a dark-mode toggle. And it did its job: it helped me land Oatopia, Rev6 and Digital Trek (Rodentia Pest Products) as clients.

But it looked like a lot of other neubrutalist portfolios, and a UX audit I'd been working through kept pointing out the same thing. It was clean and it was forgettable.

So I tried something I'd normally talk myself out of. I went maximalist. Kinetic type, colours that clash, stickers you can throw around, marquees that react to your scroll. Internally I called it the loud redesign.

This post covers what I built, the rules that kept it usable, and the bugs that caught me out.

Live site: vicentereyes.org

The brief I gave myself

Loud, but still a portfolio. Every animation had to sit on top of real content: projects, services, testimonials, blog posts. Nothing decorative could block reading or contacting me.
No new backend. Everything still comes from my existing Django REST API. The redesign was frontend only.
Respect the user. prefers-reduced-motion and touch devices get a proper experience, not a broken one.
Don't tax every page for the homepage's party tricks. Animation code ships in its own chunk.

Step 1: Prototype on a hidden route

I didn't touch the live homepage at first. I built the whole thing on a hidden /loud route so I could compare it with the real site side by side and throw it away if it didn't work.

That first commit added a set of reusable motion primitives under components/motion/:

Primitive	What it does
`KineticText`	Splits a headline into letters with a staggered spring entrance; letters get pushed away from the cursor
`Marquee`	Infinite ticker whose speed and skew follow scroll velocity
`StickerWall`	Draggable, throwable skill stickers kept inside their section
`HorizontalScroll`	A pinned section where vertical scrolling moves you sideways
`MagneticButton`, `LiftCard`, `Parallax`, `Counter`, `CustomCursor`, `ScrollProgress`, `IntroLoader`	The supporting cast

All of them are built on Motion (the library formerly known as Framer Motion).

Once /loud felt right, I moved it onto the real homepage, wired it to the live API hooks I already had, and redirected /loud to /.

Step 2: A design system made of clashes

The new palette is deliberately louder than the old one:

@theme {
  --color-loud-lime: #a3e636;
  --color-loud-ink: #111903;
  --color-loud-cool: #e0e7f1;
  --color-loud-paper: #eeefe9;
  --color-loud-blue: #2d5bff;
  --color-loud-orange: #ff7a00;
  --color-loud-purple: #8b5cf6;

  --shadow-loud: 8px 8px 0 #111903;
  --shadow-loud-sm: 4px 4px 0 #111903;

  --font-anton: Anton, Impact, sans-serif;
  --font-jet: 'JetBrains Mono', ui-monospace, monospace;
}

Anton for the giant headlines, JetBrains Mono for the sticker labels, Space Grotesk for body copy, all on a grid-paper background.

The hard part was making API data look hand-placed. Projects, services and FAQs come from the backend in whatever order and quantity they come in, so I couldn't art-direct each card. Instead, each card gets a colour and a tilt based on its position in the list:

export const FACES = [
  'bg-loud-lime',
  'bg-loud-blue text-loud-paper',
  'bg-loud-orange',
  'bg-loud-purple text-loud-paper',
  'bg-loud-cool',
  'bg-loud-paper',
];

// Small fixed tilts so lists look hand-placed but stay stable between renders.
const TILTS = [-2, 2.5, -3, 3, -1.5, 2, -2.5, 1.5];
export const tilt = (i: number) => TILTS[i % TILTS.length];
export const face = (i: number) => FACES[i % FACES.length];

It looks random, but it's deterministic. Nothing reshuffles when the page re-renders, so you don't get layout jank or hydration surprises. The featured-work grid works the same way, with a repeating pattern of bento column and row spans.

Huge headlines that fill the width need some maths. Anton capitals are about 0.47em wide, so each line gets a font size that keeps it under roughly 92vw:

export const fitLine = (text: string, max = 17) => ({
  fontSize: `min(${max}vw, ${(92 / (Math.max(text.length, 1) * 0.47)).toFixed(2)}vw)`,
});

Step 3: Motion that doesn't fight the browser

Kinetic text without layout thrashing

The hero headline reacts to your cursor letter by letter. The obvious way to build that is to call getBoundingClientRect() on every letter on every pointermove, which is a great way to drop frames.

What I did instead:

One shared pointer listener feeds every component, through Motion values:

  let pointer: { x: MotionValue<number>; y: MotionValue<number> } | null = null;

  export function usePointer() {
    if (!pointer) {
      pointer = { x: motionValue(-9999), y: motionValue(-9999) };
      window.addEventListener('pointermove', (e) => {
        pointer!.x.set(e.clientX);
        pointer!.y.set(e.clientY);
      }, { passive: true });
    }
    return pointer;
  }

Each letter measures its centre once (and again on resize and when fonts finish loading) by walking the offsetParent chain. That skips transforms, so the letter's own animation doesn't change the measurement.
The per-frame work is pure maths on cached numbers: the distance to the pointer becomes a force, and the force drives springs for x, y, rotation and scale. No DOM reads happen while the pointer moves.

On touch devices there's no hover, so tapping a letter makes it jump instead.

Marquees that speed up with your scroll

My first marquee set its speed as a percentage of the track. That meant a marquee with more items scrolled faster in pixels, and every band on the page moved at a different speed. The fix was to define speed in pixels per second and convert it to a percentage using a track width that only gets read on resize:

useAnimationFrame((_, delta) => {
  if (reduced || !inView || !trackWidth.current) return;
  // px/s → percent of the track, so speed doesn't depend on content length.
  let moveBy = direction.current * ((baseVelocity * (delta / 1000)) / trackWidth.current) * 100;
  const factor = velocityFactor.get();
  if (factor < 0) direction.current = -1;
  else if (factor > 0) direction.current = 1;
  moveBy += direction.current * moveBy * factor;
  baseX.set(baseX.get() + moveBy);
});

Scroll velocity also pushes a small skewX, so the bands lean as you scroll fast. Marquees that are off screen (!inView) skip their frame updates entirely.

Case studies that grow out of their card

Clicking a featured project opens a full-screen case study that expands from the card itself, using Motion's shared layoutId. The overlay is lazy-loaded, so react-markdown stays out of the homepage's first load. It handles focus, closes on Escape and locks page scrolling while it's open.

The intro plays once

The homepage has an intro loader. Seeing it every time you come back to the homepage would get old quickly, so it runs once per session behind a sessionStorage flag wrapped in try/catch (private windows can throw).

Step 4: Accessibility rules I didn't break

A maximalist site is where accessibility tends to get dropped. These were non-negotiable:

Reduced motion is a real mode. Marquee renders as static text with no skew. HorizontalScroll becomes a normal vertical stack. Letter entrances become a simple fade. Parallax layers stay still.
Cursor effects need a fine pointer and motion allowed:

  export function usePointerEffects(): boolean {
    const isTouch = useIsTouch(); // (hover: none), (pointer: coarse)
    const reduced = useReducedMotion();
    return !isTouch && !reduced;
  }

Split text is still readable. KineticText puts aria-label with the full headline on the wrapper and hides the individual letter spans from screen readers.
Duplicated marquee copies (it renders four for a seamless loop) are aria-hidden after the first.
The case study overlay is a proper role="dialog" with aria-modal and aria-labelledby, and focus moves to the close button.

Step 5: Rebuild every page

A loud homepage next to a quiet inner site would have felt like two different websites, so I rebuilt every page in the new style:

About and its sub-pages (Now, Uses, Music, Certifications)
Blog list, posts, series and tag pages: grid-paper backgrounds, sticker metadata, article prose restyled to the new palette
Services list and detail, plus the Works hub, Professional, Personal, Audio, Tech and project pages
Contact, Guestbook (entries are now sticky notes), Privacy, Terms, 404 and Unsubscribe
The cookie banner, resume modal and loading/error fallbacks

Doing this many pages forced me to extract shared pieces: LoudLayout (the page shell), LoudPageHeader (kinetic title plus sub-page tabs), LoudPostGrid, LoudProjectBrowser (search, category filters, animated grid), LoudFaqList, and LoudBriefSection. That last one replaced three separate copies of the inline contact form.

The form logic moved into useContactForm and useNewsletterForm hooks, so the old and new UIs submitted the same way during the transition. That made the switch-over low-risk.

Step 6: Delete everything

This is the part I'm proudest of. After the rebuild, I removed:

Components: the old Navbar, Footer, Hero, Projects, Services, Stats, Testimonials, FAQs, Button, Card, DevIcon, the old project and service modals, and an AI assistant widget that wasn't earning its place
Packages: framer-motion (as a direct dependency), lucide-react, react-countup, react-intersection-observer and @google/genai
Dark mode. The loud design is light-only on purpose: the whole look depends on ink on paper. LoudLayout removes the dark class while it's mounted.

Across the redesign: 86 files changed, 5,423 lines added, 8,454 lines removed. The site does more than it did before, with about 3,000 fewer lines of code.

Bundle split

Motion gets its own chunk, so pages that don't animate much don't pay for it up front. Because motion depends on framer-motion internally, they have to go in the same chunk, or you end up with duplicated runtime code:

manualChunks(id) {
  if (['react', 'react-dom', 'react-router-dom', 'react-helmet-async'].some(pkg => id.includes(`/node_modules/${pkg}/`))) {
    return 'chunk-react';
  }
  // motion depends on framer-motion internally; keep the whole animation stack in one chunk.
  if (['motion', 'motion-dom', 'motion-utils', 'framer-motion'].some(pkg => id.includes(`/node_modules/${pkg}/`))) return 'chunk-motion';
  if (id.includes('/node_modules/@sentry/')) return 'chunk-sentry';
},

Current production build, gzipped:

Chunk	Size (gzip)
App entry	~26 KB
React + router	~71 KB
Motion	~56 KB
Sentry	~54 KB
Each page	0.5–7.5 KB raw

Every page is lazy-loaded, so a visitor only downloads the page they're looking at.

Gotchas I hit

1. overflow-x: hidden broke position: sticky.
The pinned horizontal-scroll section wouldn't stick. The cause was a global overflow-x: hidden on html and body, which turns body into a scroll container and breaks sticky positioning for everything inside it. The fix is overflow-x: clip, which hides overflow without creating a scroll container:

// The global overflow-x: hidden on html/body makes body a scroll container,
// which breaks position: sticky (HorizontalScroll). clip hides overflow
// without that side effect.
els.forEach((el) => (el.style.overflowX = 'clip'));

2. A CommonJS-only package crashed the homepage under Vite 8.
During a dependency upgrade, react-countup (which only ships CommonJS) had its default import resolved to the entire exports object. React tried to render that object, threw error #130, and the homepage crashed as soon as the stats section scrolled into view. I unwrapped .default as a quick fix, then removed the package in the cleanup.

3. @vercel/og 0.11 and later wouldn't build on Edge.
The newer edge build imports Node's module (createRequire), which Vercel Edge Functions reject at build time. I pinned it to 0.11.1.

4. Social previews were quietly broken.
The fallback og:image pointed at a Twitter profile-photo URL that had started returning 404, so links to the homepage were shared with no image. It's now a self-hosted 1200×630 card with og:image:width and og:image:height declared, so Facebook renders it on the first share instead of processing it in the background. Detail pages (case studies, blog tags, series, tech) also get their own generated OG images from an edge function.

5. Phones needed their own layout.
The first version of the hero looked great on desktop and fell apart on phones. Phones now get one word per headline line, the stickers sit above the headline instead of scattered around it, the hero height is capped on tall tablets, and the bento grid only uses four columns at lg and up.

What I'd do differently

Plan for reduced motion from day one. I did this, and it's the only reason the reduced-motion version doesn't feel like an afterthought. Every primitive decides its fallback up front.
Prototype on a hidden route again. Being able to compare /loud with the live site was the most useful decision in the whole project.
Extract shared components sooner. I wrote the contact form three times before turning it into LoudBriefSection. I should have stopped at two.

Wrapping up

The redesign took four days, from the first /loud prototype to the final cleanup. The site is louder and lighter, and every page shares one set of components.

Go throw some stickers around at vicentereyes.org, and if you're planning a site that needs to stand out, let's talk.

Built with React 19, Vite 8, Tailwind CSS 4 and Motion, on a Django REST backend.

A Gemini 500 on a resume upload turned into a .docx bug, a frozen DigitalOcean droplet, a timed-out deploy, and a corrupted zip file. Here's every fix.

Vicente G. Reyes — Wed, 21 Oct 2026 08:25:54 +0000

It started with one Sentry alert on a Tuesday night:

ServerError: An internal error has occurred. Please retry or report in
https://developers.generativeai.google/guide/troubleshooting
Transaction: job_board.seekers.tasks.parse_resume

GiggleGigs is a job board I run. When a job seeker uploads a resume, a Celery task sends it to Google's Gemini API, which pulls out their name, headline, skills, links and years of experience and fills in their profile. One seeker's resume had failed to parse.

Easy fix, I thought. Gemini had a hiccup, so add a retry.

Two days later I had fixed four separate bugs, frozen my production server, restarted it from the DigitalOcean dashboard, and learned more about the .docx format than I ever wanted to. Here's how it went.

Bug #1: One transient error, permanent failure

The task looked roughly like this:

@shared_task
def parse_resume(profile_id):
    ...
    try:
        response = client.models.generate_content(...)
        # parse JSON, fill in the profile
        profile.parsing_status = SeekerProfile.ParsingStatus.DONE
        profile.save()
    except Exception:
        logger.exception("Resume parsing failed for profile %s", profile_id)
        profile.parsing_status = SeekerProfile.ParsingStatus.FAILED
        profile.save(update_fields=["parsing_status"])

Every exception was final. A 500 INTERNAL from Gemini, which is Google's problem and usually gone a minute later, permanently marked the resume as failed and sent an error to Sentry.

The fix was to make the task bound, retry the error codes that are worth retrying, and back off exponentially:

# Gemini errors worth retrying: quota exhausted (429), internal error (500),
# model overloaded (503). Retried after 1, 2, then 4 minutes.
TRANSIENT_GEMINI_CODES = (429, 500, 503)
PARSE_RESUME_MAX_RETRIES = 3


@shared_task(bind=True, max_retries=PARSE_RESUME_MAX_RETRIES)
def parse_resume(self, profile_id):
    from google.genai import errors as genai_errors
    ...
    try:
        ...
    except genai_errors.APIError as exc:
        if exc.code not in TRANSIENT_GEMINI_CODES:
            logger.exception("Resume parsing failed for profile %s", profile_id)
        elif self.request.retries < self.max_retries:
            raise self.retry(countdown=60 * 2**self.request.retries)
        else:
            logger.warning(
                "Gemini unavailable (%s); gave up parsing resume for profile %s: %s",
                exc.code, profile_id, exc.message,
            )
        profile.parsing_status = SeekerProfile.ParsingStatus.FAILED
        profile.save(update_fields=["parsing_status"])
    except Exception:
        ...

Two details are worth pointing out.

Order matters. self.retry() raises celery.exceptions.Retry, which is a subclass of Exception. If the generic except Exception came first, it would swallow the retry. Raising from inside one except clause skips the sibling clauses, so this layout is safe.
Warning vs. error. If Gemini is still down after three retries, that's an outage, not a bug, so it gets logged as a warning. Real bugs, like a 400, still go to Sentry as errors.

I deployed it and re-ran the failed resume. It failed again.

Bug #2: Gemini doesn't read Word files

I opened the profile in the Django admin and saw the file name: ..._CV_Updated.docx.

The task sent every resume to Gemini as raw bytes with whatever MIME type matched the file extension:

MIME_MAP = {
    ".pdf": "application/pdf",
    ".docx": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
    ".doc": "application/msword",
}

Gemini reads PDFs as inline documents. Word files aren't supported, and instead of a clear 400 Unsupported MIME type, the request came back as a 500 INTERNAL. So the "transient" error was actually permanent for this file, and my new retries would have tried it three more times and failed every time.

The fix: for .docx, extract the text locally and send it to Gemini as part of the prompt. PDFs still go as bytes. Legacy .doc files (the old binary format) get skipped with a warning.

My first version used python-docx. That turned out to be the wrong choice, as you'll see in Bug #4.

Bug #3: The deploy that froze the server

Adding python-docx meant a new line in requirements/base.txt. My deploy is a GitHub Action that SSHes into a DigitalOcean droplet and runs:

git pull origin main
docker compose -f production.yml build
docker compose -f production.yml run --rm django python manage.py collectstatic --noinput
docker compose -f production.yml run --rm django python manage.py migrate
docker compose -f production.yml up -d

Changing the requirements file invalidates Docker's cached pip wheel layer, so every package is rebuilt from scratch. One of those packages was psycopg[c], the C-accelerated PostgreSQL driver, which compiles from source.

Here's what went wrong:

The build was still compiling psycopg-c when appleboy/ssh-action hit its default 10-minute command_timeout and killed the session.
The droplet has 2 GB of RAM and no swap. Compiling C while serving the site pushed it into memory exhaustion. The dashboard showed 90% memory and 83% CPU.
The site stopped responding, and so did SSH.

I had to click Actions → Restart in the DigitalOcean dashboard. Docker's restart: unless-stopped policy brought the old containers back, so the site came back up on the previous image.

Three fixes came out of this.

Add swap so a heavy build slows down instead of freezing the machine:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

During the next build, top showed about 920 MB of swap in use. Without it, the box would have frozen again.

Stop compiling on the server. psycopg[binary] ships precompiled wheels:

-psycopg[c]==3.2.2
+psycopg[binary]==3.2.2

The next full rebuild went from timing out to about 3 minutes.

Make the deploy job tolerant and fail-fast:

- name: Deploy via SSH
  uses: appleboy/ssh-action@v1.0.3
  with:
    # ...
    # A requirements change rebuilds every wheel, which can
    # outlast the action's 10m default.
    command_timeout: 30m
    script_stop: true

script_stop: true matters as much as the timeout. Without it, a failed build still continues on to up -d.

Bonus bug: ghost containers

While I was recovering, I ran the deploy by hand in tmux, and the GitHub Action ran at the same time. The two docker compose up -d runs collided and left behind containers with names like 430e938fc82c_gigglegigs-celerybeat-1. After that, every deploy failed with:

Error response from daemon: Conflict. The container name "/gigglegigs-celerybeat-1"
is already in use by container "430e938fc82c...".

The fix is to remove the stateless app containers (never Postgres or Redis) and bring them back up:

docker ps -a --format '{{.Names}}' \
  | grep -E 'gigglegigs-(django|celeryworker|celerybeat|flower)-1$' \
  | xargs -r docker rm -f
docker compose -f production.yml up -d

The lesson: never run two deploys against the same Compose project at the same time.

Bug #4: A corrupted image inside a Word file

With everything deployed, I re-ran the resume. FAILED, again. The worker logs had the answer:

File "/usr/local/lib/python3.11/site-packages/docx/opc/phys_pkg.py", line 83, in blob_for
    return self._zipf.read(pack_uri.membername)
...
zipfile.BadZipFile: Bad CRC-32 for file 'word/media/image1.png'

A .docx is a zip archive. The text lives in word/document.xml, and images live under word/media/. This seeker's file had an embedded image (probably a profile photo) whose checksum didn't match. Word doesn't care and opens the file fine. python-docx, however, loads every part of the package when you open it, including images it never needs, so one bad PNG took down the whole parse.

I only needed the text, so I dropped python-docx and read the one XML file directly with the standard library:

import io
import zipfile
from xml.etree import ElementTree

WORD_NS = "{http://schemas.openxmlformats.org/wordprocessingml/2006/main}"


def _docx_text(file_content):
    """Plain text of a .docx, one line per paragraph (table cells included).
    Only word/document.xml is read, so a corrupt embedded image (which Word
    tolerates) doesn't fail it."""
    with zipfile.ZipFile(io.BytesIO(file_content)) as archive:
        root = ElementTree.fromstring(archive.read("word/document.xml"))
    lines = [
        "".join(node.text or "" for node in paragraph.iter(f"{WORD_NS}t"))
        for paragraph in root.iter(f"{WORD_NS}p")
    ]
    return "\n".join(line for line in lines if line.strip())

Every paragraph is a <w:p> and every run of text is a <w:t>. Table cells contain paragraphs too, so resumes laid out in tables come through with no extra code. And I had one fewer dependency.

To make sure this stays fixed, the test builds a .docx by hand and deliberately corrupts the image. In ZIP_STORED mode the bytes sit raw in the archive, so you can change them without updating the CRC:

def _docx_bytes(corrupt_image=False):
    buffer = io.BytesIO()
    with zipfile.ZipFile(buffer, "w") as archive:
        archive.writestr("word/document.xml", DOCUMENT_XML)
        archive.writestr("word/media/image1.png", IMAGE_BYTES)
    content = buffer.getvalue()
    if corrupt_image:
        # Flip the stored image bytes without updating the zip's CRC-32.
        content = content.replace(IMAGE_BYTES, IMAGE_BYTES.upper())
    return content


@pytest.mark.parametrize("corrupt_image", [False, True])
def test_docx_resume_is_sent_as_text(profile, corrupt_image):
    ...

I checked that this fixture raises exactly the same Bad CRC-32 for file 'word/media/image1.png' as the real resume before trusting the test.

One more deploy, one more parse_resume.delay(...), and then:

DONE

What I took away

Not every 5xx is transient. Gemini returned 500 INTERNAL for an unsupported file type. Retries handle real outages, but read the error and what you sent before assuming it's the provider's fault.
Only parse what you need. A full-document library is the wrong tool when all you want is text. zipfile plus ElementTree handled a file that python-docx couldn't.
Small servers need swap. On a 2 GB droplet, one heavy build can take down the site and SSH with it. Swap is cheap insurance.
Don't compile in production. Prefer prebuilt wheels like psycopg[binary]. If you must compile, build the image in CI and pull it, rather than building on the box that serves traffic.
Deploy scripts should fail fast and never overlap. script_stop: true, a realistic timeout, and one deploy at a time.
Run long server commands in tmux. If your SSH connection drops halfway through a build, the build keeps going.

A single user's resume exposed four weaknesses in the stack. All of them are fixed now, and the next person who uploads a slightly broken Word file won't notice anything happened.

I'm building GiggleGigs, a job board for gigs and contract work, with Django, Celery and React. If you've been bitten by a .docx file too, I'd love to hear about it in the comments.

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.

DEV Community: Vicente G. Reyes

My first freelance client paid me $5. Here's what I'd tell myself at that stage.

1. You probably already have something sellable

2. Sell an outcome, not a skill

3. Say what you can't do yet

4. Scope before you start, every time

5. Don't price like a hobbyist forever

The playbook

From Side Projects to Your First Paying Client: A Practical Guide for Developers

1. Pick one offer a stranger understands in ten seconds

2. Make your portfolio sell, not just exist

3. Find your first lead (it probably isn't a job board)

4. Price without panic

5. Write a one-page proposal and protect yourself

6. Deliver so one client turns into three

Want the full playbook?

Zero-Downtime Django Deploys on One Small Droplet

Why 99.99% means deploys can't cause any downtime

Measure first

Why a deploy went down

Step 1: Collect static files when the image is built

Step 2: A healthcheck, and a second container

The first live deploy still dropped requests

Reproducing it locally

Two bugs, one cause

Step 3: Route only to healthy containers

Step 4: Drain before you stop

The rehearsal, with the CPU capped

A gunicorn 26 surprise

The transitional deploy

Result

What 99.99% still needs

Takeaways

Stop Building Docker Images on Your 2 GB Droplet

The problem: the droplet was also the build server

The goal

Step 1: One image instead of four

Step 2: Build and push in GitHub Actions

Gotcha #1: workflow_run doesn't check out what CI tested

Gotcha #2: Private repo, private package

The cache

Step 3: The droplet only pulls

No long-lived registry token on the server

Why git pull still runs

Gotcha #3: Don't push your Postgres image

Gotcha #4: Overlapping deploys

A step I deleted

Cleaning up

Rollbacks

Checking it before merging

The first deploy

What this doesn't fix

Takeaways

Moving a Django App from Mailgun to Amazon SES

The goal

Step 1: The AWS side

Step 2: Choosing the provider with an env var

Gotcha #1: The [amazon-ses] extra wouldn't install

Step 3: Bounces, complaints, and a suppression list

Gotcha #2: Anymail calls every SES bounce "bounced"

Gotcha #3: The webhook host

Gotcha #4: 401, not 400

Step 4: Enforcing suppression in one place

The exception: requests the user explicitly made

Step 5: Staying under the SES send rate

Gotcha #5: Django's test runner replaces your email backend

What the tests cover

Checking it before deploy

Takeaways

Case Study: Making My Portfolio Loud (Without Making It Slow)

The brief I gave myself

Step 1: Prototype on a hidden route

Step 2: A design system made of clashes

Step 3: Motion that doesn't fight the browser

Kinetic text without layout thrashing

Marquees that speed up with your scroll

Case studies that grow out of their card

The intro plays once

Step 4: Accessibility rules I didn't break

Step 5: Rebuild every page

Gotcha #1: `workflow_run` doesn't check out what CI tested

Why `git pull` still runs

Gotcha #1: The `[amazon-ses]` extra wouldn't install