Summary

SLAtech LTD is an Israeli software development company, operating since 2004. We help owners of apps built with Lovable: we check the Supabase database access rules, how keys are stored and how the code is structured, take the project to production and keep developing it. The code stays in your GitHub repository. People define the architecture and make the decisions; AI only proposes.

Lovable projects

Your Lovable project is stuck? We will check it, fix it and take it to production

Lovable lets you build a working app in a few days: a React interface, with the database and user sign-in on Supabase. The trouble starts later, when real users, payments and personal data arrive. The database access rules turn out to be incomplete, keys end up in the browser code, and every new change breaks something that used to work. We audit Lovable projects, continue their development, or rewrite what is not worth fixing. What we fixed, we stay accountable for.

Tell us about the project Go straight to the audit

What Lovable does well

Turns an idea into a working product fast. Interface, database, user sign-in and publishing all in one place.

Gives you a modern, readable stack: React, TypeScript, Tailwind. Any experienced developer can read and extend this code.

Does not lock the code in. The project syncs with GitHub, so you can export it and run it in your own repository.

Takes care of baseline security. Row level security (RLS) is on by default, and Lovable runs its own checks before publishing.

That is why a Lovable project rarely has to be thrown away. More often it is enough to fix the specific places the tool is not responsible for.

Where Lovable projects usually get stuck

Data access rules

Row protection is on, but the rules are written for the first version of the product. Once roles, teams and shared records appear, the rules fall behind. Lovable itself warns that checking their correctness is up to the project owner. The automated check sees that protection exists, but not that a rule lets the wrong people in.

Keys in the browser code

Anything in the settings named with the VITE_ prefix ends up in the code every visitor downloads. An AI service or payment key put there can be taken by anyone.

Logic in the browser

Such an app usually has no server of its own, so price, limit and permission checks live in the page code. Those checks can be bypassed. They need to move into Supabase server functions or into the database itself.

Changes going in circles

The bigger the project, the more often a new request in the chat breaks a neighbouring feature. There are usually no tests to catch the breakage before users do.

Invisible to search

Pages are assembled in the browser after loading. Many search and AI crawlers do not run JavaScript and see an almost empty page. For the app itself this does not matter; for pages meant to bring in customers it is critical.

Moving to your own infrastructure

If the database lives in Lovable Cloud, moving to your own Supabase, migrating users and setting up deployment become a separate task.

What we check in a Lovable project

1

Access rules for every table: who can read, create, change and delete records, and whether that matches the intent.

2

Keys and secrets: what ended up in the browser code and in the GitHub change history, and which keys need replacing.

3

Supabase server functions: whether they check who is calling them and what exactly is sent.

4

Payments and limits: where the decision is made, in the browser or on the server, and whether confirmations come straight from the payment provider.

5

File storage: which folders are open to everyone and what is in them.

6

User sign-in: email confirmation, password reset, roles and permissions.

7

Third-party libraries: outdated and vulnerable versions.

8

Database queries: what slows down first as the number of users grows.

9

Repository and deployment: branches, tests for the main scenarios, a separate environment for checking.

The result: a written report in plain language, a list of issues ranked by risk, and a plan of fixes.

Three ways forward

Audit

A check against the list above, a written report and a plan of fixes. A fit if you carry on yourself or with your own team.

More about the audit

Continued development

We take the code from your GitHub repository, close the critical issues and keep developing the product. What we fixed and wrote, we are accountable for.

Discuss continuing

Rewriting a part

Most often what needs rewriting is not the interface but what sits beneath it: access rules, payments, server logic. The React interface can usually be kept.

Discuss a rewrite

How we choose between these paths is described in detail on the page about helping vibe-coded projects.

How we use AI ourselves

In Lovable, AI writes the code and a person describes the task in words. We work differently. On client projects, people define the architecture and make the decisions. AI proposes a solution to a task a person has set, and we bring it into the project ourselves, after review. The AI agent gets no access to the code, databases, keys or passwords, and there is not a single line in the code that a person does not know about.

Frequently asked questions

Yes. The audit does not require leaving Lovable: you get a list of fixes and decide who makes them. If we continue the development, from then on we maintain the code, in your repository.

No. Read access to the GitHub repository the project syncs with is enough. To check the database we need access to the Supabase project, usually read-only as well. We sign an NDA if needed.

No. The project can be exported and the database moved to your own Supabase. If the move is needed, we help with it and check that users and access rules came across in full.

An automated check sees that protection is enabled, but it does not know who in your product should see which data. Only someone who understands the product knows that. The audit checks the rules against how the product is meant to work.

It depends on two things: the size of the project and how far it has drifted, that is, how much in it needs changing and fixing. After the initial assessment we name the scope of work and the price, before any work starts.

Other AI tools

We work the same way with projects built on other tools. The general page: help for vibe-coded projects.

Tell us what you built with Lovable

Describe the product and what is holding it back. We will take a look and suggest where to start: an audit, continued development or rewriting a part.

Tell us about the project Go straight to the audit