Dev terms for client work

A job title that exists only in the Korean web industry. Elsewhere front-end developers do it as part of their work. When reading an agency quote, check whether this is separate or bundled with front-end — miss it and you have designs but no screens.

"The button does not work" is front-end; "it will not save" is usually back-end. Saying which side it is gets you a much faster response. When unsure, describing exactly what you saw on screen is the best option.

"We cannot wire it up until the API is ready" means real data cannot be connected to the screens until back-end work finishes. So the API schedule determines the front-end schedule. Confirm that dependency when agreeing timelines.

"Is the admin panel included?" changes a quote by roughly double. A project with 20 user-facing screens needs 15 to 20 admin screens too. This is the number one thing to confirm before signing.

An About page is static; a product list is dynamic. Dynamic pages need a server and a database, so cost and schedule differ. If the "simple website" has log-in and a message board, it is dynamic.

Transitions are smooth, but the first load can be slow and search visibility (SEO) can suffer. If marketing matters to the product, discuss this with development in advance.

"It is live" means real users can see it. Always review on staging and promote only what has been signed off. Also check that the staging address is blocked from search engines.

"I fixed it" and "I deployed it" are different. If the code is changed but not yet on the server, users still see the old version. When reviewing, ask "has it been deployed?" first.

Leave QA out of the schedule and the launch date slips. Allow around 15–20% of the overall schedule. And QA only means something when done by a third party, not the developer — people cannot see their own mistakes.

Fix requests sent over chat get lost, without exception. Registering an issue leaves an owner, a status and a deadline. A good issue records all three of ① which screen ② what you did ③ what differed from what you expected.

The reference document when a scope dispute arises. The moment someone says "obviously that is included", this is what gets opened. Without it, the side asking always wins. Leave out vague phrasing ("make it easy to use") and write verifiable statements.

The single biggest risk on agency projects. Ten rounds of "just one more thing" and the project collapses. This does not mean refuse — it means state every time that "yes, and it adds three days and a cost". Put it in writing and most of them resolve themselves.

Dependencies cause most schedule slips. You cannot simply add "3 days design, 5 days development". One day late at the front puts everything behind it one day late. Mark predecessors on the schedule.

"Send me the resources" means export and send the images. Send only a Figma link and the developer has to cut them out, and sizes and padding shift in the process. Sort out SVG, @2x/@3x and transparency, and hand over a folder.

Developers can now read values straight from Figma, so a separate spec document is often skipped. But information the tool cannot show — "what does this do at other widths?" — still has to be written down.

A native app means building two of them, for iOS and Android, passing app store review, and going through review again on every update. Web takes effect the moment it is deployed. "And an app as well" is effectively a second project.