The Deployment Odyssey: A Portfolio That Refused to Die
By Ax de Klerk | 28 Nov 2025
Deployment is supposed to be the final step — the tidy ribbon you tie around a finished project. In reality, it often feels like being dropped into the backend of an internet boiler room, surrounded by switches that don’t do what they claim. When I first attempted to publish my portfolio, I thought it would be a straightforward affair: select a service, connect a repo, press deploy. Instead, I embarked on a journey that involved more database migrations than my degrees involved dissertations.
What I learned is that deployment isn’t just technical — it’s emotional. It exposes the limits of documentation, infrastructure, and occasionally your own patience. But beneath the frustration lies something oddly liberating: the understanding that even when systems collapse, you can rebuild them, line by line.
1. Render and the Art of False Promises
My journey began with Render — a platform that once, apparently, provided free databases. The keyword here is once. Halfway through my setup, Render quietly rearranged their pricing strategy, removed features I was using, and transformed the deployment process into a digital ghost hunt. My configuration files were correct; the platform no longer was. It was like trying to dock a boat while the port authority is dismantling the harbour in real time.
The experience taught me an early truth: sometimes the obstacle isn’t your code — it’s the architecture you’re trying to stand on. The illusion of stability disappeared, and with it any lingering belief that platform-as-a-service offerings are predictable. I left Render behind, not with anger, but with the quiet resignation of someone who has finally understood that “free tier” is a philosophical concept, not a contractual agreement.
2. NeonDB: Hope, Confusion, and the UTF-8 Curse
NeonDB arrived like a beacon: clean UI, modern features, and — crucially — an actual free tier. It seemed promising. Then I attempted to migrate my data. Cue the encoding errors. Somewhere between exporting fixtures and re-importing them, the universe decided to introduce a byte-order mark (BOM), the digital equivalent of a gremlin. Its broke migrations, corrupted JSON, and made Django throw life-dooming errors like “UnknownSchemeError”, which felt less like a bug and more like a personal criticism.
The clean solution was ironically the least technical one: delete everything, start again, and rebuild the data by hand. In that moment, I realised that tooling can fail, exports can break, services can shift, but the old-fashioned method of doing things manually still works. It’s slower, but dependable — like a typewriter in a world full of auto-correct.
3. Heroku: Returning to the Old Familiar
In the end, I returned to Heroku — the deployment equivalent of moving back into a childhood home after a disastrous flat-share. It still as a free tier that it is reliable, comprehensible, and didn’t gaslight me about database availability. Connecting Heroku to Neon felt like stabilising two tectonic plates. Suddenly, migrations behaved. Static files behaved. Even collectstatic, the silent saboteur of many a Django deployment, complied without incident.
What struck me most was how comforting predictability can be. Heroku didn’t try to surprise me. It asked for a Procfile, Python version, environment variables — nothing dramatic, nothing cryptic. The quiet professionalism of it made me wonder why I’d ever tried to leave.
4. Rebuilding From the Fragments
The final hurdle was the data itself. After losing fixtures to encoding chaos and abandoning the fantasy of a plug-and-play migration, I rebuilt everything manually in the Neon admin panel. It felt less like coding and more like archaeology: reconstructing artefacts from fragments, re-entering descriptions, re-uploading media, rewriting blog posts that had existed three times before. But through that repetition came clarity — an understanding of my own work, not as files or objects, but as something crafted line by line.
This isn’t the part of development people romanticise, but perhaps it should be. There’s a quiet discipline in rebuilding, in not giving up when automation fails, in knowing your project so well you can reconstruct it from memory. It reminds you that under all the tooling, frameworks, and services, the constant factor is you.
5. The Lesson Beneath the Deployment
Looking back, the real victory wasn’t getting the site live — it was understanding the architecture behind it, the ways systems interact, break, recover, and continue. I entered this simple project thinking deployment was a final step. Now I see it as a continuation of the same logic that underpins coding itself: identify the failure, debug the failure, rebuild what must be rebuilt.
The deeper truth is simpler: structure isn’t permanent. Infrastructure can collapse without warning. Databases vanish. Services rebrand. Encodings corrupt. The resilience isn’t in the tools — it’s in the willingness to reconfigure them. Deployment, at its core, is an act of adaptation.
6. The Portfolio That Refused to Die
When the portfolio finally went live — connected to Neon, deployed on Heroku, stitched together with configuration files that had been rewritten more times than my academic dissertations — it felt less like triumph and more like relief. Not because the process was easy, but because I’d survived it. Each error, each rollback, each inexplicable failure had taught me something about the fragility of systems and the persistence required to navigate them.
This wasn’t just a deployment. It was a reminder that the things we build are temporary, precarious, and held together as much by patience as by code. And yet, somehow, they work. Sometimes beautifully.
Final Reflection
If I were advising another new developer about deployment, I’d say this: expect the unexpected. Documentation lies. Platforms change. Exports corrupt. But somewhere beneath the chaos is a structure that can be rebuilt, if you’re willing to approach it with humour, stubbornness, and a willingness to question every assumption.
Deployment isn’t a final step — it’s a confrontation with the realities of modern tooling. But it’s also a quiet form of liberation. Once you’ve survived your first catastrophic deployment cycle, nothing in development really scares you anymore. You learn to navigate the rubble, to trust your own problem-solving, and to accept that sometimes the only way out is through the looking glass.