When you prompt an app build on Lovable or Replit, that AI is going to build with a predetermined tech stack. It's unlikely its your exact existing stack. You think that’s how it has to be, but it doesn’t; you can force the AI to build an app from the ground up ready to plug in your existing APIs. Here’s how to do it.
Lovable’s system prompt
Each builder platform has existing tech stack partner brands: Lovable integrates Supabase, Replit has a built-in Postgres service, and so on. Their AI is programmed to build any app to prioritize those databases and other third party software partners.
This has been a pain as non-tech users often-times have to go through the confusing process of replacing the boiler plate tech stack with their organizations' existing stack. Or, in most cases, they feel like they just got tied into paying for another service subscription that does something they already subscribe to.
However, there is a way you can force the AI to build your app to use your existing technology stack APIs. This way, your app is purpose-built from the start to use your organization's current auth provider, database, file storage, email service, and more. It’s not just a custom built tool anymore, but a custom built tool for your specific organization’s tech stack.
The Foundation
Rather than starting in Lovable, begin in Visual Studios (VS) using a Claude Code subscription.
You’ll first set up a GitHub repo for the app you want to build. This repo needs your PRD markdown file for this app (use our free PRD Refinery Tool for an AI friendly .md), your auth provider variables .md, your file store .md, and to follow the branding of your organization, you should save a screenshot of the website or page you want this app to reflect here too.
Pull this repo into VS and confirm everything is there. Add your .env file with your API and database URL info and exclude this file from Git (we don’t want GitHub to have your info). Then, tell your AI model to:
Review this repo. We need to plan to build the (@PRD file) and do so with the database and (@DAM platform file) variables in the .env. (User Auth) variables can be imported using the attached (@auth .md file). Follow the design language from the (@website screenshot file). Any real questions before we get started?
Planning and Building
Upon repo review, the AI should generate a couple of relevant questions to flesh out a build plan. Answer according to your preference and provide the info missing in the documentation. Tell it:
Restate your plan, and then use /worklist-generator to make the full build end to end in a worklist.
**The worklist-generator is a slash command we’ve created for our team here at Opichi so the AI will properly structure these projects. This is something you can build for your own purpose and preferences. If you want to learn more about worklist commands, drop us a comment on our YouTube videos or in our contact page, and we can start creating some instruction around that.
We set the AI agent on ‘extra high effort’ so the likelihood of errors is reduced. It "burns more tokens", but the lower effort modes always requires rework in our experience, so it burns more less expensive tokens, takes more time, and creates more frustration. Just choose the higher effort mode for the most likely chances of success the first time.
The AI will return a JSON file with the sprints organized. The AI should finish by saying something along the lines of ‘I left the file uncommitted, next step is to start at task 1.1, or run sprints through ship-task task-by-task. Want me to kick off Sprint 1?’
We tell the AI to:
/ship-task for each task, orchestrate the whole thing.
Optimizing Your Build
For some better results, here are a few more things you can prep:
We have a Claude.md file that instructs the AI to do specific tasks, such as gather current API documentation and NOT rely on the trained model’s possibly outdated documentation. Update your own AI agent markdown files to do this, plus some other custom instructions that will make it work better for you.
Keep an eye on your build. Sometimes we’ll catch the AI agent trying to do it all, and we’ll interrupt the agent to tell it to parse out the tasks to subagents. Running parallel agents will make the build go faster.
Watch for required actions from you. There will likely be times you’ll need to test, approve, or provide more information to the agent, and it won't continue without your approval. If the AI cannot proceed without you, don't schedule something like this to build overnight.
Testing the Build
This is going to be a case-by-case situation, but here are some broad stroke best practices for your own user testing:
Start a new chat for each new fix for a tested item. Keep your context windows clean.
For getting through user auth testing, we like to sign in ourselves. We tell the AI we’ve done that to help speed along testing rather than waiting on the AI to try to log in. IYKYK.
For uploading, have test documents ready.
When using an email server to send emails with links, don’t forget to test those links and all required actions in incognito browsers.
Stacking Your Own Micro-SaaS Apps
There you have it! You can rinse and repeat these steps to build a whole suite of micro-SaaS apps hosted on your own private server using your existing tech stack.
You can watch our CEO Courtney Hamp do a complete walk-through example to see what something like this looks like in real life in our video Claude Code to Production: A Transactional Connectivity Framework for Replacing SaaS
Watch the 15-minute video on YouTube here: https://youtu.be/evPfh0gQ0lA?si=K5lXrhZTmz53XT4q