Why we still hand-code more than clients expect in 2020

Clients sometimes ask, reasonably, why a project still requires meaningful hand-coding when so many tools now promise to automate large parts of web development. Automated and low-code tools have genuinely improved, and we use plenty of them ourselves where they make sense. They still haven't replaced the judgment a real, considered build requires, and pretending otherwise would be dishonest about where the actual limits currently sit.

We're not resistant to these tools out of stubbornness or nostalgia for how things used to be done. We use automation constantly, for anything mechanical and repetitive, and we still hand-code the parts that genuinely require a real decision about tradeoffs specific to the actual project in front of us.

Standard layout patterns, common content structures, routine responsive behavior: these are well-solved problems, and using an established tool or component library for them is simply more efficient than writing custom code from scratch every single time. We reach for these tools constantly and see no benefit whatsoever in reinventing well-solved, thoroughly tested problems from first principles.

This is where the majority of genuine productivity gains from modern tooling actually show up in a typical project, and we take full advantage of them wherever the underlying problem is genuinely standard and doesn't require anything unusual specific to this particular client's situation.

Custom interactions specific to a client's actual product, unusual layout requirements that don't map cleanly onto a standard component, performance optimization that requires understanding exactly what's happening at a low level rather than accepting a generic tool's reasonable but generic default behavior. These require real judgment, weighing specific tradeoffs unique to this project, not a templated pattern applied uniformly regardless of context.

We've inherited sites built entirely through automated tools that hit a hard wall the moment a client needed something genuinely custom, a specific interaction, an unusual layout requirement, a particular performance target, that the tool simply wasn't built to accommodate gracefully at all.

Automated and low-code tools generally optimize for broad applicability across many different use cases, which means they carry code and functionality that any specific individual site doesn't actually need. This general-purpose overhead adds up, and it's one of the more common causes of slow-loading sites we find during performance audits across different clients and different tools.

Hand-coding lets us include exactly what a specific site needs and nothing more, which consistently produces meaningfully better real-world performance than a general-purpose tool's reasonable, broadly applicable default, even when that default is genuinely well engineered for the average use case it was designed around.

A site built entirely through a proprietary automated tool is often locked into that specific tool's ecosystem indefinitely, making future changes dependent on that tool's continued existence, continued quality, and continued pricing decisions, none of which a client actually controls. Hand-coded, well-structured code is more portable and more maintainable over the genuinely long run, by any competent developer, not just specialists in one particular proprietary tool.

We weigh this tradeoff explicitly with every client: faster initial build speed against long-term flexibility and true platform independence. For projects with a genuinely long expected lifespan, we usually recommend leaning toward more hand-coded, less tool-locked structure, even at some real cost to how quickly the very first version ships.

We map specific requirements against what available tools can genuinely handle well, and we hand-code specifically where a tool would force an unwanted compromise on performance, on flexibility, or on genuine long-term maintainability. This isn't a fixed, ideological rule against automation. It's a case-by-case judgment call, made honestly for each specific project rather than applied uniformly regardless of context.

We explain this reasoning to clients directly, with specific examples relevant to their own particular project, rather than asking them to simply trust a vague, unexplained preference for hand-coding that we haven't actually justified with reasoning specific to their situation.

Hand-coding genuinely takes more time upfront than assembling a site from pre-built components, and we're honest about that real tradeoff with every client from the very start of a project. We frame it clearly as an investment in long-term quality and flexibility, not as a mysterious, unexplained added cost that a client simply has to accept without understanding why.

For projects where speed to launch genuinely matters more than long-term flexibility, a short-term marketing campaign, a quick test of a specific idea, we readily recommend leaning much more heavily on available tools instead, since the tradeoff clearly favors speed in that specific situation.

On a recent project, an available component library handled ninety percent of a client's site well, and the remaining ten percent, a genuinely unusual interactive comparison tool central to the actual product, would have required awkward, fragile workarounds to force into that same library's existing patterns, workarounds that would have made every future change to that specific feature slower and riskier than it needed to be. We hand-coded that specific piece, kept the library for everything else, and the result performed better and was easier to maintain than forcing the whole site into one single approach.

This kind of mixed approach is typical of how most of our real projects actually get built, and it's a more honest, more accurate picture of the work than either "we use modern no-code tools" or "we hand-code everything" would suggest on its own, as a simplified marketing description.

Modern tools have gotten genuinely good, and using them well, for the problems they're actually well suited to solving, is smart, efficient work, not a compromise of any kind.

Hand-coding hasn't become obsolete because the judgment it requires, weighing tradeoffs specific to an actual project in front of us, hasn't been meaningfully automated yet, no matter how sophisticated these tools have become in other, more standardized respects.

We use both, deliberately and honestly, deciding project by project rather than defaulting reflexively to either extreme regardless of what a specific situation actually calls for, or what happens to be trendiest in the industry that particular year, or what would be easiest for us to sell in a pitch deck.