From a Project Everyone Shared… to the Question “How Did You Do That?”
After the Three Kingdoms Interactive Map went live for people to try, it got shared and talked about widely, along with a question the team kept hearing:
“Did you really use AI to build this?”
“How do you build a website like this in 4 hours?”
You can explore the site here: muze.co.th/labs/three-kingdoms-interactive-map
The answer is yes — we genuinely used AI to build this website.
But what’s more interesting than the AI itself is the workflow behind it, the one that let this project produce a working prototype in under 4 hours.
Rewind a few years, and a website this complex would likely have taken 3–6 months just to see a first prototype, requiring a product team, UX designers, and multiple developers working together throughout the project.
Today, AI has cut that timeline down dramatically.
But the speed didn’t come from AI alone.
What actually changed was the product-building workflow itself — from understanding the requirement, to breaking development into multiple iterations, to continuously gathering feedback, to choosing the right AI for each type of task.
What most people saw was a website that went live within hours. What they didn’t see was the large number of decisions made along the way — because no matter how fast AI can generate code or a web page, every time the system produces an output, the team still has to keep asking whether it actually meets the need.
So AI didn’t replace “thinking” — it cut the time spent on work that used to require a lot of repetition, freeing the team to spend more time on user experience design, checking data, and making business decisions.
Here’s what we learned from this project.
Step 1: Product Requirement
The better you understand the problem, the more precisely AI can build what you need
Many people assume using an AI builder is about writing a good prompt. In reality, what matters more is the “product requirement” — understanding what you actually want to build.
For the Three Kingdoms project, the team didn’t start by telling the AI “build a Three Kingdoms website.” They started with a detailed conversation to translate the picture in their heads into a requirement AI could actually build from.
Examples of the requirements included:
- The map must be based on the current map of China
- It must show how Chinese territory evolved from the Han Dynasty, splitting into multiple factions before settling into three kingdoms
- The story must follow a timeline
- Users need to be able to easily follow the sequence of events
- Use CE years instead of the Buddhist calendar, to stay consistent with the historical context
These details might look small, but to an AI, they are the system’s specifications.
AI can’t guess what its creator wants. If the requirement isn’t clear, the result might look beautiful but miss the mark entirely.
Another lesson the team learned: a good requirement isn’t the longest one — it’s the one that fully answers the important questions, such as:
- Who is this system for?
- What does the user need to do?
- What’s the most important piece of information?
- What absolutely cannot be wrong?
For the Three Kingdoms website, the accuracy of the timeline and historical data mattered more than how polished the animation looked — because even a small timeline error could instantly mislead a user’s understanding of history.
Once the requirement was clear, AI could produce results much closer to what the team pictured, and the time spent on revisions in the next stage dropped noticeably.
Worth noting: the time the team spent on this stage wasn’t actually less than writing a traditional requirement — the nature of the work just changed. Instead of writing a long spec document to hand off to a dev team, it became a real-time conversation between the team and the AI, seeing immediately whether the understanding matched. That’s what shortened the “think, then see the result” loop so dramatically, even though the requirement itself still needed the same careful thinking as before.
Step 2: Build Process
Don’t try to finish everything in one go
Another thing that’s changed in the AI era is how software gets built. In the past, a development team might spend weeks or months before seeing a first draft of a website. Today, AI lets us see a first prototype within hours — and that changes the whole approach to building.
Instead of trying to finish everything in one pass, the team chose to split development into multiple drafts, or iterations, and gradually fill in detail with each round.
Here’s how it played out for this project:
Draft 1: Verify the core structure
Start by building only the essential parts, such as:
- Website layout
- The map
- Data layout
- Descriptions
- User flow
The goal: check whether the overall direction is right.
This first draft might look unpolished and incomplete, but it’s valuable for confirming the project’s most important assumption: whether viewers can understand what story is being told through the map and timeline. If the answer is yes, the team can confidently invest more time in the next round of detail.
Draft 2: Fill in the detail
Once the structure is settled, add elements that make the map more complete, such as:
- Rivers
- The Great Wall
- Warlord portraits
- Various features
Draft 3: Add the experience
Once the data is complete, add:
- Timeline
- Animation
- Narration
- Background music
From there, the team kept iterating until reaching the most complete version of the website.
The advantage of this approach: the team could see results and gather feedback from early on, instead of waiting until everything was finished before circling back to fix things.
In the past, even a small change might have to go through a designer, get handed to a developer, and wait several more days for a new build.
But with AI able to generate a prototype in minutes, the team could keep testing new ideas continuously, so decisions were grounded in something real rather than imagined from a document or wireframe.
No single AI is good at everything
Another common misconception is trying to use just one AI to do everything.
In practice, most development teams use several AIs together, because each model has different strengths — for example:
- Some are better at architecture
- Some are better at writing code
- Some are better at UX
- Some are better at debugging
- Some are better at generating content
In a real project, AI ends up working like several specialists each responsible for a different part of the job.
A team might start with one AI to break the requirement down into user stories, then use an AI coding agent to scaffold the website, then switch to another model to review code quality or refactor before shipping to production.
AI Is Changing the Developer’s Role
Many people ask whether AI will replace developers.
Based on the team’s experience, the answer is that AI doesn’t reduce a developer’s importance — it changes the nature of the work developers do.
Time that used to go into writing large amounts of basic code has dropped noticeably.
Meanwhile, time spent on architecture design, requirement analysis, system quality review, and technical decision-making has increased.
Developers are gradually shifting from “the person who writes code” to “the person who directs how the system gets built.”
The important skill in the AI era isn’t memorizing every bit of syntax — it’s knowing which work should go to AI and which decisions still need a human.
For the Three Kingdoms project, the one thing the team always had to weigh in on themselves was historical accuracy. AI could lay out the layout or generate animation quickly, but checking whether a given year or the sequence of events actually matched the historical record still needed someone who understood the context to review it every time before publishing.
From Prototype to Production
Even though AI makes it far faster to build a prototype, taking a system into real organizational use still requires many more components, including:
- System architecture
- Security
- Data privacy
- Integration
- Monitoring
- Performance
- Scalability
A prototype can get away with a lot of shortcuts — temporary data storage, no authentication system, or support for only a handful of users.
But once a system needs to go into real use, every one of these components has to be redesigned.
Many organizations can build a prototype within days, but need weeks or months more to turn it into a production system ready for real use.
Having a good workflow from day one is a critical factor in closing the gap between “an exciting prototype” and “a system that actually works.”
The Three Kingdoms Interactive Map itself is an example of a prototype still at this stage. The project’s main goal was to test an idea and make historical storytelling more accessible, so it didn’t need to meet full production standards yet. But if it ever needed to scale to support a large number of users, or connect to other systems within an organization, every component listed above would immediately need to be designed properly.
AI Prototype to Production, with Muze
The Three Kingdoms Interactive Map project shows that AI can genuinely cut prototype-building time from what used to take months down to a few hours. But in the enterprise world, the challenge doesn’t end once a prototype is built.
Many companies have started letting employees use AI to build their own websites, applications, or work tools — which sparks new ideas and cuts development time significantly.
However, a pattern many organizations run into is the same: even when a tool gets built fast, it’s hard to bring into real use across the whole organization. The tool might only run on the builder’s own machine, lack a consistent UX/UI standard or system architecture, skip a security and data privacy review, or have no way for other teams to use it and build on it.
Muze’s AI Prototype to Production service is designed to help organizations close these gaps — from building the right knowledge and workflow, to systematically bringing tools employees built using AI into real, organization-wide use.
The service framework covers 5 core stages:
- Workshop Program — teaching teams to build AI tools around real organizational problems, with a hands-on focus and an output that’s a genuinely usable tool, not just AI literacy training.
- Builder Kit — a set of tools and standards for UX/UI, frontend, and backend, so everyone on the team builds tools to the same standard.
- Built with any LLM — works with multiple AI coding platforms — Claude Code, Codex, or other LLMs — without locking into any single vendor, giving organizations the flexibility to pick the right tool for the job.
- IT Governance Pipeline — reviews security, technology stack, and data privacy before a system goes live, ensuring every AI tool built meets the organization’s standards.
- Internal App Store — brings reviewed AI tools into a central organizational hub with access management, so every team can use, co-develop, and extend them efficiently.
This approach doesn’t just help an organization build prototypes faster — it turns the tools employees build into systems that are genuinely production-ready, meet IT governance standards, and can scale confidently across the whole organization.
If your organization is starting to use AI to build internal tools, or wants to turn a prototype into a production-ready system, Muze Innovation is ready to help set up the right workflow from day one — so AI isn’t just a tool for testing ideas, but something that creates lasting business value.
Learn more about AI Prototype to Production
