Process at ViewPrice Studio
From wireframe to launch and handover
A web project goes wrong in predictable places: unclear scope at the start, content arriving late, and no plan for who keeps the site in shape afterward. This is the order we follow so those points stay under control.
Timelines vary with project size. The order rarely does.
Why the sequence matters more than the speed
Most delays we see in South Korea come from the same three gaps. The brief leaves the goal vague, so structure drifts. Text and images arrive after design is done, so layouts are rebuilt around late content. And nobody agrees who updates plugins, backups, and pages after launch, so a good site slowly goes stale.
This page walks through our website project steps from first brief to handover. You can stop between phases, ask questions at each checkpoint, and keep everything your team needs to run the site without us if you prefer. If you want the service view first, see what is included alongside each step.
How to use this guide
Start at the brief. If scope is clear, every later decision gets faster, from sitemap to launch checklist.
We design phone-first. Most first visits in Korea happen on a phone, so wireframes and prototypes are checked there first.
End with ownership. Hosting logins, editing rights, and backup routine are written down before we close the project.
Scope and brief
A short written brief saves weeks. We keep it practical and costed by phase.
What we ask
Everything starts with a written brief. We ask about your current site, your host, your internal editing team, and your deadline. We also ask what the site needs to achieve in the next year, because that shapes structure more than current page count does.
For shops and service firms that means one honest question: which enquiry, booking, or sale should grow? The answer decides navigation, homepage order, and which pages we keep.
What you receive
The output is a scoped estimate broken into phases, so you can see what each one costs and stop between them if needed. No bundled mystery fee. If content writing or a shop setup can wait, it sits as a separate line.
Phased scope with page list, integrations, and content responsibilities.
Hosting and domain notes, so launch day has no missing logins.
A rule we keep
Structure first, decoration later.
Feedback on a wireframe costs minutes. Feedback after visual design and code costs days. That is why sitemap and wireframe come before color and type.
Old pages sorted by traffic and purpose before anything is drawn.
Content inventory and structure
Before design, we look at what content exists and what needs writing. Old pages get sorted by traffic and purpose; some are migrated, some archived. From there we build a sitemap and a rough page outline.
This step catches the common problem where a redesign launches with the same structural issues as the old site, just with better spacing. If three service pages compete for one search, we merge them. If a contact page hides the phone number, we move it up. Korean and English versions are mapped page by page so nothing launches untranslated by accident.
Wireframes
Wireframes are low-detail layouts that settle structure before visual design. We start at phone width, since that is where most first visits happen in Korea, then expand to tablet and desktop. Each wireframe shows what content goes where and what the primary action is on that page.
You review boxes and order, not colors. Is the call button visible without scrolling? Does a shop page answer price, delivery, and return in one screen? Feedback at this stage is cheap. Feedback after visual design is not.
Prototype and design
Once the structure holds, we move into visual design and a clickable prototype. In Figma, the work becomes components and variants rather than static screens, so changes propagate.
Dark mode, form states, and error messages get designed here rather than improvised during development. Buttons, inputs, and product cards share spacing and color tokens. If the project needs a design system, this is where it takes shape — a small library your team can reuse instead of redrawing each page.
You click through the prototype on your own phone. That walkthrough from wireframe to prototype is the moment most issues surface, while they are still easy to fix.
Build
Front-end build
We build the templates and reusable blocks in code. Front-end styling often uses Tailwind CSS, first released in 2017, which applies utility-first styling instead of prebuilt component libraries.
That approach suits teams who want consistent spacing and color across pages without fighting an opinionated theme. Where a CMS is involved, we connect the templates to editable fields so your team can update content without touching markup. Speed work runs alongside: image sizes, font loading, and mobile layout are checked as we build, not patched at the end.
Ownership
CMS configuration and content loading
This is where the site becomes yours. We configure the editing interface, user roles, and any multilingual setup. Content gets loaded, either by us or by your team with our structure as a guide.
Permissions are set so that the people who edit content cannot accidentally change settings they do not understand. It is a small thing that prevents a lot of support requests.
Editor roles limited to pages, products, and blog.
Korean and English fields kept in parallel.
Image sizes preset so uploads stay fast.
Pre-launch checklist
Before anything goes live, we work through a checklist: redirects from old URLs, form delivery tested to a real inbox, analytics and tracking verified, performance budget checked, and metadata filled in.
We also test on actual phones rather than only in a browser responsive view. Launch day has enough surprises without skipping this step.
Old links keep working
Every old URL maps to its replacement. We open redirects by hand and confirm none land on a missing page.
Forms reach a real inbox
Each form is sent to the address you will actually read, including file uploads and error messages.
Speed on mobile data
Homepage and key templates are checked on a phone with throttled data, with heavy images compressed before launch.
Search and sharing ready
Titles, descriptions, and preview images are filled in so search results and chat shares read cleanly from day one.
Launch
We deploy to your hosting, switch DNS if needed, and monitor the first days for errors and slow pages. If there are redirects from an old site, we verify they resolve rather than landing on a 404.
Search console and analytics get a first look so problems surface early. You get a short summary of what was deployed and where things live — hosting, domain, backups, and admin access in one note.
Handover and training
Handover includes documentation covering your host, plugins, backup routine, and the parts of the site that are safe to edit. We run a short training session with the person who will actually maintain the site, not just the project sponsor.
If you prefer to keep maintenance in-house, this is where that becomes realistic. If you would rather we handle it, support arrangements are separate and quoted on their own.
After launch
The weeks after launch usually reveal small adjustments: a form field that confuses people, a page that gets more traffic than expected, a heading that reads wrong in Korean. We plan a review window so these get handled together.
Longer-term improvements, including conversion work, run on their own schedule once the site has enough traffic to learn from.
See tools we build with
Bring a brief. Leave with a site your team can run.
Tell us about your pages, host, and deadline. We will map the steps, cost each phase, and agree who handles content and maintenance. Write to [email protected] or call (219) 747-6137, Monday to Friday 9:00 AM to 6:00 PM.
Prefer reading first? Read answers about timing and handover.