How to build high-fidelity prototypes with AI

Legacy software does not become a problem just because it is old.

It becomes a problem when it starts limiting the business.

In one of our modernization projects, a legacy application was still central to the client's product. Customers used it every day to search and book flights, hotels, transportation, and other travel services.

But maintaining it had become expensive. Routine changes took too long, the technology was no longer supported, and the application struggled to meet current accessibility, usability, and security requirements.

The company needed to replace it without interrupting the customers who depended on it.

There is no single right way to modernize legacy software. The right approach depends on how the system works, how users depend on it, and what it will cost to run the old and new systems during the transition.

TLDR

• Modernize when the existing system is creating business problems, not simply because the technology is old.
• Compare incremental migration with building the replacement separately.
• Treat legacy code as a reference, not the specification.
• Define scope, expected behavior, and acceptance criteria clearly.
• Validate the replacement with real users before broad migration.
• Treat launching the new system and retiring the old one as separate milestones.
• AI can speed up implementation, but it cannot resolve unclear requirements.

Start with the business problem

An old system may still serve the business well.

Modernization becomes more urgent when maintaining it starts getting in the way of what the company needs to do.

Common signs include:

• Routine changes taking too much engineering time.
• Security or compliance requirements becoming harder to meet.
• Integrations becoming difficult to maintain.
• Customer requests becoming expensive to deliver.
• Teams avoiding necessary changes because they fear breaking the system.

These problems give the modernization a purpose.

Instead of asking, “How do we rebuild this application in newer technology?”, ask:

What constraints does the replacement need to remove?

That question helps keep the project focused on business needs rather than technology for its own sake.

Decide how the old and new systems will coexist

One of the first decisions is whether to migrate gradually or build the replacement separately.

An incremental migration can work well when parts of the system can move independently. But it also means the old and new applications may need to work together for months.

That temporary architecture has a cost.

In this project, the team initially considered releasing parts of the replacement while the rest of the product remained in the legacy application. They even started working that way.

But the approach introduced additional complexity. Each new feature needed to work alongside the legacy system, requiring compatibility, security, and interoperability work that would eventually have to be removed. With tight deadlines, the extra development effort and future maintenance costs made this approach impractical.

The team decided to build the replacement separately while keeping the legacy application in production. Once the new application was ready, selected customers began using it and reporting issues or missing functionality before the broader migration.

In other projects, moving functionality gradually has made more sense because workflows could be separated cleanly.

The useful question is:

What temporary work does each migration strategy create?

If gradual migration requires months of disposable compatibility work, a separate replacement may be easier to control. If capabilities can move independently, incremental migration may reduce risk.

Make that trade-off explicit before development starts.

Treat legacy code as evidence, not the specification

One of the hardest questions in a modernization is simple:

What should the new system actually do?

“Make it work like the old system” is not enough.

Legacy code can show developers how something was implemented. It cannot always explain which behaviors still matter, why exceptions exist, or what users depend on today.

For each piece of work, define:

• The scope.
• The expected behavior.
• Acceptance criteria.
• Representative use cases or test cases.

Instead of writing:

“Recreate the functionality from the legacy application.”

Start by defining what the user needs to accomplish. Then describe the steps they take, what information they need to see, how the application should respond, and how the team will verify that the feature works as expected.

Modernization projects will uncover missing details. When they do, make the new work visible instead of quietly expanding the task already in progress.

Protect the team's capacity

Keeping the legacy system running while building its replacement creates two workloads.

Production support can quickly compete with modernization work, especially when the same engineers understand both systems.

Before committing to a schedule, decide:

• Who supports the legacy application?
• Which legacy improvements still need to happen?
• Which requests can wait?
• How much modernization capacity is protected?
• What happens when a production issue interrupts the plan?

A deadline is more useful when the capacity behind it is clear.

Validate the replacement with real users

Development being complete does not mean the migration is complete.

Before moving everyone, selected customers on this project used the replacement in their real workflows.

They found bugs, missing information, and behaviors the development team had not anticipated.

Technical completeness does not guarantee that users can complete their work.

Before broad rollout, test realistic tasks with real users. Find out where information is missing, which workflows break down, and where people still need the old system.

Separate launch from legacy shutdown

A migration rarely happens in one event.

The replacement may already be serving customers while the team continues fixing gaps and moving the remaining users.

Treat these as separate milestones:

1. The replacement is ready for testing.
2. The replacement is ready for production users.
3. Customers no longer depend on the legacy system.

Before retiring the old application, confirm that users can complete their important workflows, support teams can resolve problems in the new system, and customers no longer need to return to the legacy application.

If users keep going back, find out why.

The replacement may be missing functionality, require more training, or make an existing task harder.

Migration success is not simply having the new application in production.

It is reaching the point where people can stop depending on the old one.

AI makes clear requirements more important

AI was introduced partway through this modernization project and helped the team implement work faster.

It worked best when the task was already clear.

With defined scope, acceptance criteria, and test cases, developers could use AI to produce more of the implementation and spend more time reviewing the code and checking the expected behavior.

Ambiguous requirements stayed ambiguous.

AI can reduce the effort required to produce code. It cannot decide which legacy behavior matters or what the replacement should do.

As implementation gets faster, understanding the system and defining the work become even more important.

Plan the migration, not just the deadline

