We start every build on an empty file

A theme, an admin template, a boilerplate repo all hand you the same object. Several thousand lines of somebody else's answer to somebody else's brief. Most of it stays, because working out which part is load-bearing costs more than leaving it alone.

Coupling is what makes it stick. Class names and template references are strings, so no compiler and no bundler can prove a rule or a partial is dead. The only check is loading every page and looking. So deleting is a guess with a manual audit attached, and adding is not. That is why nobody gets a morning where the honest thing is to delete 400 lines.

Then the vendor ships a new major version. Kits know this, which is why they ship child themes, override layers and hooks. Those cover the changes the vendor anticipated. The change you need is nearly always the one nobody anticipated. Then you are reaching past the extension point into internals nobody promised to keep.

So the upgrade offers 2 options, both bad. Freeze and stop getting security fixes, or redo your work by hand against a codebase you never learned. Teams freeze, and the freeze is often still there when the rebuild gets quoted.

The quietest cost is the defaults. A kit has already decided how your fonts load, what your breakpoints are, and how much JavaScript the homepage ships. Nobody on your side chose that. Almost none of it gets audited, because it arrived working.

Fonts show the shape of it. Load 2 families at 4 weights each and that is 8 files. None can be requested until the browser has parsed the stylesheet naming them and matched an element using one. They are late as well as heavy. Say 20KB a face and that is a 160KB floor before a word of copy.

An empty file is not a claim that we write everything. We use a framework, a build tool, an image pipeline, a hosting platform, and a typeface licensed from someone who draws better than we do. Pretending otherwise would be a pose, and a slow one.

The line is about who owns the shape of the page. A framework owns routing, rendering and the build, at documented boundaries we can point at. A theme owns the markup, the class names and the visual defaults. It holds an opinion about what your page is, and you inherit it in every file you touch.

The case worth ruling on is neither. Take a copy-in component library, a set of headless primitives, a utility CSS framework. Each owns markup and visual defaults, which is the theme definition. Each also sits at a documented seam, which is the framework one.

Ownership after the copy settles it. Paste a component into your own repo and it is yours to edit and yours to maintain. That is an empty file with a head start. Install a package that renders markup you cannot see and the opinion stays with the vendor. You work around it instead of changing it.

So the test for any dependency has 3 parts. Name what it does, name what breaks when it goes, name what we would use instead. Fail any of the 3 and it was not chosen, it was accepted. The stack stays boring on purpose. Boring means every piece has an alternative we could swap in without redrawing the site.

Often enough that we say so out loud. If the brief is a shop with checkout, tax rules, discount codes and shipping bands, the honest answer is Shopify and a restrained theme. Those problems are solved, a vendor is paid to keep them solved, and rebuilding them spends a client's money on covered ground.

The same goes for anything with a short life. A conference site up for 6 weeks, an internal tool 12 people use, a page testing an idea nobody knows has an audience. Ship those on whatever is fastest and bin them on schedule. Starting from nothing pays back over years, and some things do not get years.

The case that matters most is who holds the code next. An empty-file build assumes somebody can read it. If a client has no developer and no plan to get one, a platform with a large hiring pool is the more responsible pick. That holds even when the result is heavier than we would draw. Being able to hire the next person beats the elegance of the current thing.

Starting empty is only defensible if you carry the parts of the kit worth having. Otherwise you have swapped somebody else's mediocre answer for your own, and yours is newer and less tested. 4 things have to exist before the first file does.

• Patterns the studio owns and has run in production: navigation, forms, focus handling, keyboard behaviour, error states.
• A performance budget in numerals before the design starts. Say 200KB of JavaScript on the homepage, written where the designer sees it.
• A recorded reason next to every dependency, with the name of whoever added it.
• A handover where someone who did not build it clones the repo and runs it from the README.

Accessibility deserves the pointed version. A widely used theme has had its menu tried with a keyboard by everyone who shipped it. That means the bugs are known, not that they are fixed. The kit buys you a bug tracker, not a working menu.

So you inherit the obligation either way. Tab order, visible focus, Escape closing the menu, form errors announced to a screen reader and not just coloured red. Skip that work and starting empty is a preference dressed up as a principle.

The payoff shows up the day someone asks you to take something away. On a build that started empty, remove means delete. The component goes, the route goes, the styles go with it, and nothing else on the site moves.

On an inherited build, remove nearly always means hide. The markup still renders, the CSS still ships, the handler still binds, and the only change is that nobody can see it. Do that 6 times across 2 years and every visitor pays full price for a site that shows less than it carries.