Working with Existing Projects

Continue developing an existing condoo.Vibe project or bring outside code into condoo.Vibe safely without rebuilding features you already have.

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 condoo.Vibe.

How you work with an existing project depends on where that project currently lives and how much of it condoo.Vibe can access.

This guide explains the best way to approach existing applications without accidentally rebuilding functionality you already have.

Existing condoo.Vibe projects

The simplest case is an application you've already created with condoo.Vibe.

Open the existing project from your condoo.Vibe dashboard and continue the conversation.

Because you're working inside the same project, condoo.Vibe 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.

Start by understanding what already exists

When working with an established application, don't immediately ask condoo.Vibe to make major changes.

First, make sure condoo.Vibe 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 condoo.Vibe 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 condoo.Vibe 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 condoo.Vibe 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 condoo.Vibe

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 condoo.Vibe project in a supported way.

A live URL is not the source code

If you have:

https://example.com

condoo.Vibe 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.

condoo.Vibe can export supported projects to GitHub, allowing you to take your condoo.Vibe-generated code into a traditional development workflow.

If direct repository import is available in your condoo.Vibe account, follow the import options shown in the project creation experience.

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 condoo.Vibe.

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 condoo.Vibe to turn into a working product.

In that situation, explain what you're providing and what you want condoo.Vibe 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 condoo.Vibe that product context separately.

Continuing development outside condoo.Vibe

condoo.Vibe 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 condoo.Vibe to accelerate product development while retaining control over their code and infrastructure.

Hosting and development are different

condoo.Vibe can host published condoo.Vibe projects for you.

But hosting and development are separate concepts.

You might:

Build with condoo.Vibe → Host with condoo.Vibe

or, where your project and plan support it:

Build with condoo.Vibe → 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 condoo.Vibe, responsibility for that external deployment environment belongs to whoever operates it.

Before making major changes

When continuing an existing application, use this checklist:

• Does condoo.Vibe 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.

A recommended workflow

For significant existing applications, use:

Understand → Protect → Plan → Build → Test

Understand

Make sure condoo.Vibe 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

condoo.Vibe 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 condoo.Vibe 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 condoo.Vibe application over time

The objective is not always to start over.

It's to keep moving the product forward.

You've completed Building with condoo.Vibe

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 condoo.Vibe Min and condoo.Vibe Max
• Work with Project Memory
• Iterate on your application
• Debug problems
• Approach existing projects safely

Together, these concepts form the core condoo.Vibe development workflow.

Next: What condoo.Vibe Builds For You

Until now, we've focused primarily on how you work with condoo.Vibe.

Next, we'll go underneath the application.

We'll look at what condoo.Vibe 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.