A delivery date is not a migration plan.

Teams also need to understand:

• Which pieces of work depend on each other.
• What can happen in parallel.
• Where the biggest unknowns are.
• How much capacity is available.
• What must happen before users can migrate.

The plan will change as the team learns more about the legacy system. Having one still gives the team a way to understand whether the deadline remains realistic.

What should be clear before modernization starts?

Before committing to a migration plan, answer four questions:

Why are we modernizing?

Identify the business constraints created by the existing system.

How will the old and new systems coexist?

Compare the temporary cost and risk of each migration approach.

How will expected behavior be defined and validated?

Document acceptance criteria and representative use cases, then test them with real users.

What needs to be true before the old system can be retired?

Define this separately from the launch of the replacement.

Any question the team cannot answer identifies work that should happen before rollout.

Modernization should remove constraints, not reproduce them

A legacy application is an important source of information, but it should not dictate every decision about its replacement.

Understand which business rules still matter. Make expected behavior explicit. Choose a migration strategy based on the real dependencies between the old and new systems. Then validate the replacement with the people who will depend on it.

The goal is not simply to replace old technology.

It is to leave the business with software that is easier to change, support, and rely on.

If you're planning a legacy modernization and need help understanding the existing system, comparing migration strategies, or defining a path to the replacement, let’s start a conversation.

‍

Kaizen Softworks is Certified in the Claude Partner Network.

This milestone recognizes the Claude training and certifications completed by members of our team. It also reflects work we've been doing across Kaizen: testing how AI can improve software development and exploring new ways to build AI into products.

For your team, that could mean testing a product idea earlier, finding information across internal systems, or reducing manual work in an existing process.

We've been exploring these opportunities through internal experiments and client projects. Now we're bringing that experience into services designed to help you identify where AI makes sense and turn promising ideas into working software.

What being Certified means

The Claude Partner Network is how Anthropic works with firms that help customers bring Claude into production. Its Services Track recognizes progress in developing certified teams, delivering Claude use cases, and demonstrating customer work.

Certified is the first partner tier. It recognizes firms whose team members have completed Claude training and earned Claude certifications.

For Kaizen, this is another step in building our team's AI capabilities. The certifications add structured learning to the practical work we've been doing through our Innovation Hub.

How AI is changing the way we build software

AI is changing how we work across the software development cycle, from exploring ideas and designing experiences to writing code, testing, and releasing improvements.

AI-assisted workflows can help teams build up to 6× faster at a fraction of the cost. The actual gains depend on the project, the tools involved, and how the work is organized.

Our experience has shown us that speed alone isn't enough. AI-generated work still needs clear requirements, technical judgment, and careful review to ensure the software is reliable and maintainable.

For clients, this creates opportunities to explore ideas, validate decisions, and ship improvements faster, with less development effort and lower costs.

How AI changes what your product can do

Using AI to build software is different from adding AI capabilities to a product.

When AI becomes part of your product, the starting point is what users need to accomplish.

Maybe they need to find information across several systems. Maybe your team spends too much time gathering context before making a decision. Or perhaps there's a repetitive task that could be completed with less manual effort.

AI can help with these needs, but making it useful takes more than connecting to a model.

We help define what information AI can access, which actions it can take, when people need to be involved, and how the product should handle incomplete or incorrect answers.

What this means for our clients

Whether you're building a new product, improving an existing platform, or modernizing software, AI creates opportunities worth exploring. Your product doesn't need an AI feature for your team to benefit from AI-assisted development.

Here's how we can help.

Test ideas earlier. AI-assisted prototyping and design exploration can help your team review ideas sooner. You can identify usability issues, gather feedback, and decide what's worth building before committing to a full implementation.

Find where AI fits your project. Not every workflow needs AI, and results depend on your systems, requirements, and team. We help you identify specific opportunities, test them, and decide whether the improvement justifies further investment.

Turn promising ideas into working software. A successful experiment is a starting point. We support the design, integration, testing, and engineering work needed to make software reliable, secure, and maintainable.

Our certification marks progress in developing the skills behind this work. What matters for clients is how we put those skills to use.

Services built around those needs

Your team may have useful information spread across applications, databases, and internal systems. Finding an answer often means searching through several tools. Our Custom MCP Connector service helps connect those systems to AI tools such as Claude, so users can find approved information without navigating every system separately.

Some processes involve the same steps every time: reading a request, gathering information, and deciding what happens next. Our AI Agents service helps identify which parts of those processes AI can handle. We define the task's boundaries with your team, including which tools the agent can use and which decisions require human approval.

A prototype can show that an idea works. Making it reliable enough for everyday use requires more work. Our Prototype to Production service helps your team take an existing prototype further, addressing how it connects with your systems and what it needs to run reliably. That includes defining expected behavior, improving code quality, addressing security, preparing deployment, and planning maintenance.

Where to start

Start with a change worth making.

Choose one workflow or product need. Identify what takes time, where information is difficult to access, or what prevents users from completing a task.

Then define what an improvement should accomplish.

That might mean less time searching for information, fewer manual handoffs, or a task users can complete with less assistance.

Start small, evaluate the whole workflow, and use the results to decide what comes next.

If you have a process you'd like to improve or a prototype you're ready to take further, get in touch. We can help you identify the next step and what it needs to prove.