How should an AI product builder handle the integrations you already have?
August 28, 2026
It should preserve them by default. A product already running on Auth0, Stripe, Postgres, and Vercel does not need those replaced. It needs new work built around them. So the question to ask any AI product builder is not how many integrations it supports. It is what happens to the ones you arrived with.
Your stack is not a set of defaults
Most AI builders were designed for an empty directory. You describe a product, the platform picks the stack, and every choice it makes is a first choice. Nothing exists yet, so provisioning a database and switching on payments for you is a favor.
Bring a running product and the same behavior stops being a favor. Your auth provider is wired to how permissions work. Your payment processor holds your customer records and your tax setup. Your database carries the history of every schema change that got you here, in order. Those are not blanks waiting to be filled in. They are decisions that have already been tested by real users.
A development platform that treats them as replaceable doesn’t save you setup time. It is proposing an architecture change and calling it an integration.
Three things a development platform can do with a service
Work with what is already there. The platform reads your repository, sees that you use Stripe, and writes code that uses Stripe. Nothing is configured inside the platform, and no account is connected. The integration stays where it already lived, in your code.
Provide the capability itself. You get email, or hosting, or a database, and the platform owns the relationship with whoever is underneath. This is simpler when you have nothing. When you already have something, it means a vendor you did not choose is now inside your running product.
Require a connection of its own. The platform needs access to your account to do its job, for example to read your analytics or your error tracker. This can be legitimate and should be visible because it is where the platform ultimately holds a key.
Product pages often describe all three under the same word, “integrations,” which is why counting logos tells you very little.
What happened when three platforms were handed an existing codebase
Forged ran Emergent, Replit, and Lovable through the same test rounds and recorded what each one did without being asked. Everything below we observed first-hand, in the product, on our own accounts, in August 2026.
| What you arrive with | Lovable | Replit | Emergent |
|---|---|---|---|
| An existing Python and Flask codebase | LovablePreserved | ReplitPreserved | EmergentPreserved |
| Database | LovableAuto-enabled in chat, on a Supabase project owned and managed by Lovable rather than your own Supabase account | ReplitProvisioned by default, connection string exposed to you and described in product as something to copy into any service that needs to connect | EmergentNo database service |
| Payments | LovableStripe and Paddle switched on by default on an account that connected neither. Lovable provisions the Stripe account and you claim it at go-live | ReplitNo payments service. Stripe appears as a sign-in integration for read access to your own account | EmergentNo payments service |
| Transactional email | LovableNo first-party service, third-party providers supported | ReplitNo first-party service, third-party connectors supported, including MailerSend and MailerLite | EmergentNo email service |
| Git hosts | LovableGitHub and GitLab | ReplitGitHub, GitLab and Bitbucket | EmergentGitHub only |
Observed August 2026.
All three preserved a Python and Flask codebase. None tried to rewrite it in JavaScript. If you have read that these platforms only work in one language, that is not what we found. Lovable did preserve Flask when we supplied existing source, but it did not support importing the existing repository itself. In our test, its file-attachment route was also limited to ten files.
The differences are in what each one switches on by itself. Lovable hands you a working service it owns. Replit hands you the credentials and lets you drive. Emergent stays out of application services altogether, which we verified at the account level, within a project, and across all three of its published tiers.
None of those is the wrong answer for a new product. They are answers you want to choose rather than discover.
Two of the Lovable findings would be unfair without the rest of the story. The Stripe account it creates is claimed by you at go-live, so payments are credited to your name. The database is the harder one: your data exports, but the schema does not. Lovable’s own documentation describes exporting the data, connecting a Supabase project to a new Lovable project, and rebuilding the schema there yourself. The data is recoverable. The structure you rebuild by hand. That is a real cost, and it is a smaller claim than “you cannot leave”, which would not be true.
How to check this yourself in ten minutes
Connect a repository to whichever platform you are evaluating, ask for one small change, and watch what it switches on that you did not ask for. Ten minutes of that is worth more than any integration page, because it shows you the platform’s defaults rather than its catalog.
Then ask four questions about whatever it turned on. These are worth asking of any platform in this category, Forged included.
Whose account is it? There is a real difference between a service the platform operates for you and one it creates in your name. Both are defensible. Only one leaves you holding the vendor relationship, and you want to know which before you have customers on it.
What from the platform is still running in production? Ask about anything that sits between your application and a service it calls, or that holds a key. Code you can read and move is a different kind of dependency from something in the middle you cannot see.
Where does a change arrive first? A change that arrives as a pull request in a repository you own can be read, questioned, and rejected before it is merged. A change that appears first inside a platform-managed project or preview follows a different review model.
What does leaving cost, in steps? Almost every development platform has an export. The useful question is what you hold afterward and what you have to rebuild. Ask for the actual sequence, not the principle.
Where Forged stands
Forged is an AI product-building system for founders, built for existing products where the fiftieth change matters more than the first. That is why preserving the stack is the default rather than a setting.
| Forged approach | |
|---|---|
| Existing integrations | Preserved by default |
| New transactional email | Forged email available |
| Hosting | Forged hosted by default, customer infrastructure supported |
| Payments | Customer-owned Stripe |
| Database | Existing database preserved; PostgreSQL preferred when a new database is needed |
| Customer-owned integrations | Direct application-to-provider connection by default |
Services your code already uses need no setup inside Forged and are not recreated as Forged connections. If your application runs on Auth0, Stripe, Postgres, and Vercel, a feature that adds paid team accounts extends Auth0, Stripe, Postgres, and Vercel. Changing a major provider is a product decision, and it is treated as such rather than as a choice an agent makes quietly.
Where Forged does provide a service, the point is to remove a vendor choice rather than make one for you. Forged email services abstract the transactional email provider underneath, so you can send email without choosing one, opening an account, or managing credentials. If your application already sends email through a provider, that stays.
Forged hosting is the default deployment path, and it is not mandatory. Applications with specialized infrastructure continue to run on their own GCP, AWS, or existing setup. Deploy is separate from hosting and does not change either way, so the same release workflow, verification, and rollback history apply wherever the application runs.
And customer-owned integrations do not become dependent on Forged. The output is a change in your own repository. When your application connects directly to a customer-owned service such as Stripe or Auth0, Forged does not insert itself into that connection. Managed Forged services, such as Forged email services or Forged hosting, are different because you have explicitly chosen Forged to provide that capability.
Your questions, answered
Will an AI product builder replace my existing integrations?
Some will, by default, if you let them. In our August 2026 rounds, one of the three platforms we tested enabled a database and two payment providers on an account that had connected to neither. It is framed as setup rather than as replacement, so it is worth checking rather than assuming.
Can I keep my existing database and hosting?
With Forged, yes, and it is the default rather than something you ask for. Across the category, confirm with each platform whether an existing database is preserved and whether hosting is required or merely offered.
What if I do want my development platform to manage some of it?
That is a reasonable thing to want, and it is why managed services exist. Take them one at a time rather than as a bundle, and keep the ones with a direct commercial relationship, payments in particular, in your own name. Convenience is a good reason to hand over email. It is a weaker reason to hand over the account your customers pay into.
Do I have to move my whole stack to get value?
No, and a platform that requires it is asking for an architecture migration before it has earned one. The reasonable path is that new work uses what is already there, and any provider change is proposed, priced and approved on its own terms.
See how Forged works with an existing product
Connect your repository and describe the next change you want to make. Forged works from the product and stack you already have.
Last reviewed: August 28, 2026.