Lovable is good at turning a description into a working app quickly. TDK CLI is good at running a multi-service app on your machine. The two fit together when the app you ask for has a shape TDK can describe: separate services, a health route on each, and no secrets in the code.
This article gives prompts you can use with Lovable, then the steps that turn its output into a local TDK stack. I have not run these prompts against Lovable, so treat the wording as a starting point and check what it produces.
Before you start
Ask for the app in a way that matches TDK's model. TDK describes each service with a service.json, and each service runs as its own container. An app that is one large frontend with no backend is simple to run, but it gives TDK little to organise. An app with a frontend, an API, and a worker is a better fit.
Export or download the code from Lovable into a folder you control, and put it under version control before you run anything.
Prompt 1: ask for separate services from the start
Build this app as separate parts:
- a frontend in React
- an API service with a GET /health route that returns { "status": "ok" }
- a worker that runs on a schedule (optional)
Keep each part in its own folder: frontend/, api/, worker/.
Do not put any API keys in the code. Read them from environment variables.
List the folders and the environment variables each part needs.
Why it works: it asks for the separation TDK needs, and it asks for the health route up front, which you will check later.
Prompt 2: ask for a clear data layer
The API stores its data in PostgreSQL.
Put the schema in a migrations/ folder, with one file per change, numbered in order.
Do not run migrations from the API's startup code.
Provide a single script that applies the migrations once.
Why it works: migrations in their own step, applied once, is the pattern that holds up when a local stack starts several times. TDK's guidance puts migrations in a separate resource, ordered after the database and before the API.
Prompt 3: ask for configuration you can check
For each service, list the port it listens on, read from a PORT environment variable with a default.
Bind to 0.0.0.0, not localhost.
Write a short README section that lists the ports and the start order.
Why it works: a service that reads its port from the environment and binds to all interfaces starts cleanly in a container.
Prompt 4: ask for tests you can run
Add one test per API route.
The test should call the route and check the response status and shape.
Give me the single command that runs all the tests.
Why it works: you get a check you can run without reading the code.
After you export the code
Once the code is on your machine, the TDK steps are short. These assume you have Docker running and TDK CLI installed:
tdk doctor --json
Check that canUp is true. Then describe each service to TDK. Each service folder needs a service.json, and TDK generates the runtime files from it. Run a dry run before the first start:
tdk up main --dry-run
Read the plan, then start the stack and check it:
tdk up
tdk status --json
If a service fails, read its log:
tdk logs --json --service <name> --tail 200
Do not edit the generated files under .autogenerated/. Change the service.json or the source instead, and regenerate.
Common problems
-
The app calls
localhostfor the API. Replace it with a setting read from the environment, so the frontend uses the address TDK gives it. -
Secrets are in the code. Move them to the environment and add the file to
.gitignore. - The API runs migrations on start. Move them to a separate step.
- A service has no health route. Add one before you rely on readiness output.
Summary
Ask Lovable for separate services, a health route on each, migrations in their own step, configuration from the environment, and tests you can run. Then export the code, describe each service to TDK, dry-run the plan, and check readiness. The prompts make the app easy to run, and TDK makes the running part repeatable.
Top comments (0)