Common Traps.
A field guide for what goes wrong when you're new to this. Bills you didn't expect, files you can't get back, sites that look broken in production but worked on your laptop. Here's how each trip-up happens and how to avoid it.
Every trap below is something I've either fallen into or watched someone else fall into. None of them are catastrophic if you catch them early. Most are small habits to build before they become problems.
Bills you didn't expect.
Cloudinary storage creeping toward the free tier limit
What happens: You upload every photo from a client's phone "to be safe" and forget about it. Three months later, an email arrives saying you've hit 25 GB and Cloudinary will start charging.
Fix:After every site launch, audit Cloudinary and delete unused assets. Keep only what's actually referenced in the site. See Chapter 06.
Netlify build minutes on the day before launch
What happens: Final review week. Client says "make this 2 pixels smaller, also fix this typo, and can we change one word." Each tiny request is its own commit and push. Each push is a Netlify build. By Friday you've burned through your free tier and Netlify is asking for $19.
Fix:Bundle small changes into single commits. Or better: keep the site on GitHub Pages until the client signs off, then move to Netlify only for the production launch. See Chapter 09.
Forgotten domain auto-renewal
What happens: A client's domain expires because nobody set auto-renew. The site goes dark. You scramble to recover before the registration grace period ends. Sometimes the domain is bought by a squatter and now costs $500 to recover.
Fix:Always set auto-renew on Porkbun (or whatever registrar). Use a credit card that doesn't expire soon. Add a calendar reminder a month before expiry as a backup.
API keys committed to GitHub
What happens: You're testing the Anthropic API and paste your key into a file. You commit and push. The key is now public on GitHub. Bots scrape new commits and start running your key against the API. Your bill goes up overnight.
Fix:Never put keys in code. Use environment variables. Add a .env file to your .gitignore. If a key leaks, rotate it immediately at the provider.
Code and design pitfalls.
Hardcoded colors instead of CSS variables
What happens: Claude sometimes uses raw hex codes scattered through 200 lines of CSS. Then the client says "actually, make our blue a little darker." Now you're search-and-replacing 47 instances and missing some.
Fix:Always set up CSS variables (:root { --blue: #0675BC; }) at the top of your stylesheet on the first prompt. Tell Claude "use CSS variables for all colors" and "don't introduce new colors without adding them as variables first."
Mobile never actually tested
What happens: You build the site on a 27-inch monitor, resize the browser narrow once, decide it looks fine. The client opens it on their iPhone and the buttons stretch to the screen edges, the headlines wrap weirdly, the hero image gets cropped to nothing.
Fix:Open the site on your actual phone before you call it done. Run a local web server (python3 -m http.server in the project folder), find your computer's IP, visit the IP from your phone on the same WiFi. Walk through every page.
Lorem ipsum that ships to production
What happens: You used Lorem Ipsum during the build because real copy wasn't ready. You forget to swap it. Six weeks later someone Googles the client's name and finds "Lorem ipsum dolor sit amet" on the live site.
Fix:Do a final pre-launch search across all files for "lorem", "ipsum", "TODO", "FIXME", "placeholder text," and the like. Chapter 07 has a pre-launch audit prompt that covers this.
Missing alt text on images
What happens: Every image gets alt="" by default. Screen readers skip them entirely, which is bad for accessibility. SEO also takes a hit.
Tell Claude up front: "every image needs descriptive alt text — what's in the image, not 'image of a thing.'" Run the pre-launch audit prompt to catch any that slipped through.
Hot-linking other people's images
What happens: You're prototyping and reference an image directly from another site's URL. You forget to swap it. Now your client's site is loading from a third-party host that could go down, change the image, or block you.
Fix:If you use a placeholder image, use placehold.co or picsum.photos — they're built for this. Never link to a random site's image. For real images, always download and re-upload to your own host (Cloudinary, GitHub, etc.).
Things that break between local and live.
Site looks fine on your laptop, blank in production
What happens: Most often: file paths. Locally you reference /assets/css/style.css with a leading slash; on GitHub Pages with a project subdirectory, that path is wrong. Browser console shows 404s for every asset.
Use relative paths (assets/css/style.css) instead of absolute paths (/assets/css/style.css) so the site works regardless of subdirectory. Open the browser's DevTools → Console after deploying to catch any 404s.
Browser caching makes you think your update didn't deploy
What happens: You push a fix, refresh the live site, and nothing changed. You panic and assume the deploy failed. It didn't — your browser is showing you a cached version.
Fix:Hard refresh: Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows. Or open the site in a private/incognito window. Or check the Netlify/GitHub Pages dashboard to confirm the new deploy actually went out.
DNS panic during a domain switch
What happens: You point a custom domain at the new site. It doesn't work after 5 minutes. You assume something's wrong. You start changing things. You make it worse.
Fix:DNS propagation can take anywhere from 10 minutes to several hours. Use dnschecker.org to see whether the new record is propagating globally. Wait at least an hour before assuming something's wrong.
Forms that don't actually submit anywhere
What happens: You build a contact form, the page looks great, you ship it. Nobody tells you submissions go nowhere because you never wired up a backend.
Fix:Static HTML can't process form submissions on its own. Use Netlify Forms (free up to 100 submissions/month, just add data-netlify="true" to your <form>), or Formspree, or wire up a Google Forms embed. Test the form by submitting it after launch. Get a notification, see the data land somewhere.
HubSpot, WordPress, and Squarespace cache aggressively
What happens: If you're publishing into a hosted CMS instead of GitHub Pages or Netlify, the platform's CDN may serve stale versions for hours after a deploy.
Fix:Most platforms have a "purge cache" or "republish" button. Use it after a meaningful update. Or wait — most caches expire within an hour.
You-versus-future-you problems.
"I want yesterday's version back"
What happens: You make a change you regret, save the file, can't undo. Or Claude rewrites a section and you preferred the old version.
Fix:This is what Git is for. Every commit is a snapshot you can roll back to. If you're using Claude Code, ask it: "show me what's changed since the last commit" or "revert these changes." If you're not, GitHub Desktop has a "Discard changes" button. Make sure your work is on GitHub before you start a major refactor.
No backup of client-provided assets
What happens: Client emails you logos and photos. You drop them into Cloudinary, build the site, finish the project. Six months later the client wants to redo something. The Cloudinary account is the only place those high-res files live, and you accidentally deleted half of them during cleanup.
Fix:Keep client-provided source files in a project folder on your local drive (or Google Drive). Never delete the originals from your local archive even if you remove them from Cloudinary.
Not testing the live site after deploy
What happens: You assume the production deploy works. The client emails two days later: "the donate button doesn't work."
Fix:After every meaningful deploy, open the live URL in a private window. Click every link. Submit forms. Open it on your phone. Five minutes of testing catches what hours of staring at code didn't.
Letting the look book or strategy doc go stale
What happens: Halfway through a build, the client decides on a new direction. You make the changes in the code. You don't update the strategy doc. Six weeks later you can't remember why a section is the way it is.
Fix:When the client changes direction in a meaningful way, update the strategy doc and the brand guide before you make the code change. Five minutes of doc work saves an hour of "wait, why did we do this?"
The trap that almost got us
During the ACF build, I had about 80 candidate images uploaded to Cloudinary while we were figuring out which ones to actually use. The free-tier dashboard started showing the storage bar approaching the limit. We pruned to about 25 final images the week of launch and Cloudinary usage dropped back to comfortable territory. If we'd let it sit, the next monthly cycle would have started racking up overage charges.
The lesson became a permanent habit: post-launch cleanup is its own checklist item, not "I'll get to it eventually."
What's next
You can build, publish, and avoid most of the traps. Last chapter is the bonus round: once you've done a few sites, you can build little AI-powered tools to make your own workflow faster.