For a backend developer, "deployment" usually means setting up a server. Spinning up an EC2 instance, running Docker containers, configuring nginx — that was deployment to me. But building Q-Fit was my first time trying static hosting. And there were quite a few things that only became visible after deployment.
Where to Deploy: I Explained My Situation to Gemini
At first I thought I'd just rent a server and put it there. I figured I'd use AWS, but when I mentioned it to Gemini, it said static sites can be deployed without a server at all. The build just produces HTML, CSS, and JS files, so you can simply upload them to a CDN. That was also the first time I learned that there's almost no cost since you don't need a server running 24/7.
It also gave me a few options: Vercel, Netlify, Cloudflare Pages. At first it recommended Vercel for its convenience. But when I explained that Q-Fit had commercial purposes and might get some traffic, it flagged issues with Vercel's free plan — commercial use restrictions and bandwidth limits. It then suggested Cloudflare Pages as an alternative: no commercial use restrictions and no bandwidth limits on the free plan. So I went with Cloudflare Pages.
First Deployment: I Couldn't Find the Pages Menu
When I got into the Cloudflare dashboard, there were a lot of menus. Workers, R2, D1, KV — all sorts of names lined up. But I couldn't find Pages for quite a while. Was it inside Workers, or was it somewhere separate? I ended up taking a screenshot and sending it to Gemini asking, "Where do I click for Pages on this screen?"
Gemini looked at the screen and told me where to click. It also walked me through every value I needed to enter — build command, output directory. I didn't fully understand why I was entering each thing, but I just put in what it said. And the first deployment worked. It was easier than I expected.
Images Were Loading Way Too Slowly
After deployment I opened the site, and image loading was noticeably slow. I had just dropped PNG files straight into the public folder, and they were pretty large. On local it loaded instantly so I hadn't noticed, but in the actual deployed environment the difference was clear. Test result images were especially obvious.
I told Gemini and it said to convert to WebP. Same image, but the file size is much smaller than PNG. It also wrote the conversion code. After switching all the images to WebP, the perceived loading speed was noticeably different. That was my first time actually feeling what image optimization means. Developing only on local and then touching a deployed environment for the first time — that's when things like this become visible.
Sharing to KakaoTalk Always Went to the Main Page
After deployment, I tried sharing a specific psychology test link on KakaoTalk. But clicking the link always took you to the main page — not the test I was trying to share, just the home page. I asked Gemini why, and it said the routing wasn't set up so that the URL changes per page.
Gemini handled the routing, and in the process the SPA-specific refresh 404 issue got resolved too. Because SPAs render pages on the client side, directly accessing a specific URL or refreshing would cause the server to not recognize the path and return a 404. There was a way to handle this in a static hosting environment, so we applied it together. I knew what an SPA was, but I didn't know this kind of problem could arise with static deployment until I experienced it firsthand.
The KakaoTalk Share Preview Showed Nothing
After fixing the routing issue, I tried sharing on KakaoTalk again. This time clicking the link properly navigated to the right test page. But when sharing, there was no preview. Other service links would show a title and image, but Q-Fit links just showed the bare URL.
I asked Gemini why, and it said it was because there were no OG tags. It explained that Open Graph tags are meta information you embed in the HTML so that preview images, titles, and descriptions appear when you share a link. It also said each page needed to dynamically generate OG tags, and since it's a static site, prerendering was necessary too. That was also my first proper introduction to SEO — how search engines recognize pages, what meta information content needs. Deployment was how I naturally came to feel why SEO matters.
Accessing a Nonexistent URL Broke the Page
One day I found that accessing a nonexistent URL just broke the page. Either a completely white screen, or a layout that looked half-collapsed. I hadn't created a 404 page. With server-based deployment I had handled 404s in the nginx config, but with static deployment there was nothing like that — so it just showed a blank screen.
Solved it by making a 404 page. For incorrect URLs, I added a message saying "Page not found" and a button to return to the main page. Gemini told me that Cloudflare Pages handles it automatically if you put a `404.html` file in the root. A simple fix, but again something I hadn't thought about until I ran into it.
Things That Only Become Visible After Deployment
Looking back, all of these problems were difficult to discover on local. Images load fast on local, you can't test KakaoTalk sharing before deployment, OG tag previews only work with a real URL, and 404 handling only surfaces once you actually navigate to a wrong URL. Everything was something I only learned after deploying.
When building APIs on the backend, I could reproduce most things locally. But static frontend deployment was different. There were aspects where "the environment users actually use" differed considerably from local, and those differences surfaced as problems. I learned that deploying without a server isn't simply "upload and done" — there are things specific to that environment you need to pay attention to.
Closing Thoughts
Static deployment definitely has a lower barrier to entry than server deployment. Less configuration, almost no cost, and solid automation. But "no server" didn't mean "nothing to worry about." There were issues that only surfaced in the deployment environment, and by running into each one, I gradually came to understand how static deployment actually works. Going through frontend deployment for the first time as someone who had only done backend, I learned quite a bit. Next time I do a similar project, I think I'll fumble around a lot less.