Skip to main content
You don’t always have to start with a blank idea. Sometimes you already have an application, website, design, or codebase and want to continue developing it with AIWA. How you work with an existing project depends on where that project currently lives and how much of it AIWA can access. This guide explains the best way to approach existing applications without accidentally rebuilding functionality you already have.

​
Existing AIWA projects

The simplest case is an application you’ve already created with AIWA. Open the existing project from your AIWA dashboard and continue the conversation. Because you’re working inside the same project, AIWA has access to the existing application context. For example:
Add a customer portal to this application where customers can see their projects, invoices, files, and recent updates.
Or:
Redesign the dashboard while preserving the existing authentication, database, APIs, and customer management functionality.
You don’t need to create another project just because you’re adding a major feature.
If you’re evolving the same product, continue working inside the existing AIWA project whenever possible.

​
Start by understanding what already exists

When working with an established application, don’t immediately ask AIWA to make major changes. First, make sure AIWA understands the current product. For significant work, Explore Mode is useful. For example:
Analyze the existing application before changing anything. Explain the current architecture, main pages, data model, authentication flow, major features, integrations, and anything important I should understand before we continue development.
This gives you an opportunity to confirm that AIWA understands the project correctly.

​
Then explain what you want to change

Once the existing application is understood, describe the desired outcome. For example:
We want to add subscriptions to this application. Users should have Free, Pro, and Business plans with different feature limits.
For a focused change, you may be able to move directly into Build Mode. For a major change, use Plan Mode first.
Create a plan for introducing subscriptions without changing the existing authentication or customer data. Include Stripe checkout, subscription state, feature entitlements, upgrades, downgrades, cancellations, webhooks, and billing portal access.
This separates understanding the existing system from modifying it.

​
Preserve existing functionality

One of the most important principles when working with an existing application is telling AIWA what must not change. Suppose your existing application already has working authentication. Instead of:
Add team workspaces.
Try:
Add team workspaces to the existing application. Preserve the current Google and email/password authentication. Don’t replace the existing authentication system unless the new workspace architecture absolutely requires a change.
Or:
Redesign the dashboard. Preserve all existing API behavior, database functionality, filters, and user permissions. This request is only about presentation and information hierarchy.
The more mature the application, the more important these boundaries become.

​
Work in stages

Large existing applications should usually be changed incrementally. Imagine you have an existing single-user CRM and want to turn it into a platform for agencies. Trying to do everything in one instruction creates a large change surface. A better workflow might be:
1

Explore

Ask AIWA to understand the existing CRM, its data model, authentication, and important workflows.
2

Plan

Create a specification for introducing agency workspaces, team members, roles, and data isolation.
3

Build

Implement the approved architecture.
4

Test

Verify existing CRM functionality still works within the new workspace structure.
5

Expand

Add invitations, team management, permissions, billing, or other agency features in logical stages.
This gives you opportunities to validate the application throughout the migration.

​
Existing code outside AIWA

You may already have an application that was built using another development environment or AI coding tool. For example, your project might currently exist:
  • On your computer
  • In a Git repository
  • On another development platform
  • On a VPS
  • On another hosting provider
The first question is whether the existing project can currently be brought into an AIWA project in a supported way.
Don’t assume that a live website URL gives AIWA access to the application’s source code, database, server configuration, or backend.A deployed application and its underlying codebase are not the same thing.

​
A live URL is not the source code

If you have:
AIWA may be able to understand what the public-facing application looks like when appropriate, but the URL itself does not automatically provide access to everything behind it. A production application may include:
  • Frontend source code
  • Backend code
  • Database schemas
  • Environment variables
  • Authentication configuration
  • APIs
  • Server configuration
  • Private business logic
Much of this isn’t exposed through the public website. If you want to continue developing an existing product, access to the actual project files is much more useful than simply providing the production URL.

​
GitHub and external repositories

If your application is stored in GitHub or another Git-based workflow, the ideal development workflow is to work from the actual repository rather than trying to reconstruct the application from its live website. However, GitHub export and GitHub import are different capabilities. AIWA can export supported projects to GitHub, allowing you to take your AIWA-generated code into a traditional development workflow. If direct repository import is available in your AIWA account, follow the import options shown in the project creation experience.
If you don’t see an option to import an existing repository, don’t create a blank project and assume AIWA automatically has access to your GitHub code.

