You have a product. It works, people use it, and you built it yourself with a generation tool. Now you are stuck: the changes being asked for exceed what you can do, and you cannot decide anything because there is nobody to tell you what is reasonable.
It is an uncomfortable position and far more common than people admit. Here are the real options, with what each one assumes.
What you are missing may not be a developer
Before looking for someone to hire, separate three different needs, which are not met the same way.
Deciding. Should this part be rebuilt or improved? Is this supplier selling you unnecessary time? Does this technical choice lock you in? Those questions need someone who has seen projects go by, not someone who writes code.
Producing. Writing features, fixing, shipping. The most visible need and the easiest to outsource.
Lasting. Knowing the application still works this morning, reacting when a user reports a problem, applying security updates.
Many founders hire a developer expecting all three to be covered. A good developer covers the second, helps with the third, and does not necessarily have the distance for the first.
The four options, and their real constraints
Carry on alone with the tool. Viable for longer than people say, provided the code stays in order. These tools handle simple changes on a sound base well. They come unstuck on subjects nobody taught them to handle: access rights, behaviour under load, links to business software.
Hire. The most expensive and slowest route, rarely appropriate before the product’s trajectory is established. A lone salaried developer, with nobody reviewing their work, also carries an underrated risk: you have no way to assess what they produce.
A supplier working to defined batches. You hand over scoped work, you pay a fixed price, you keep control. This suits most situations, provided the scope is written beforehand and you can judge the result.
Ongoing technical support. Someone who knows your product, available for decisions and for changes, without the cost of an employee. That arrangement covers the first and third needs, with production handled as it comes.
The five questions that make you self-sufficient
You do not need to code to steer. You need to know what to ask.
“Where is the code, and can I reach it on my own?” Open the repository with your own credentials. The tools support continuous synchronisation to a repository you control. If you cannot manage it in ten minutes, that comes before everything else.
“Can one user see another user’s data?” The expected answer is a demonstration, not an assertion. This defect is the leading application risk category according to OWASP, and in 2025 it produced a flaw catalogued as CVE-2025-48757 across more than 170 applications built with Lovable.
“What breaks if the number of users multiplies by ten?” A serious supplier answers by naming two or three specific screens. A vague answer means nobody has measured.
“How do we know it is working this morning?” If the answer is “users tell us”, you have found a gap.
“What happens if you disappear next week?” The right answer has three parts: the repository is yours, access is inventoried, the documentation lets someone else take over.
What to refuse
A supplier who answers “it is complicated” without explaining. Your assumed lack of technical skill is no reason to leave a choice unexplained: someone who cannot explain it usually does not master it either.
A quote with no written scope. Without a document describing what will be delivered, you can neither compare nor confirm it was done.
An arrangement that keeps you from your code. It should no longer exist and it still does.
A full rebuild proposed up front, before any diagnosis. It is the most expensive answer and rarely the right one.
The rhythm that works
Founders who cope best without internal technical skill apply a simple discipline: short batches, a written scope before each one, a demonstration at the end, and a regular review of what comes next.
That cadence keeps you in control without requiring technical skill. You judge on what you see working, not on explanations.
The three documents that protect you
Without internal technical skill, your safety rests less on trust than on written records. Three documents are enough, and none requires special knowledge.
The scope, before each batch. One page in plain language describing what will be delivered, what will not, and how you will know it is done. Without it, a discussion about a delay or an omission rests on memories.
The access inventory. Which service, which account, which owning address, who holds the password. A one-page table, kept current, living somewhere other than in one person’s head.
The delivery note. Two lines after each batch: what was delivered, what remains open. Accumulated, those notes tell the product’s story and stand in for the memory you do not have.
These documents matter most on the day someone leaves, you change supplier, or an investor asks where the product stands.
What we do
We work routinely with directors and project owners who are not technical. Scopes are written in plain language, approval happens at each stage, and deliveries come in batches you see working.
We work on a one-off basis or over time, depending on what you need, and we always leave what is required to continue without us: a repository in your name, inventoried access, written documentation.