An app isn’t an invisible workflow: there’s a user on the other end. The diagram below shows the cycle that repeats with every interaction — the browser (frontend) sends a request, the server (backend) processes it and returns a response, and the screen updates.
Illustrative diagram — conceptual recreation of the request/response cycle, not a real screenshot.
🪟 Background vs. Visible
Until now, what you built ran in the background: workflows and scripts triggered by a schedule or event, with no one watching. A app is the opposite: it is visible — has an interface that people interact with. This track takes you from what runs invisibly to a real product on the internet, with design, authentication, and payment.
💡 The mindset shift
A full-stack app is a frontend on top of the backend you already know how to build. The practical approach is to start simple—a basic website—and iterate by adding features instead of planning everything in advance.
- •Background: workflow/script with no visible interaction.
- •Visible: an interface that other people use.
- •Anchor project: an AI Lead Qualifier—from idea to app live.
✓ Think like a product
- ✓Start with a basic website and grow it feature by feature.
- ✓Assume other people will interact with it.
- ✓Treat the frontend as part of the product, not decoration.
✗ Pitfalls
- ✗Try planning 100% of the features before publishing.
- ✗Treating an app as if it were just a workflow under the hood.
- ✗Ignore that there is now a user on the other end.
🎯 Practical tip
Start small and publish early. A simple app that's live teaches you more than a huge plan in your head — and each new feature (design, login, payment) builds on what already works.
Workflow without an interface.
An app you can interact with.
Frontend over backend.
Grow by features.
🗺️ Frontend vs. backend
O frontend is everything the user sees—buttons, images, forms, text, fonts, layout—and it runs in the browser. O backend runs in one server: holds the logic, makes HTTP requests, calls APIs, and talks to the database. You don't need to master every technical detail, but you do need to internalize this separation — it's the foundation for everything else about apps.
🖥️ Frontend (browser)
- •Buttons, forms, images, text.
- •Fonts, colors, and layout — the UX.
- •What the user touches and sees.
⚙️ Backend (server)
- •The logic and business rules.
- •HTTP requests and API calls.
- •Database connection.
🧭 Why apps differ from workflows
Workflows run in the background, without visible interaction. Apps require an interface and real-time interaction: someone clicks, waits, and sees the result. That’s why UX—ease of navigation, font readability, and layout clarity—becomes part of the product.
🎯 Practical tip
When something goes wrong, first ask yourself: is this frontend (the screen doesn't show it) or backend (the logic didn't run)? Pinpointing which side the problem is on is half the diagnosis.
Where the frontend runs.
Where the backend runs.
Part of the frontend.
The foundational mental model.
🔄 Request/response cycle
Every app runs on a continuous back-and-forth between what the user sees and what happens behind the scenes. This back-and-forth is the request/response cycle: the user clicks, a request goes to the server, the server processes it, and the response comes back to update the screen.
The four steps in the cycle
The user clicks
A frontend action (submitting a form, clicking a button) triggers the cycle.
The request goes to the server
The browser sends the data to the backend, which receives the request.
The server processes
Saves data, calls an API, or runs the logic—the behind-the-scenes work.
The response updates the UI
The backend returns the response, and the frontend redraws the screen with the result.
⏱️ Real-time interaction
This cycle is what fundamentally separates an app from a workflow: someone is waiting on the other end. Each interaction is a complete turn of the cycle — and the speed of that turn is part of the experience.
🎯 Practical tip
When describing the app to the AI, think in terms of a cycle: “when the user submits the form, send X to the backend, process Y, and show Z on the screen.” This gives the AI the exact shape of the interaction.
Start of the cycle.
Frontend → server.
Logic, API, database.
UI updates.
🎨 Design Tips
AI-generated sites tend to have a “AI-ish”: standardized layouts, colors, gradients, and hero sections. This happens because AI tends toward safe, predictable "functional design," suggested the same way to everyone. Creating something original requires consciously guiding it — with references, precise vocabulary, and specific feedback.
✗ The “AI look”
- ✗“Build a landing page” → generic result.
- ✗Gradients and hero sections identical to a thousand other sites.
- ✗Vague feedback → endless iteration cycles.
✓ Intentional direction
- ✓Use a dedicated design skill.
- ✓Provide concrete references (websites, screenshots).
- ✓Say what you liked and what to change — and why.
💡 Why AI outputs look alike
The AI optimizes for a "safe" result: what tends to work for most people. Without direction, it delivers the lowest common denominator. The good news is that it responds very well to references and vocabulary—that's exactly what the next two topics explore.
🎯 Practical tip
The first time you see the interface, say out loud what you liked and didn't like—and why. That raw feedback is the best input for the next iteration.
The AI’s default.
Shows what it wants.
Describe it precisely.
Specific, not vague.
🖼️ Design skill & references
The shortcut with the biggest visual impact is a design skill dedicated: just ask the AI to use it when generating the UI, and the result improves dramatically, even with a single prompt. Combine this with references — clone a site you like, get inspiration from galleries, and use screenshots as examples.
Three ways to elevate the UI
Ask for the design skill
When generating the interface, ask the AI to use the front-end design skill. It's the highest-impact change for the least effort.
Clone / get inspiration from galleries
Find a site you admire and ask it to clone the design; look for inspiration in galleries and component libraries.
Use screenshots as references
Upload an image to the project and ask for “something like this”—the AI uses the visual reference as a guide.
🔎 Where to find references
Design galleries and component libraries are gold mines of inspiration: tested layouts, palettes, and ready-made patterns. Instead of describing everything from scratch, show what you want — a reference is worth more than adjectives.
🎯 Practical tip
Even with a single prompt, activating the design skill makes a huge difference. To go further, pair the skill with a visual reference—the result becomes tailor-made.
Greater impact.
Copy a good website.
Inspiration ready.
Image reference.
🗣️ Design prompt language
Describe the interface with accuracy is what turns a generic request into an intentional design. Instead of "make it look nice," you name layout, components, and visual tone — and, when iterating, give specific feedback instead of saying "that's wrong".
# Layout Header fixo: logo à esquerda, links de nav à direita. Botão de CTA com glow azul no canto direito. # Hero Texto grande e bold, subtítulo curto, um CTA primário. # Tom visual Escuro, premium, com um acento âmbar e bastante respiro.
✓ Describe precisely
- ✓Layout: placement of the header, nav, hero, and sections.
- ✓Components: cards, buttons, forms, states.
- ✓Visual tone: palette, font weight, density.
✗ Avoid Being Vague
- ✗“Make it look nice” / “modern” without details.
- ✗“It’s wrong” instead of saying what and why.
- ✗Changing everything at once without isolating what hasn’t been changed.
🎯 Practical tip
When iterating, use the formula “I liked X, but change Y because Z.” Feedback like this is actionable; “I didn't like it” forces the AI to guess and leads to more rounds than fixes.
Where everything goes.
Cards, buttons, forms.
Palette and weight.
I liked it / change it / why.
🚀 Building the AI Lead Qualifier
The anchor project is a full-stack app for lead qualification: the backend (workflow) runs on Trigger.dev and the frontend in Vercel, connected so anyone with the URL can use the workflow. The goal is to go from a simple prompt to a published app quickly.
From prompt to published app
Plan in Plan Mode
Describe the app (backend on Trigger.dev, frontend on Vercel) and let the AI generate the CLAUDE.md and base structure before coding.
Generate workflow + Trigger.dev config
The AI creates the qualification workflow, the deployment instructions, and the trigger.config.ts; paste the project ID/reference.
Backend deployment (dev + production)
Deploy the task to the development and production environments; add the AI API key as an env var in Trigger.dev (ideally, use separate keys).
Generate and publish the frontend on Vercel
Generate the UI with the design skill and deploy it on Vercel — the site is accessible from anywhere, with auto-deploy on every push.
📊 The result
A form submits company data → the AI analyzes it → displays a score (e.g., 68/100, "lukewarm lead"), a summary, a score breakdown, and suggested next steps — with the corresponding execution appearing in Trigger.dev runs.
⚠️ Attention
- ✗Don’t paste secret keys into chat—ask where to find them and set them up yourself as environment variables.
- ✗Don’t forget to promote the task to the production (not just dev).
Backend / workflow.
Published frontend.
CLAUDE.md + base.
User-facing result.
🔗 Connecting frontend ↔ backend
With the backend on Trigger.dev and the frontend on Vercel, all that's left is to connect them. The connection is made through environment variables: you add the secret key of Trigger.dev as an env var in Vercel, and the frontend starts communicating with the logic. Every push to GitHub triggers an automatic deploy—the site stays up to date.
✓ How to connect
- ✓Get the Trigger.dev secret key (ask where it is).
- ✓Add it as an env var in Vercel and redeploy.
- ✓Trust auto-deploy on every push to GitHub.
✗ Don’t
- ✗Paste the secret key into the chat or version-controlled code.
- ✗Forget to redeploy after adding the environment variable.
- ✗Confuse the development environment with production.
🎯 Practical tip
Think of env vars as the "outlet" between the frontend and backend: the code never contains the secret; it only reads from a variable stored on the platform. Changing the key means changing the variable—without touching the code.
Self-healing (optional): how does the frontend on Vercel connect to the backend on Trigger.dev?
📌 Module Summary
Next Module:
4.2 — Real Production: Auth, Security, Payments & Integration