From Forgotten Tech Test to Mini Product: The Comeback of My Django Proxy

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I took one of...

title: From Forgotten Tech Test to Mini Product: The Comeback of My Django Proxy published: true cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/re1kkjbpc84qj65e918r.png tags: devchallenge, githubchallenge

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I took one of my old projects (a Django + DRF proxy) and turned it into something that actually feels like a product: a Control Room to monitor traffic and contain abuse.

Before, it was basically a “request forwarder doing its best.” Now it includes:

• A main dashboard at / with metrics, recent activity, top paths, and risk signals;
• An /insights/ endpoint with a JSON summary for automation and observability;
• A persistent IP/path blacklist with a simple UI CRUD flow, so no one needs to edit .env and restart everything;
• Migration, tests, and a coverage gate to make it more reliable and less “Friday 11 PM proof-of-concept energy.”

In short: it used to be a utility. Now it is demoable, shareable, and ready to grow through forks.

Demo

You can present the demo in 3 acts:

1. Control room online: open / and show the dashboard with counters and the incident feed.
2. Traffic coming in: hit the proxy endpoints to populate data.
3. Containment in action: create a blacklist rule and trigger a live block.

Main routes:

• Dashboard: /
• Insights JSON: /insights/
• Proxy: /proxy/{path}
• Registry: /registry/

Quick local commands:

# run the app
make run
# or
python3 manage.py runserver

# hit the proxy to generate entries
curl http://localhost:8000/proxy/100
curl http://localhost:8000/proxy/admin

# after creating a path=admin/* rule in the dashboard:
curl http://localhost:8000/proxy/admin  # should be blocked

The Comeback Story

This project started as a POC from a technical assessment I did for a job about 6 years ago. It was simple, Docker/Docker Compose-based, had a basic cache approach, and did what it needed to do. I got approved, mission accomplished, repo archived in the “someday” folder.

It was never meant to become a real open-source project or a product.

With Finish-Up-A-Thon, I decided to give it a comeback arc: take it off the shelf and give it a professional finish. The idea was to keep the technical core, but improve what was missing so people would actually want to use it:

• a narrative UI (not just raw endpoints);
• real operational control (runtime-editable blacklist);
• tests and coverage to reduce surprises;
• branding and consistency so it feels alive.

So this became one of my favorite project stories: “it was a functional draft, now it is something I am proud to share.”

My Experience with GitHub Copilot

GitHub Copilot was the key piece that helped me move this repo from “it works on my machine” to “this looks and feels like a product.”

What Copilot accelerated in practice:

• troubleshooting pending app issues;
• implementing and tuning tests with real coverage;
• tightening branding and visual consistency;
• polishing the small details that improve product perception (docs, flow, consistency).

In other words, many of these were not huge technical challenges, but they were exactly the kind of improvements people keep postponing. With Copilot, “later” turned into “done now.”

Repo link: https://github.com/lucasrafaldini/proxy