I Didn’t Build It All at Once
Why I split requirements → mockups → wireframes → code — and what it saved me
When building Hansaiam, I never asked for code on the first request.
That wasn’t a plan I came in with — it was something I learned the hard way on my previous project, trading_mvp. There, I ended up doing the UI work twice. Built everything first, then had to revise it all after the fact. The cost of fixing things after they’re built is roughly double. It was painful. I didn’t want to repeat that with Hansaiam.
So from the start, I broke the work into stages.
Here’s how it actually went.
First: requirements. I wrote down the direction (“feels like walking into an exhibition”), the constraint (my mom needs to be able to upload pieces herself), and the structure (three halls — calligraphy, folk painting, lettering). That document came first. No code yet.
Then: mockups. Instead of “build this,” I asked for “show me six homepage concepts.” Looked at all six, picked one. Then fleshed out the main screens — gallery grid, artwork detail, exhibition hall page. Only after all of that did I ask for working code.
The actual development revisions were minimal. I’d initially scoped the admin panel to just artwork management, but once my mom started using it, she wanted to manage her career history and other sections herself too. So we added and adjusted some admin features — but that was expanding scope, not fixing a wrong direction. The site was simple enough that those changes were small. Nothing like the structural overhauls trading_mvp required.
The reason I paused between stages: if the earlier stage is wrong, everything downstream breaks.
If you write code before seeing a mockup, fixing something that looks off costs you code revision time on top of design revision time. Catching “this direction isn’t right” at the mockup stage means the code gets written once, in an already-confirmed direction. You’re building in human checkpoints.
The commit log tells the real story:
Jun 03 Initial Next.js build — public site + admin CMS
Jun 04 Add guestbook management
Jun 05 Update artist bio section (mom's feedback)
Jun 06 Remove lecture/exhibition inquiry cards
Jun 08 Production deploy
Jun 13 Add Korean/English toggle (263 fields translated, deployed)See Jun 05: “mom’s feedback.” That only stays small because I’d staged the work. Feedback after everything is built means rework. Feedback mid-process, with direction already aligned, means a one-line fix.
I plan to apply this to backend work on the next project too.
Hansaiam was frontend-heavy, so the staged approach felt natural. But it applies to backend just as well. Instead of designing the full API then implementing it, you can review the data model first, confirm it, then review the API list, confirm it, then write the code. Human checkpoints at every stage eliminate the cost of rebuilding.
I learned this cheaply at Hansaiam. I learned it expensively at trading_mvp.