13 Days with an AI Builder: How We Rebuilt Our Landing Page and App in One Go

What I learned building Laplace V4: hand over what you know, get answers as pictures, and stay skeptical to the end

Eugene · October 30, 2026

Hi, I'm Eugene, and I build product at Laplace.

At 6:27 p.m. on October 29, a single PR was merged into our app repository. It was called Laplace V4, and it touched 4,116 files. With that one PR, every screen of Laplace Analytics and our landing page got a new look. The product now supports five languages, and it finally renders properly on phones, where it used to be practically unusable. It took 13 days, and one person built it: me.

To be honest, I wasn't confident when I started. I don't have deep engineering knowledge, and I wondered whether it was really possible to rebuild an entire product with vibe coding alone. But by the end, what made the difference wasn't engineering knowledge. The experience I'd built up moving between design, PM, CS, and sales turned out to be my most reliable asset for working with AI.

I felt it every time I wrote a prompt. I knew why UI and UX have to be designed differently for an analytics product, and which features and charts we needed was already in my head from customer inquiries and meetings. That context was exactly what the AI needed.

For a long time I dreamed of being a specialist who goes deep in one field. In reality, I've been closer to a generalist who covers a lot of ground. Working with AI, that breadth became a real strength for the first time. In this post, I'll walk through what I built in those 13 days, and how.

First, what changed?

Pictures will be faster than words. Every image below was captured at the same width from a local app loaded with the same fake data. On the left is the previous UI (the ui-classic branch); on the right is V4 as deployed today.

The biggest change was on phones. The previous app had no mobile layout at all. The desktop UI simply shrank, so the menu covered most of the screen and settings titles wrapped one character per line.

Then there's language. In the previous app, switching the display language to Japanese gave you a mix of English and Korean, and the menu showed raw translation keys like group.strategy.

We changed the landing page the same way. The landing work actually started a little before V4, in early October, by auditing our Framer site and moving it to code. The audit found that the hero mockup was a "2024 Black Friday Performance Report" and the chart legend still read series-1. And on phones, there was no product screen at all.

During V4, we added Japanese, Simplified Chinese, and Traditional Chinese versions of the landing page. Visitors are sent to the right version based on their browser language, and overseas versions show prices in US dollars. The automatic language redirect is covered by a regression test that opens the built HTML in 18 different scenarios.

If the landing page says "we support five languages" while the app is Korean-only, overseas customers are disappointed the moment they sign up. That's why I treated the two as one bundle.

1. It started with handing over everything I knew

AI doesn't know commerce. More precisely, it doesn't know what our customers look at first or what frustrates them. So for the first few days, I mostly just explained.

