Springuptech
← Back to Insights

How We Built Our Company Website with AI — A Real Vibe-Coding Workflow and What Humans Still Must Do

We shipped the first version of our company website in a day with an AI coding tool and refined it over a week. Here is what AI did well, what needed human judgment, and the real bugs we found by testing.

Jaeyong RohPublished 4 min read

"Does coding with AI really make things faster?" It is the question we hear most. The answer is "Yes — but only when you know what to hand over and what to do yourself."

The Springuptech website you are reading was built together with an AI coding tool. We went from planning to a live deployment on day one, then spent a week refining it through real use. This article walks through that process step by step and is honest about what the AI missed and what a human caught.

What is vibe coding?

Vibe coding describes a way of building software where a person explains what they want in plain language and an AI writes the code. The human decides what and why; the AI quickly handles how.

The important point is that the AI is not accountable for the result. Code can look convincing, but whether it actually works, whether it misleads customers and whether it is secure must still be checked by a person.

Step 1. Turn a rambling request into clear requirements

It started with a very short note: "I want a company website, it should have dark and light modes, I want to show my experience, take inquiries by email, and use e-contracts."

Instead of asking the AI to write code right away, we first asked it to "explain back how you understood my intent." The AI summarized the requirements, proposed a menu structure and came back with questions that needed decisions:

  • Which tech stack and hosting?
  • Korean only, or English as well?
  • Integrate an external e-signature service, or build one?

This is the most important step. When requirements are vague, AI builds something plausible but wrong — very quickly.

Step 2. A decision only a human could make: how to present past work

One early idea was to list large companies as "partners". The lead engineer had worked on those projects as a subcontractor or freelancer, so calling them partners could imply a direct contract between companies.

We chose to list projects by end client and add a clear note about the engagement type, without using any logos. That is not a technical question; it is about trust and legal responsibility. AI can lay out the options, but a person must make the call.

Step 3. Implementation: where AI really shines

Once the structure was settled, implementation was remarkably fast. AI was especially good at:

  • Repetitive UI: service cards, project cards, process steps and other similar components
  • Bilingual copy: natural English versions based on the Korean text
  • Data structuring: turning 24 projects from a résumé into end client, period and tech stack
  • Configuration: dark mode, sitemap, robots.txt and link preview images

Repetitive work that would have taken days by hand was done in hours.

Step 4. Bugs we found only by actually testing

The AI's code passed the build and looked fine. But using it in a real browser like a customer would revealed problems.

① An inquiry form that erased what you typed In recent versions of React, a form is cleared automatically after submission. So when a customer mistyped a phone number and got an error, their carefully written project description disappeared too. Had we not deliberately triggered the error, a customer would have found it first.

② Country names rendered differently on server and browser In the phone country list, the server said "Hong Kong SAR China" while the browser said "Hong Kong", causing a rendering error that was only visible in the developer console.

③ A page that looked gray only on phones A mobile browser's "force dark mode" was painting the light theme gray. Declaring that the site supports its own dark mode (color-scheme) solved most cases.

All three would have slipped through if we had stopped at "the build succeeded."

Step 5. Improvements that came from real use

After launch, feedback from actually using the site turned out to be the most valuable:

  • "How many people really use mailto links?" → the email address became a click-to-copy button
  • "I want customers' phone numbers, and some may be overseas" → a phone field with a country selector
  • "The emails aren't arriving" → they were in the junk folder; sending-domain verification and DMARC improved deliverability

AI does not know where real users get frustrated. The judgment of the person using it is what finishes a product.

What to give AI, and what to keep

Good tasks for AI What a human must do
Repetitive code and UI Decide what to build and why
Translation drafts Review legal and ethical wording
Config files and documentation drafts Test real user flows
Analyzing errors and proposing fixes Make security calls on secrets and personal data
Comparing options Make the final choice and own it

Closing thoughts

AI has clearly changed the speed of development. But as speed goes up, verification matters even more. Turning something built quickly into something customers can trust is, we believe, the job of an experienced engineer.

That is how Springuptech works: build fast with AI, then verify carefully with 22 years of hands-on experience. If you have an idea, we would love to hear it.

AIVibe codingDevelopment processNext.js
J

Jaeyong Roh

Lead engineer at Springuptech · 22 years in software engineering

Have a project related to this topic?

Even if it is just an idea, we will help you work out what is possible.