Issue 01 / Portfolio / 2026
I build web applications end to end — the database, the API, and the part people actually touch. I'm looking for my first full-time role on a team that reviews code and lets juniors own something real.
Most of what's below started as a problem I couldn't stop thinking about: a scheduling tool for a friend's studio, a scraper that saved me an hour a week, a game I built to understand how physics loops work. Each one is finished enough to use and honest about what it doesn't do yet.
If you're hiring, the fastest way to judge me is to read the code — every project links to its repository. If you'd rather talk first, the contact section at the bottom reaches me directly.
Section 01/Selected work
Drag the strip sideways to move through them — or use the arrow keys once it's focused. Each card says what the thing does, what I built it with, and what I'd do differently now.
01
Full-stack web app
A booking tool for a small studio: clients pick a slot, the owner sees the week at a glance and gets an email when something changes. Built because the studio was running its calendar out of a paper diary.
What I'd change: the availability logic lives in one long function. Next time it gets its own module with tests.
02
Python command-line tool
Pulls a set of public data sources on a schedule, cleans them into one table, and writes a short summary I read with coffee. It replaced about an hour of manual copying every week.
What I'd change: it fails loudly when a source changes shape, which is correct, but the error message should say which field moved.
03
Browser game
A small arcade game built to teach myself how a game loop actually works — fixed timestep, collision, state that survives a pause. Runs on canvas, no engine, no dependencies.
What I'd change: input handling is tangled with rendering. They should never have been in the same file.
04
API & documentation
A small REST service with authentication, rate limiting, and documentation I wrote by hand so a stranger could integrate it without asking me anything. The docs were the hard part.
What I'd change: I'd write the tests before the endpoints, not after. I learned that the slow way.
Section 02/Tools
Honest labels: daily means I've used it on something that shipped, learning means I'm partway through and won't pretend otherwise.
I read the error message before I search for it. I write the smallest version that could possibly work, then make it correct, then make it readable. I leave comments explaining why, never what. When I'm stuck for more than half an hour I write down what I've ruled out and ask someone — that habit has saved me more time than any tool on this page.
Section 03/About
I came to software the long way round — [one line about how you got here: a course, a degree, a career change, a project that got out of hand]. What kept me is the part where something that didn't work starts working, and you can point at exactly why.
I'm self-directed about learning. When I hit something I don't understand I read the source, or the spec, or someone's blog post from 2014 that explains it better than the current docs. I keep a running file of things I got wrong and what the fix was, because I'd rather make each mistake once.
What I want from a first role: code review from people who've seen more than I have, a codebase bigger than one person can hold in their head, and problems that aren't solved by a tutorial. I'm not precious about the stack — I'll learn whatever the team uses.
Outside of work I [one line about something you do that isn't code — a sport, an instrument, a side interest]. It shows up in how I build: [one line connecting the two, or delete this sentence].
Full CV available on request — ask me.
Section 04/Questions
The five questions that come up most from recruiters and hiring managers. If yours isn't here, the form at the bottom of the page is the fastest route.
01
Everything on this site is self-directed — no employer has paid me to write code yet. That means I can't point at a team I shipped with, but it also means every project here is mine end to end: the schema, the API, the interface, the deployment, and the bugs I had to sit with until they made sense. [One line about any internship, freelance job, or open-source contribution you've done — delete this sentence if there isn't one yet.]
02
A junior or graduate developer position on a team that reviews code and gives feedback. I'd rather join somewhere I'm the least experienced person in the room than somewhere I'm left alone with a ticket and no one to ask. Full-time, and I'm open to remote, hybrid, or on-site near [City].
03
I've moved between JavaScript, Python, and SQL without much friction, and I'm partway through TypeScript and Next.js now. The honest answer is that the first weeks are reading, not writing: understanding the codebase, the conventions, and why things are the way they are. I'm comfortable being slow at the start if it means I'm not breaking things I don't understand yet.
04
Yes — every project in the strip above links to its repository, and I'd rather you read it than take my word for anything. The commit history is real, including the mess. If you want a walkthrough of a specific decision, ask and I'll explain what I was thinking, including where I'd do it differently now.
05
Gladly. A paid trial, a take-home exercise, or a short contract is a fair way for both of us to find out whether this works — and it tells me more about your team than the interview would. Send the brief and a deadline and I'll tell you honestly whether I can do it well in the time.
Section 05/Contact
Both are fine. I reply to everything within a day or two. If you're a recruiter, a link to the role helps me answer properly the first time.