• The numbers commerce CEOs check first thing in the morning (yesterday's sales, progress against target, revenue relative to ad spend)

• Things I'd heard from customers: "The numbers can't move from where they were on the old dashboard," "Tables stutter when I scroll sideways," "Region names overflow their cells on the map"

• Features and UI I'd wanted on the old screens but had to give up because they couldn't be built, and why

• How we look at data: dates and times are always in Korea time, the year is never dropped even for dates in the current year, and by default no table columns are pinned

• Usability rules that must hold: text never smaller than 11px, tap targets on phones at least 44px, and no native system dropdowns

• On mobile screens that never existed before, what to keep and what to collapse

If you say something once and move on, it's forgotten in the next conversation. So I turned the rules into documents and skills. Rules like "Chart cards don't get headlines" and "Card heights are stored in 160px units so they stay compatible with the old screens" were attached automatically to every new task instruction. Getting to a state where I didn't have to explain everything again each time was the first job.

2. Instead of building everything at once, I asked for pictures

At first I wanted to say, "Just build all of it." But that gives you results that are wide and shallow. So I changed the order.

When I had a screen in mind, I'd describe it in words first and ask the AI for two or three drafts. The drafts were drawn inside the real app running locally. That way they look like the actual product, and I could immediately check how they looked at phone and desktop widths.

Whenever a decision came up, I asked for before-and-after pictures instead of text. So much was changing that I couldn't judge what was different from a written report alone. I said "I can't tell what's different, give me a picture" so often that it eventually became a working rule.

Once one screen was done, things sped up. The settings screens share the same spec and flow, so once the header, left menu, right-hand help panel, and save bar were defined on the "My profile" screen, the rest just followed that spec one by one.

3. Quite often, the AI's suggestions beat my own ideas

Honestly, this was the most surprising part. When I was figuring out how to show Custom Dashboard to customers who hadn't connected any data, I was picturing "one sample screen." The AI proposed drawing eight industry case boards with real chart components and putting "Want to see this with your own data? Connect your data" on top. As you browse boards like inventory management, tax and P&L, repurchase product analysis, cross-selling, and CRM, you start thinking, "We want to do this too." That was exactly what I wanted.

But I always had to check. The AI didn't reliably catch things on its own, like popping a large notice in the middle of the screen, a board looking sparse because it had too few cards, or a table with an empty right side. Calls that need judgment, like keeping real customer names out of the examples, also had to be made by a person.

The advanced filter was the same story. The AI's first proposal attached a condition dropdown to every value chip, and a single "or" between chips switched how all the conditions were joined at once. It looked plausible on screen, but you couldn't mix or group conditions. I threw that out and switched to stacking rules one line at a time, like Notion's advanced filter. Even when the AI said "Done," it wasn't done until I had clicked through the screen myself.

4. I treated the design system as a reference only

There was one rule I set on purpose for this project: I used the existing design system only as a reference, and didn't follow it strictly from the start.

If you stick to a design system from the beginning, you only think inside the system. You only imagine screens you can build with the parts you already have, and the screens customers actually need often aren't in the system. So at the draft stage I thought broadly, but reused the color and spacing tokens and shared components to keep things consistent.

Then, after the design was done and before rollout began, I swapped the existing design system for the current version. That's why 151 files in the design system package changed in the integration PR. Instead of the system holding the design back, the finished design rewrote the system.

After the swap, I combed through every screen looking for "separate components that do the same job." For example, a dialog that's a centered modal on desktop and a bottom sheet on phones was used in 34 files, and there were four more similar dialogs. Lists like this became the starting point for the next round of design system work.

5. When usability calls got hard, I borrowed from others right away

Questions like "Is this the right place for this button?", "What should we call this status badge?", or "Should we show a notice to people coming in on Internet Explorer?" are endless if you agonize over them alone. In those moments, I asked the AI to find out how other services handle it and what people in the community say, then had that approach applied to the local screen right away and sent back as a picture.

It was much faster than researching and comparing on my own. I still make the call, but the material for it shows up on screen within minutes. Reading ten search result links and looking at two pictures of our own screen with the approach applied side by side lead to completely different decision speeds.

6. For work that needed experts, I brought in experts

For work that needs specialized knowledge, like chart visualization, performance measurement, and translation review, I downloaded and plugged in skills and agents for that field. And I ran many things at once. Date formats, badge copy, card heights, and the map replacement each went to a different subagent, and my role was to look at the pictures that came back and choose.

Table scrolling. "Tables stutter when I scroll sideways" was long-standing homework. Instead of fixing it by feel, I measured all 27 tables in the app with the CPU throttled 4x and tracked down the cause. After the fix, long tasks over 50ms dropped from 119 to 14, and script execution time was cut in half. This fix is a PR posted the day after launch, so it's still in review.

Translation. We don't have native Japanese or Chinese speakers on the team, so we reviewed translations with AI. Each string's source and translation were placed side by side, and the translation was back-translated into Korean to compare meaning. We reviewed 711 connection guide strings this way and fixed 93. What mostly got caught were translations that were grammatically fine but meant something different, like "You can log in once you set it up" reading differently from the intended "You can't log in unless you set it up."

Pre-launch checks. Finally, we opened 119 screens in five languages at eight widths and had machines find overlaps, clipping, leftover Korean, and tap targets that were too small; people only looked at what got flagged. We also ran Safari, Firefox, iPhone, iPad, and Android device settings separately, plus a Windows environment without the Pretendard font. When we reran everything after the merge, there were zero new critical issues.

That said, running too much at once was more than my laptop could take. After several browser-launching agents running tests at the same time all froze together, I added a rule to the instructions: heavy jobs run one at a time, with only one browser open.

7. We still had an incident

Not everything went well. Once, I pointed an automated browser at a preview URL that used production data, and within 3 minutes it had sent about 18,000 authentication-failure (401) requests to the production API. The browser wasn't logged in, and the app retried every time authentication failed.

After that, I put rules in place. Automation runs only against a local app where authentication and the API are both faked, and every request from the browser that leaves 127.0.0.1 is blocked from the start. All app screenshots in this post were taken from that local app. This rule is also written into the skill documents, so it's attached automatically to every subagent instruction.

AI does what you tell it, fast. That's why deciding what it must not be told to do is the human's job.

How did we ship it?

Each area got its own PR and review, and at the end everything was combined into one integration PR. Starting with settings, menus, and Custom Dashboard, we layered on multilingual support, data connection, data management, and the standard dashboards in turn; the combined list came to 25 lines, and 820 commits piled up in the PR. Of the 4,116 changed files, 1,333 are test files.

We shipped it all at once but left a way back. With the "New screens" switch in the app bar, anyone can move between the new and old screens. It's there so customers don't lose the screens they're used to overnight. Thanks to this switch, I could capture the old screens and V4 side by side with the same fake data to make the comparison images in this post.

Looking back on 13 days

What changed most was how much time I spent agonizing. Before, I'd hold on to "Is this right?" by myself for a long time; this time, I looked at a few drafts and picked one. In exchange, my eye for choosing and how well I knew our customers decided almost everything about the result.

For anyone who wants to try working this way, I'd like to share three things.

One, organize the knowledge you'll hand over first. The quality of the screens the AI built was almost proportional to how much customer context I gave it. If you write down customer feedback, features you gave up on, and the numbers your industry cares about, the AI reads them every time before it starts.

Two, decide with pictures, not text. Once you're past a few dozen screens, written reports aren't enough to make calls. A single before-and-after picture of the same screen replaced an entire meeting.

Three, don't trust "Done." The AI's suggestions were often better than I expected, but tapping through at phone width, switching to another language, and checking that no real customer names had slipped in remained my job to the very end. So did deciding what it must not be told to do.

What's next

I think AI will soon take on a large part of building products. Good features will reach the world at a speed we can't compare to today. If so, we need to rethink how we work and how organizations are structured. I'm not sure the lines dividing roles like designer, planner, and developer need to stay as rigid as they are now.

Still, I see this change as more of an opportunity than a threat. Ideas that lived only in my head and plans that existed only on paper can now be built right away and put in front of customers to validate.

Beyond data analytics, Laplace is now preparing automated planning. Our goal is to ship it within this year. A global version of the app is also about to launch. Please keep an eye on Laplace's next journey, beyond data infrastructure.

---

All app screens in this post were captured from a local app with fake data, and every brand name, figure, and email address on screen is a sample. Sources for the numbers: app repository git history (PR #4984, merged 2026-10-29), landing repository git history, pre-launch check report (plan/v4_qa/sweep.md), table performance measurements (.local/hscroll/agg_all4.md), and translation review log (plan/i18n_ai_review.md).