MLH_PE_Hack_2026 —URL_Shortener

Inspiration

For a long time we had been hearing about Production Engineering and the role of Production Engineers at tech companies. Participating in this hackathon gave us a great opportunity to move beyond theory and get hands-on exposure to modern engineering standards — reliability, observability, testing pipelines, and the conventions that keep real services alive in production where critical thinking is key.

What it does

The project is sort of production-grade URL shortener built on the official MLH PE Hackathon 2026 template. It exposes a REST API that allows us to shorten long URLs into short codes, redirect visitors to their original destinations, manage users and URLs, and track analytics events. Beyond the core functionality, the service is built with reliability in mind — every endpoint returns clean JSON errors, invalid inputs are rejected before touching the database, inactive URLs return proper 410 responses, and every redirect is recorded as a click event for analytics.

How we built it

We started by cloning the official template which gave us a Flask + Peewee ORM + PostgreSQL skeleton, we were initially planning to use Docker but since we had not used PostgreSql before we choose otherwise. We then designed and implemented three data models — Users, URLs, and Events — and built out a full REST API covering CRUD operations, bulk CSV import endpoints, filtering by query parameters, and a redirect engine that logs click events. We wrote 40 automated tests covering unit tests, integration tests, and edge cases, and set up a GitHub Actions CI pipeline that runs the full test suite with coverage enforcement on every push. The service reaches 87% code coverage and passed 28 out of 29 judge-run automated tests.

Challenges we ran into

The biggest challenge was (realizing mid-hackathon) the judge's automated tests expected a completely different data model and API contract than what we had initially built — with separate Users, URLs, and Events tables and specific field names like short_code, original_url, and is_active. We had to improve our initial code and models. We also ran into PostgreSQL sequence issues after bulk-loading CSV seed data with explicit IDs, which caused auto-increment to conflict with new inserts. Debugging PATH issues with uv and PostgreSQL on Windows at the start also cost us time we hadn't budgeted for.

Accomplishments that we're proud of

We're proud of passing 28 out of 29 judge-run automated test cases, which required not just working endpoints but precise validation, correct HTTP status codes, proper event logging on redirects, and handling edge cases like inactive URLs and duplicate inputs. Getting from zero to a fully tested, CI-verified REST API in one weekend — while also learning the tooling from scratch — felt like a genuine production engineering experience.

What we learned

We learned how production engineers think about reliability from day one — writing tests before worrying about features, setting up CI so broken code can never reach main, and documenting failure modes so anyone can operate the service. Earlier we used to think that CI/CD must been some sort of a framework of its own completely different type involving heavy software not se beginner friendly, only to realize that its just a concept and its implementation can be as simple as a GitHub Workflow/Action.

What's next for MLH PE Hackathon 2026 — URL Shortener

The natural next steps would be completing for the other quests/tracks - we wanted to explore other challenges and their implementations as well but due to time constraint only made one track mvp. We will for sure explore the remaining tracks.

Built With

• flask
• githubactions
• peeweeorm
• postgresql
• pytest