Built something with AI? We can help you finish it.
If you started a website or app in Lovable, Cursor, Bolt, Replit, or another AI tool, you may be closer to launch than you think. We'll review what works, find what's missing, and help you get it ready for real customers.
AI builders are good at producing screens, flows, and a working demo quickly. The part that stalls is usually what a demo never exercises: real accounts, real payments, real customer data, and a public domain that customers and search engines can reach.
It works in the preview, not on your domain
Custom domains, redirects, environment variables, and production hosting behave differently from a builder preview. Pages that refresh to a 404 and forms that stop sending are common first signs.
People can sign in, but permissions leak
One customer can open another customer's records, or an admin screen loads for anyone who knows the URL. Authorization has to be enforced on the server and in the database, where the browser can't skip it.
Payments only work in test mode
Checkout opens, but nothing reliable happens afterward: no webhook, no subscription status, and no plan for refunds, failed renewals, or a customer who closes the tab mid-payment.
Every new prompt breaks something else
A fix on one screen changes behavior on another, and nobody can say which version last worked. Without version control and a few tests on the main journeys, each change is a gamble.
Google can't see the pages
The site loads in a browser but sends crawlers an almost empty page, repeats the same title everywhere, or has no sitemap. Visitors see a finished site while search engines see very little.
Nobody knows what you own
The code, database, domain, email, and payment accounts may sit under different logins. Some may belong to the builder's account rather than yours until you export or connect them.
What we fix
What Routeless can finish
Each of these is a separate check. The review tells you which ones your project needs and in what order, so you are not paying to fix things that already work.
Production readiness review
Authentication, data access, error handling, backups, and deployment checked against what your launch needs, with a clear list of what passes and what doesn't.
Your domain, environment variables, a production database, error monitoring, and a way to roll back the first release if something goes wrong.
Website or app
Is it a website or an app?
The checks differ. A marketing website has to load quickly, be found, and capture leads. An app has accounts, stored data, and often payments, so permissions and data handling come first.
Website
An AI-built website
Pages, contact forms, booking links, a blog. We check hosting, the domain, page speed, search visibility, forms, analytics, and who controls each account.
Most projects don't need to start over. The review sorts the existing work into three outcomes, and a rebuild is recommended only for the parts that would cost more to repair than to replace.
Signals that point toward a partial rebuild: the data model has to change for every new feature, the code can't leave the builder, or security problems run through every screen instead of a few routes.
Outcome
When it fits
What usually happens
Finish and launch
The main flows work and the gaps are integrations, hosting, or polish
Connect the missing pieces, test the main journeys, and launch on your domain
Stabilize
It works, but breaks often or has security or data problems
Fix permissions and data handling, add version control and basic tests, then keep building
Rebuild part of it
The structure can't support the product, or the code can't be exported
Keep the design, content, and lessons learned, and rebuild the parts that can't be repaired
Supported tools
We can review projects started in these tools
The tool matters less than what it produced. If you can share the code, a repository, or at least a working preview, we can assess it.
Product names belong to their owners. Routeless is independent and is not affiliated with or endorsed by any of these companies.
How it works
How a project review works
01
Share
Tell us what you built, which tool you used, and what has to work at launch. A preview link or repository helps but isn't required. Don't send passwords or API keys.
02
Review
We look at the preview or code, the accounts involved, and the launch requirements, then note what works, what's missing, and what's risky.
03
Scope
You get a written scope listing what we would finish, fix, or rebuild. The timeline, ownership boundary, and price are in writing before any work begins.
04
Build and launch
We do the agreed work in a repository you control, test the main journeys, and launch on your domain. You own the production code and accounts.
Custom projects are scoped and quoted after we review what needs to exist. We don't publish a standard price because the work ranges from a few fixes to rebuilding part of an app.
Engagement
Typical starting point
What it covers
Finish and launch
A working prototype that needs integrations, hosting, or polish
Missing features, integrations, the domain, and launch checks
Fix and stabilize
A live or nearly live project with bugs, security gaps, or data problems
Permissions, data handling, version control, tests, and monitoring
Take over and keep improving
A product that needs regular development after launch
Ownership transfer, a maintained backlog, and ongoing releases
Finishing an app means accounts, payments, AI features, and security fixes that hold up under real use. These Routeless projects show that work.
These projects are shown for production capability. They were not started in AI builders, and none is presented as an AI-builder rescue.
Routeless Lab
VisaMind
The problem it solves
Immigration questions change with the country, the visa type, and the applicant's family situation, and a general service page does not answer them. The product had to match each applicant to a visa and then help them prepare.
What we built
Visa matching across 14 countries
A personalized checklist and timeline for each applicant
An AI voice interview coach that plays the part of a consular officer
Accounts and a document vault, with private document storage and controlled downloads on AWS
Transactional email with signed delivery events, sent through Resend
Country hubs, visa guides, a forms library, and a glossary, with a page for each country, visa type, form, and processing-time question
VisaMind launched on a domain with no search history. The case study tracks its Google appearances and the visits ChatGPT sends, from Search Console and GA4 data.
A course platform competes with free documentation and every tutorial on the internet, and broad course terms are competitive in search. The free reading had to point learners toward the paid product.
What we built
A curriculum of 121 lessons
1,598 exercises that run in the browser
A context-aware AI tutor
Accounts and subscription payments through Stripe
An 86-article library written against what the curriculum already teaches
Yes, in most cases. Lovable can sync a project to a GitHub repository, which gives a developer the full source code and its change history. From there the developer can run it locally, review the database and permissions, and deploy it. If you can only share a preview link, we can still review behavior and plan the work, but changing the code needs repository access. The Lovable page covers the sync and ownership details.
Usually not. Most AI-built projects have screens, flows, and content worth keeping. The review identifies which parts can be finished as they are, which need repairs, and which would cost more to fix than to replace. A rebuild makes sense when the data model can't support the product, the code can't be exported, or security problems run through every part of the app. Even then, the design and copy usually carry over.
That's enough to start. A preview shows us the screens, flows, and behavior, and you can describe what is supposed to happen. We'll tell you what we can assess from the preview and what we need to see in the code before committing to a scope. For most builders the next step is connecting the project to GitHub or exporting the code, and you can do that without sharing your password with anyone.
Yes. Those are the most common gaps between a working preview and a launched product. Domains include DNS, redirects, and email records. Payments include Stripe checkout, webhooks, and subscription status. Databases include the schema, access rules, backups, and moving data off a builder's managed backend when that's needed. SEO includes crawlable pages, titles, canonical tags, sitemaps, and Search Console. The review tells you which of these your project needs, and in what order.
Yes. You own the production code and accounts on custom work, and we document how to run, deploy, and recover the project. Part of the review is finding out what you control today, because some builders keep the code, database, or hosting under their own account until you export or connect it. If something important sits under a login you don't control, moving it into your name is one of the first tasks.
It depends on what's missing, so we don't quote a standard timeline. Connecting a domain and fixing a few forms is a different job from adding payments, fixing permissions, and moving a database. After the review, the written scope includes the timeline for the agreed work. Routeless accepts at most two new builds per month so Eric can stay involved through launch, which also affects when work can start.
Often, yes. If the builder's hosting fits the project, we can fix content, metadata, forms, and integrations and leave it there, so you can keep editing with prompts. Some limits stay, such as hosting options, how pages are rendered, and how much control you have over the server. We'll tell you whether staying on the builder is reasonable for your goals or whether moving to your own hosting will save trouble later.
That's common and usually fixable. The frequent problems are missing database access rules, permission checks that only run in the browser, API keys exposed in frontend code, and admin pages without real protection. We test with accounts at different permission levels, fix the access rules on the server and in the database, and rotate any keys that were exposed. A builder's security scan helps, but it doesn't replace testing the app with real accounts.
Yes. Code produced in a chat assistant or an agent gets the same review as code from an app builder: what runs, where it's hosted, what data it touches, and what's missing for launch. These projects are often spread across copied files and chat threads, so the first step is collecting everything into one repository and confirming it runs. If the project depends on a platform's own hosting or database, we check what can be exported.
Start with the review form. Tell us what you built and what has to work at launch, and we reply with whether we can help and what the next step would be. Custom projects are scoped and quoted after we review what needs to exist, and the price is put in writing before work begins. We don't publish a standard price because the work ranges from a few fixes to a partial rebuild. The cost guide explains what drives the number.
