A small enquiry into why the hardest part of building for the web was never actually the building
3am. One tab open. console.log("why").
Not console.log("why is this null"). Not console.log("why is this undefined"). Just why. Sitting there in the terminal like a full sentence, because at some point that evening the debugging had quietly stopped being about the code and started being about something else entirely, and I hadn't noticed the switch happen.
You do know it's not actually broken, don't you?
That was the thought. Uninvited, unhelpful, entirely correct. The function worked. The tests passed. The site rendered exactly as it should on every device I threw at it. And yet there I was, elbows-deep in a component that had done nothing wrong, looking for a bug that didn't exist, because somewhere underneath the syntax was a much older, much less technical question that refused to compile.
Every Developer Has One Tab They Won't Close
You know the one. Not the documentation tab. Not Stack Overflow, God rest its soul. The other one. The one with someone else's finished, beautiful, effortless-looking website open in it, sitting there quietly ruining your evening.
Why doesn't mine look like that?
I used to think this was a skill problem. More hours, more tutorials, one more course on "advanced" whatever, and eventually the gap would close. It never quite does, though — not because the skill isn't real, but because the thing I was actually comparing wasn't code at all. It was the invisible layer underneath the code: the design decisions, the content strategy, the thing that makes a site feel like it was built for someone, rather than merely built.
Nobody puts that bit in the tutorial. There's no npm install taste.
The Day I Stopped Building Everything Myself
Here's the confession, and it took me an uncomfortably long time to admit it out loud in a room full of other developers: I used to think outsourcing any part of a project was a small defeat. Real developers build the whole thing. Frontend, backend, deployment pipeline, the logo, the copy, the client's entire digital existence — all of it, alone, at 3am, fuelled by nothing but spite and instant noodles.
That's not dedication. That's just poor scoping.
A friend of mine — freelance, brilliant with React, hopeless with everything that happens before React — finally admitted defeat on a client project that needed proper brand design, SEO structure, and a content strategy alongside the actual build. He didn't have the bandwidth to be a one-person agency anymore, and pretending otherwise was quietly costing him both sleep and client trust.
He ended up bringing in Avanexa Technologies), a web design and development company, to handle the parts of the project that sat outside his lane — the design system, the SEO-friendly architecture, the ongoing digital marketing the client actually needed post-launch. He still owned the build. He just stopped pretending he needed to own everything else too.
What changed wasn't the code. It was the site actually working — as a whole thing, not just a repository that compiled without errors.
The Part Where I Admit CSS Isn't the Enemy
There's a particular kind of denial developers specialise in, and it usually starts with the phrase "design isn't really my thing." Said with a shrug, like it's a fixed trait, like handedness.
Is it not your thing, or have you just never taken it seriously?
Uncomfortable question. I sat with that one for longer than I'd like to admit. Somewhere around my fourth attempt at centring a div — genuinely, still, after all these years — I realised the frustration wasn't with CSS itself. It was with the assumption that visual thinking and logical thinking were somehow different departments, when really the best interfaces are just very well-argued logic wearing a nice outfit.
I've stopped fighting that now. Badly, but I've stopped.
What Actually Ships
Here's the bit nobody tells junior developers, and most senior ones have simply forgotten to say out loud: a website that's technically flawless and strategically empty doesn't help anyone. Clean code with no clear purpose is just an elaborate way of doing nothing very slowly. The sites that actually work — that convert, that get remembered, that don't need a redesign eighteen months later — are the ones where someone thought hard about the why before a single component got written.
That's not a criticism of code. Code is still the thing that makes any of it real. But it's the last step in a longer conversation, not the whole conversation by itself.
So, Why Was I Still Awake at 3am?
I still don't have a clean answer, and I've made peace with that the same way I've made peace with most things in this field — slowly, and with several false starts. But I closed the laptop that night having fixed nothing in the code, because there had genuinely been nothing broken there to begin with.
What I'd actually been debugging was the gap between what I built and what it was meant to do. And that's not a problem git blame can help you with.
So what are you actually building next, then?
I don't know yet. But for the first time in a while, I'm not planning to build all of it alone.
Tags: #webdev #programming #discuss #productivity
Top comments (0)