Why a Web Service Took Four Days to Build
What AI Removed
AI Reduced Cross-Functional Coordination Costs
Using AI and Codex, I built a price-comparison web service in about four working days. It includes a product catalog, prices fetched from Rakuten and Yahoo! Shopping, and checks that match products against their attributes. It also has price history, search, product pages, buying guides, automated tests, and a deployment workflow. This was not a simple one-page website, yet it took shape quickly. Explaining that only as “AI wrote the code” misses the point. The largest reductions were in explanations, waiting, handoffs, and alignment that would normally happen between different roles.
The Data Must Connect Correctly, Not Just the Screens
The live site includes more than product listings: a product catalog, search filters, price retrieval, product matching, price history, aggregation, articles, and mobile layouts. Products with similar names must remain distinct when their language, product type, or unit of sale differs. Out-of-stock and unavailable-price states also need to be handled separately. The data must connect correctly, not just the screens. It is closer to a combination of a small web application and a media site than a static homepage.
Time Is Spent Explaining, Not Only Doing the Work
In a typical outsourced project, planning, requirements, UI design, frontend development, data processing, testing, content production, and deployment management are divided among different people. Specialization has advantages, but information has to pass between roles. The intent behind a plan becomes a specification; the design must be explained to the implementer; the result is reviewed; and the reasons for revisions have to be explained again. Time is spent not only doing the work, but also helping others understand what to do.
The Person Who Spots a Problem Can Request a Fix Immediately
When one person develops with AI, the person who notices something wrong can request a fix on the spot. There is no need to schedule a meeting, create a ticket, or wait for an estimate. They can review the revised screen and request another change, repeating this cycle many times a day. AI removed not only coding time, but also the wait for the next person to start.
A Product Vision Can Be Reflected Through Short Iterations
In this project, one person made decisions about the goal, priorities, UI issues, product criteria, and whether the result was ready to launch. There was no need to repeatedly explain why something was necessary between a client and an implementer. I could turn the product I had in mind into revisions through short exchanges with AI. Removing meetings between roles had a major effect on delivery speed.
Humans Still Decide What Goes In and What Comes Out
Using the same AI does not mean everyone can build the same thing in the same number of days. Someone still has to decide what to build, notice inconsistencies in product data, describe usability problems, stop a workflow that violates a service’s terms, and inspect the actual result rather than simply trust a completion report. AI can fill in intermediate steps, but people still decide what goes in and what comes out. Basic knowledge and quality standards help make each revision count.
Building Quickly and Building Correctly Are Different Things
Prices can differ between the homepage and a product page. Update dates can fall out of sync. A similar but different product can be mistaken for the lowest-priced match. The mobile layout can break. These issues can arise in AI-assisted development too. Some of the time saved needs to go toward checking data consistency, links, rendering, terms, and error handling.
The First Project Leaves More Than a Finished Site
The product-data structure, API retrieval, matching rules, design, tests, deployment steps, and failure cases all remain. They can serve as a foundation for the next site. More important than having built something in four days is having a system that can make the next project even faster.
Keep the Reasons Behind Decisions, Not Just the Code
To make fast delivery repeatable rather than a one-off, keep:
- Requirements and completion criteria
- Data structures
- Design rules
- Test cases
- Deployment steps
- Failures and reasons for revisions
- Reusable components
Keep the reasons behind decisions, not just the code. That makes it possible to carry the same quality standards into a different domain.
The real speed of AI-assisted development comes from
shortening the distance between a decision and implementation.
What speed makes possible.
Move Through One Decision Loop Instead of Separate Queues by Role
Saying it was built quickly can make it sound as if AI produced the finished product in a few hours. In reality, the work involved product data, external APIs, price history, product matching, guide articles, tests, deployment, and more. What changed was that I could move through these different tasks in one continuous decision loop instead of putting them into separate queues by role.
| Phase | Typical handoff in a conventional process | What AI-assisted work shortened | Judgment that remained with the human |
|---|---|---|---|
| Requirements | Writing a proposal and confirming specifications | Drafting specifications from conversation | Deciding what not to build |
| Data design | Research and design review | Drafting a schema and transformation logic | Checking data-use requirements |
| UI implementation | Handoff from design to implementation | Revising screen concepts and code together | Setting information priorities |
| External integrations | API research and coordination between owners | Building integrations from official documentation | Deciding how to handle terms and missing data |
| Content | Topic selection, writing, and publishing | Drafting outlines and copy in parallel | Checking facts, experience, and wording |
| Testing | Requesting QA after implementation is complete | Repeating checks during development | Making the final call on launch readiness |
| Deployment | Documentation and adjustments for environment differences | Organizing settings and checks | Checking production impact and rollback options |
What was reduced was not just hands-on work, but coordination time: explaining requirements, waiting for someone to become available, and re-explaining the intent behind returned work. When the planner and implementer are the same person and AI drafts work on the spot, the distance between a decision and a revision becomes extremely short.
At the same time, the four-day timeline should not be copied in isolation. It was possible because I had a basic understanding of the technologies, reusable components from earlier work, a clear scope, and available external services. If a project involves unfamiliar regulations, large volumes of personal data, payments, or complex permissions, the same speed should not be the priority.
Treat Meaningful Review, Not Production Speed, as the Bottleneck
In AI-assisted development, tasks that can be accelerated need to be separated from tasks that require time and care.
Work that is easy to accelerate
- Drafting screens or logic from familiar patterns.
- Data transformations and validation code in a repeated format.
- Expanding test cases from specifications.
- Drafting standard descriptions, metadata, and operating procedures.
- Organizing errors and listing potential fixes.
Work Where Human Review Must Not Be Rushed
- Terms for using external APIs and content.
- Semantic judgments, such as whether products are the same and figures reflect reality.
- Safety around secrets, permissions, deletion, billing, and deployment.
- The impact of inaccurate information on users.
- What the service does and does not promise.
Even if AI writes the tests, the thing being tested may still be wrong. A page can render correctly while using the wrong set of products for its price comparison. Twenty-four buying guides add no distinct value if they simply repeat the same explanation. The bottleneck should be meaningful review, not production speed.
For every change, I made a point of checking the main user flows, missing data, external links, mobile layouts, secrets, and rollback options. In a fast project, quality is easier to protect by checking that each small change still works than by saving one long test session for the end.
Turn Speed from an Accident into an Improving Process
To make the four-day project more than a one-time story, I decided what to carry forward:
The second project gets faster for reasons beyond improvements in AI. Failures, design boundaries, and checks from the first project can be reused. If only the finished code remains and the reasons behind the design are lost, the same investigations have to be repeated next time.
The real result of rapid development is not only launching something in four days. It is gaining a production system that reveals where delays occur between planning and launch, and which decisions should stay with people. As AI improves, the quality of this system will translate directly into differences in speed and quality.
The Real Cost Appears After the Four Days
If only launch speed is measured, rapid development can look like a success. But API changes, missing product data, organic-search monitoring, article updates, and user inquiries all begin after launch. If a four-day build requires ten hours of manual work every week afterward, the cost has simply shifted from development to operations.
That is why I track revision time starting in the launch week. I classify what runs automatically, what a person must check, and which problems keep recurring. If the same check is needed more than three times, I add it to the test suite; if a task requires judgment, I document the procedure and owner. Rapid development should be evaluated not only by its launch date, but also by whether it can be maintained a month later.
Users may respond differently from what I imagined during development. They may read basic guides more than the comparison feature I worked hard on, arrive through unexpected search terms, or have trouble finding important details on mobile. Before adding features, I should improve the paths people actually use. The benefit of launching in four days is not being able to boast about a finished product; it is reaching real data sooner.
Even When Working Alone, Separate the Roles in Your Mind
When one person handles planning, implementation, and quality checks, alignment work decreases—but so do the people who can challenge their assumptions. Even when the same person does the work, it helps to separate the timing and perspective. I avoid deciding to launch immediately after implementation and review only the user flows the next day. I also ask AI, in a separate conversation from the implementation work, to look for ways to break the product, confusing displays, and concerns about terms.
Generating several AI outputs at once creates a review queue. Even if screens, articles, tests, and configuration return together, the work is not finished until a person has checked what they mean. At the end of each day, I count the unreviewed outputs. If they exceed what I can handle the next day, I stop generating new work. This limit helps keep quality from slipping during rapid development.
Four days is not a target for every project. That speed only makes sense when the scope is small, changes are reversible, data can be checked, and reusable components are available. Copying the timeline while ignoring those conditions leaves unreviewed debt behind.
To repeat the same speed next time, record not only working hours, but also uncertain decisions, waiting time, and causes of rework. Distinguishing the steps AI accelerated from the human checks that protected quality turns speed from an accident into a process that can improve.