​
Moving a project from another builder

You may have originally created your application using another AI development platform. In that case, the safest migration approach is to work from the application’s actual source code whenever possible. Before migrating, identify:
  • The frontend framework
  • Backend architecture
  • Database
  • Authentication provider
  • Environment variables
  • External integrations
  • File storage
  • Deployment environment
The visible UI is only one part of an application. A successful migration needs to account for the systems behind it as well.

​
Don’t rebuild blindly

Suppose you have a working SaaS application and want to continue it with AIWA. Avoid starting with:
Rebuild this application.
Instead, first understand what you’re bringing over. A better objective is:
Preserve the existing product behavior and continue development from the current application rather than recreating features unnecessarily.
If a migration requires replacing part of the existing architecture, that should be an intentional decision rather than an accidental consequence of rebuilding.

​
Working with an existing design

Sometimes you don’t have an existing codebase. You have a design or reference you want AIWA to turn into a working product. In that situation, explain what you’re providing and what you want AIWA to create. For example:
Use this design as the visual direction for the application. Recreate the layout and responsive experience, then implement the required functionality behind it.
Also describe any behavior that isn’t obvious from the visual reference. A screenshot can show what a dashboard looks like. It can’t necessarily explain:
  • Where its data comes from
  • What permissions apply
  • What happens when buttons are clicked
  • How filters behave
  • How users authenticate
Give AIWA that product context separately.

​
Continuing development outside AIWA

AIWA also gives you flexibility when you want to take your project elsewhere. For supported projects, you can export your application code or move it into a GitHub-based development workflow. From there, your team can manage its own:
  • Repository
  • Deployment workflow
  • Infrastructure
  • VPS or cloud environment
  • Development process
This is useful for teams that want AIWA to accelerate product development while retaining control over their code and infrastructure.
Aiwa Github Integration

​
Hosting and development are different

AIWA can host published AIWA projects for you. But hosting and development are separate concepts. You might: Build with AIWA → Host with AIWA or, where your project and plan support it: Build with AIWA → Export code → Host elsewhere For example, an agency may export a project and deploy it to its own VPS infrastructure. Once the project is managed outside AIWA, responsibility for that external deployment environment belongs to whoever operates it.

​
Before making major changes

When continuing an existing application, use this checklist:
  • Does AIWA understand what already exists?
  • Have I identified functionality that must be preserved?
  • Is the requested change focused or architectural?
  • Should I use Explore before making changes?
  • Should I use Plan Mode?
  • Are there existing integrations that must remain intact?
  • Could the change affect existing data?
  • Could it affect authentication or permissions?
  • Do I have a way to test the existing workflows afterward?
The goal isn’t simply to make the new feature work. The goal is to make the new feature work without unnecessarily breaking the product you already have. For significant existing applications, use: Understand → Protect → Plan → Build → Test Understand Make sure AIWA understands the current application. Protect Identify existing functionality that must remain unchanged. Plan Think through major changes before implementation. Build Implement the approved change. Test Test both the new functionality and the existing workflows it could affect. This is especially important as your application becomes larger and more valuable.

​
Your existing product can keep evolving

AIWA isn’t only for turning new ideas into first versions. The larger opportunity is continuing to develop software after that first version exists. You can use AIWA to:
  • Improve existing experiences
  • Add features
  • Extend workflows
  • Modernize interfaces
  • Introduce integrations
  • Debug problems
  • Restructure parts of a product
  • Prepare larger changes through planning
  • Continue evolving an AIWA application over time
The objective is not always to start over. It’s to keep moving the product forward.

​
You’ve completed Building with AIWA

You now know how to:
  • Write effective prompts
  • Choose between Build, Plan, Explore, and Debug
  • Plan complex work before implementation
  • Build and modify applications
  • Choose between AIWA Min and AIWA Max
  • Work with Project Memory
  • Iterate on your application
  • Debug problems
  • Approach existing projects safely
Together, these concepts form the core AIWA development workflow.

​
Next: What AIWA Builds For You

Until now, we’ve focused primarily on how you work with AIWA. Next, we’ll go underneath the application. We’ll look at what AIWA can set up for you, including database, authentication, forms, uploads, APIs, server-side functionality, and project data, without requiring you to manually assemble the entire backend infrastructure.

What AIWA Builds For You

See what AIWA sets up automatically, from database to auth to APIs.