# What's an app?
import { YouTubeLite } from '@/components/YouTubeLite'
import { Quiz } from '@/components/Quiz'
Concept
\~5 min
Software is all around us. From the alarm clock that wakes us up in the morning, to the social media site that connects us to our loved ones, to the web browsers you're reading this on! An application, or **app**, is software designed to perform a specific task for a specific type of person.
For decades, building software required specialized education and professional training. This meant it was a power that was limited to a select few. Today, due to rapid advancements in AI technology, creating apps is more accessible than ever. But accessible doesn't mean effortless. Like anything worth making, great software still requires patience, dedication, and craft. The difference? Now you can automate boring tasks, visualize complex data, build games, or solve problems at work - without waiting for someone else to do it for you.
Apps have many interconnected pieces
Building great software requires patience and dedication
Today, with AI, it's sometimes faster to build exactly what you need than wrestle with a tool that almost works.
You may be wondering why you should create an app at all, versus use existing tools like Google Sheets or Notion. Making your own app is useful when:
1. You want it YOUR way -- custom and specific tools built unique to you
2. You've hit the limits of existing tools
3. You want a repeatable, consistent (and maybe profitable!) solution to a recurring problem
Let's run through some apps that are possible to create on Replit:
The takeaway: with AI-powered development, the barrier between having an idea and building a working app has never been lower. Whether it's a creative visualization, a productivity tool, or something entirely unique to your needs, you can bring it to life without years of coding experience.
# Introduction to AI
import { YouTubeLite } from '@/components/YouTubeLite'
import { PromptCompareQuiz } from '@/components/Quiz'
import { LLMDemo } from '@/components/LLMDemo'
Concept
\~6 min
Now that you've seen a glimpse of what's possible on Replit, let's take a quick look under the hood. What actually powers Replit Agent and most chat-based AI tools you use today?
These tools are powered by **Large Language Models, or LLMs** - systems trained on huge amounts of text from the internet, books, code, and even conversations with humans! Over time, we've trained these statistical models to recognize patterns in how humans write, think, and solve problems.
Think of an LLM like a super-charged autocomplete. When you ask a question or give it a prompt, it predicts the next most likely word, one **token** at a time, based on everything it has learned. A token is a fundamental unit of text that the model uses to process language. It could be a whole word like "cat," part of a word like "ing," or even a single character.
These days, the predictions have become extremely fast, accurate, and organized to make LLMs very powerful.
If you ask an LLM the same question twice, you might notice the answers are a little different each time. This is caused by natural variance, or **non-determinism**, in the model's training data. Each time an LLM responds, it predicts and evaluates many possible options for the next token, a bit like rolling weighted dice. Sometimes one option will be weighted more than the others. This can lead LLMs to make mistakes or sound robotic, but this same quality also makes AI great at creative tasks.
Deterministic:
Every can is identical
Non-deterministic:
Each apple is unique
The quality of the input into an LLM will also dictate the quality of the output. Providing necessary context, being specific, and adding constraints can help ensure the **model** does what you expect it to.
LLMs are typically reactive, meaning they require some input or question and then respond. An **agent** on the other hand, is software that enables LLMs to use predefined tools and resources to solve problems or accomplish tasks in multiple steps.
While LLMs and agents are powerful, they're not perfect. They can hallucinate (make things up when they don't know the answer), be biased based on the training data, or misinterpret your instructions. That's why even when using AI, we need to be diligent in testing and quality control to make sure what we create meets our standards.
# What is vibe coding?
import { YouTubeLite } from '@/components/YouTubeLite'
import { PromptTransformQuiz } from '@/components/Quiz'
import { VibeCodeDefinition } from '@/components/VibeCodeDefinition'
Concept
\~5 min
By now, you've seen that AI can answer questions, and even help you generate code. But how do you actually work with it? That's where **vibe coding** comes in.
Vibe coding is a new way of creating software - you describe what you want in plain language, and then work with Replit Agent until you've built what you're looking for. It's a new way to be creative and explore your ideas, without worrying about the code and complexity behind them.
When you're vibe coding, you're working with the AI - treating it like a creative partner rather than an answer machine.
The vibe coding mindset: describe → critique → iterate [#the-vibe-coding-mindset-describe--critique--iterate]
Think of it like a painter at work. They start with a clear vision of what they want to create. They gather their tools (canvas, brushes, paints). Then they begin, making marks, stepping back to look, adjusting strokes that don't feel right. Some attempts fail. Some details need to be reworked. But with each iteration, they whittle away at the gap between their vision and reality.
Vibe coding works the same way:
1. **Describe and plan:** Tell the AI what you want to build and why.
2. **Critique:** Look at what it gives you. What works? What's off?
3. **Iterate:** Refine your prompt or direction until it aligns with your vision.
Don't just accept the first result. Shape it through feedback and iteration, like an artist refining their work.
Describe:Study the subject
Critique:Create rough sketch
Iterate:Polish the details
You now have the mindset of a vibe coder: describe what you want, critique the results, and iterate until it's right. In the next lesson, you'll put this into practice by building your first real app on Replit.
# Your first app
import { YouTubeLite } from '@/components/YouTubeLite'
import { MultiStepQuiz } from '@/components/Quiz'
import { PromptAnatomy } from '@/components/PromptAnatomy'
import { BuildYoursForm } from '@/components/BuildYoursForm'
import { AppTypeToggle } from '@/components/LessonInlineComponents'
Hands-on
\~15 min
You've learned what apps are, how AI works, and the describe-critique-iterate approach of vibe coding. Now it's time to put it all together and build something real - a portfolio website using **Design Mode**.
Getting started on Replit [#getting-started-on-replit]
If you haven't already, head to [replit.com](https://replit.com?utm_source=replit-learn\&utm_medium=referral\&utm_campaign=learn-platform\&utm_content=lesson4-getting-started) and create an account. Once you're in, you'll see the Replit homepage - your launchpad for building.
Describe: Your first prompt [#describe-your-first-prompt]
Remember the vibe coding approach from the last lesson? It starts with **describe** - telling the AI what you want. Let's put that into practice by building a portfolio website.
Before you start, take a moment to think about what you actually want. Good prompts come from clear thinking - not templates.
Ask yourself:
* **Who are you?** A designer? A student? Someone switching careers?
* **What's the goal?** Showcase projects? Land a job? Share your work with friends?
* **What style fits you?** Minimal and clean? Bold and colorful? Professional and polished?
Write your prompt in your own words. Be specific about what matters to you. The more thought you put in, the better your result will be.
> Think critically about the instructions you give AI. Make sure they align with your goals and are specific enough to get the outcome you want.
Once you have your prompt, head to [replit.com](https://replit.com?utm_source=replit-learn\&utm_medium=referral\&utm_campaign=learn-platform\&utm_content=lesson4-first-prompt), select the **Design** tab, paste your prompt into the input box, and click **Start**. Agent will take it from there.
Design Mode vs. Build Mode [#design-mode-vs-build-mode]
On Replit, there are two ways to start building - each suited to a different type of app:
* **Design Mode** creates **static apps** - sites that run entirely in the browser. Perfect for portfolios, landing pages, and simple tools. Everything happens on the user's device, no server needed.
* **Build Mode** creates **fullstack apps** - with both a frontend (what users see) and a backend (a server that handles data). Use Build Mode when you need user accounts, databases, or connections to external services.
The Workspace [#the-workspace]
Once Agent starts building, you'll enter the Workspace - your all-in-one environment for creating, editing, and publishing apps. Everything runs in the cloud on Replit. There's nothing to install, nothing to configure. Just open your browser and start building.
The URL you see in the Preview pane is a live page - you can open it on your desktop, scan a QR code and view it on your phone, or share it with someone else. Your app is already running on the internet, even while you're still building it. We'll explore more about this environment throughout the course.
Here's what you'll find in the Workspace:
* **Chat**: Your ongoing conversation with Agent. Ask questions, request changes, or give feedback here.
* **Preview**: A live view of your app as it's being built. Interact with it just like a real website - because it is one.
* **Visual Editor**: Select elements directly in Preview to modify text, images, colors, and spacing - no code required.
* **Files**: The code and assets that power your app. You don't need to touch these, but they're there if you want to explore.
Critique and iterate: Polishing your design [#critique-and-iterate-polishing-your-design]
Your first result probably won't be perfect - and that's expected. This is where the next two steps of vibe coding come in: **critique** and **iterate**.
Look at what Agent created with fresh eyes. What works? What doesn't? Be specific about what you want changed - use Visual Editor to click on elements and adjust them directly, or chat with Agent to describe the changes.
Think like a builder when giving feedback:
* "Make the heading larger and add more space below it"
* "Change the background to a lighter shade of gray"
* "The font feels too formal - try something more modern"
Each round of feedback is one cycle through describe-critique-iterate. The more cycles you do, the closer you get to what you envisioned. Don't expect perfection on the first try - expect progress with each iteration.
Publishing your app [#publishing-your-app]
When your portfolio looks the way you want, it's time to share it with the world. Select the **Publish** button in the upper-right corner of the Workspace. Replit handles all the technical details - servers, security, and scaling.
Within seconds, your app will be live at a unique URL that you can share with anyone. That's it - you've built and published your first app.
What's next? [#whats-next]
You've just gone from idea to live app. In the next lesson, we'll explore Build Mode and learn how to add real functionality - like databases and user accounts - to your projects.
# What makes an idea buildable?
import { YouTubeLite } from '@/components/YouTubeLite'
import { MultiStepQuiz } from '@/components/Quiz'
import { ThreeLevelsGraphic, BuildabilityTest } from '@/components/LessonInlineComponents'
Concept
\~4 min
Every great app started as a simple idea. But how do you know if your idea is buildable? The difference between ideas that ship and ideas that stay stuck in your head comes down to scope.
First make it work, then make it better [#first-make-it-work-then-make-it-better]
This is exactly how professional engineers approach building software. They start with the simplest possible version running on their own computer. They tinker, test, and get something working that solves their specific problem. Then they build on that foundation.
Apps like LinkedIn and Uber weren't built overnight - they started simple and evolved over years with hundreds of people. Your goal isn't to build the finished product. It's to build something that works first.
**One thing to get right early: design.** The look and feel of your app is something you can dial in before you start adding features. It's easy to change colors and layout upfront, but harder once you've built a lot of functionality on top.
Cutting scope in action [#cutting-scope-in-action]
Say you have an idea: "I want to connect with other dog owners in my neighborhood." That's a starting point, but it's vague. You could build a full social network with messaging, photo sharing, event planning, and a marketplace - basically Instagram + Eventbrite + Etsy combined. That's three companies worth of features.
The best builders are ruthless editors. Cut it down to the simplest thing that works: a page where neighbors can list their dog's name and contact info. One sentence, one problem, buildable in an afternoon.
✕
Too big
"A social network for dog owners with messaging, photo sharing, event planning, and a marketplace."
✓
Just right
"A page where dog owners in my neighborhood can list their dog's name and their contact info."
What's next? [#whats-next]
A buildable idea is small, focused, and clear. In the next lesson, you'll use a scoping worksheet to turn your idea into an MVP spec - the blueprint for what you're going to build.
# Scope your next project
import { YouTubeLite } from '@/components/YouTubeLite'
import { Quiz } from '@/components/Quiz'
import { ScopingWorksheet } from '@/components/ScopingWorksheet'
import { RecipeExampleCard, SpecChecklist } from '@/components/LessonInlineComponents'
Hands-on
\~5 min
Now it's your turn. You've learned what makes an idea buildable - start small, solve one problem, and keep it focused. In this lesson, you'll take that knowledge and put it into practice by scoping your own project.
The goal here isn't to come up with the perfect idea. It's to practice the skill of narrowing down a vague concept into something you can actually build. Even if you never build this exact project, the exercise itself is valuable.
Scope your project [#scope-your-project]
Use the worksheet below to think through your idea. Answer each question honestly - if you find yourself writing paragraphs, that's a sign you need to simplify. The constraint is the point.
Remember: this isn't a test. There's no wrong answer. The worksheet is a thinking tool that helps you translate a fuzzy idea into a clear direction. When you're done, you'll have a spec you can copy and paste directly into the AI.
Don't have a project in mind? No problem. Practice with any idea - even "a simple to-do list" will teach you the process. The skill you're building is narrowing scope, not choosing the perfect idea.
Example: Recipe Saver [#example-recipe-saver]
Here's a completed worksheet for a recipe app. Notice how it captures the core idea without overcomplicating things.
What's next? [#whats-next]
Hold onto your spec - you're going to build this. In the next lesson, you'll learn to break it into smaller pieces. Then, you'll actually build it with AI.
Check your spec [#check-your-spec]
Before you move on, make sure your spec answers these four questions:
# Build your idea
import { YouTubeLite } from '@/components/YouTubeLite'
import { MultiStepQuiz } from '@/components/Quiz'
import { BuildProgressTracker, IterationExample } from '@/components/LessonInlineComponents'
Hands-on
\~15 min
You have a spec. You know what you're building, who it's for, and what "done" looks like. Now comes the moment of truth - actually building it.
This lesson is different from the others. It's less about learning concepts and more about doing the work. You'll take your spec from Lesson 6 and turn it into a working app. Along the way, you'll practice the most important skill in building: iterating until it's right.
Start with your spec [#start-with-your-spec]
Go back to Lesson 6 and copy your completed spec. If you used the worksheet, click "Open in Replit" to launch directly with your spec pre-filled. If you wrote it somewhere else, copy and paste it into Agent's chat.
Your spec is your north star. Every decision you make during the build should tie back to it. When you're tempted to add features or change direction, ask yourself: "Is this in my spec? Does it serve my definition of done?"
First decision: Design Mode or Build Mode? If your app needs to save data, has user accounts, or connects to external services, choose Build Mode. If it's a static site or runs entirely in the browser, Design Mode is simpler.
Build incrementally [#build-incrementally]
Here's a mistake new builders make: they paste their whole spec and expect perfection on the first try. That's not how building works. Even with AI, creating something good takes multiple passes.
Start with the core. What's the one thing your app absolutely must do? Get that working first. If you're building a recipe saver, make sure you can save and view a recipe before worrying about search or categories. If you're building a workout tracker, nail the basic logging before adding charts.
Each feature you add is a chance to test, refine, and make sure the foundation is solid. This is how professional engineers build - one working piece at a time.
The iteration loop [#the-iteration-loop]
Remember describe-critique-iterate from Lesson 3? This is where it becomes real. After Agent generates something, your job is to:
1. **Test it thoroughly.** Click every button. Try edge cases. Use it like a real user would.
2. **Notice what's off.** Too cramped? Wrong color? Missing feedback? Write it down.
3. **Give specific feedback.** "Make it better" is vague. "Add more padding between cards and change the button color to blue" is actionable.
Most apps take 3-5 rounds of iteration to feel right. Don't get discouraged if the first version isn't perfect - that's normal. Each round gets you closer.
When things go wrong [#when-things-go-wrong]
Something will break. A button won't work. Data won't save. The layout will look wrong on your phone. This is normal - it happens to every builder, every time.
When you hit a problem, describe it clearly to Agent:
* **What you expected:** "When I click Save, the recipe should appear in my list"
* **What happened instead:** "The page refreshes but the recipe doesn't show up"
* **Steps to reproduce:** "Fill out the form, click Save, check the recipe list"
The more specific you are, the faster Agent can fix it. Vague complaints lead to vague fixes.
> Stuck on the same issue after several attempts? Try a different approach: ask Agent to explain what's happening, or simplify the feature temporarily. Sometimes the best way forward is to step back.
Publish and share [#publish-and-share]
When your app meets your definition of done - when it does what your spec says it should do - it's time to publish. Click the **Publish** button in the Workspace. Within seconds, your app will be live with a URL you can share.
This is the moment most people never reach. They plan forever, tinker endlessly, or abandon projects halfway through. By publishing, you've done something most people only talk about: you shipped.
Share it. Post it somewhere. Tell a friend. The feedback you get from real users is worth more than weeks of solo iteration.
What's next? [#whats-next]
You've finished AI Foundations. You know what apps are, how AI works, and how to scope and build an idea. That's more than most people ever learn.
But here's the truth: you learn to build by building, not by reading. The lessons ahead will make more sense after you've wrestled with a real project. Your second app will be better than your first. Your tenth will be dramatically better.
So before you continue, go build something. It doesn't have to be big or perfect - it just has to be yours. Come back when you've shipped, and you'll be ready for what's next.
# Replit for Designers
import { WistiaEmbed } from '@/components/WistiaEmbed'
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
In most teams, there are two sources of truth: what's in Figma and what's in the codebase, which tend to drift apart. Adherence depends on manual iteration between designers and engineers as the project is handed back and forth. In Replit, designers and engineers work in the same project simultaneously, and the design system (both the visual guidelines and the required code components) can be enforced by the system so that projects do not drift from the original design.
Where to start [#where-to-start]
The most common reaction designers have is: "This is powerful, but what do I even do first?" Our recommendation is to pull in your existing project materials: grab your PRD from Google Docs, mockups from Figma, and handoff specs from your engineers, and bring them into the Canvas. From there, you can organize your project and begin iterating.
Capabilities [#capabilities]
1. **Describe what you need.** Tell the agent what you're building ("create a job marketplace that connects creative AI talent with companies") and it generates a working prototype.
2. **Iterate on the Canvas.** The Canvas is an infinite surface where design and code exist together. The agent generates multiple variants of any page, and you select a direction and refine it ("make this more premium looking"). Adjusting a color or resizing a component updates the code, and code changes are reflected back on the Canvas.
3. **Make precise visual adjustments.** Colors, typography, and spacing can be changed using design controls on the right side of the Canvas, with changes applied directly to the running UI.
4. **Import from Figma.** Connecting your Figma file lets the agent generate working code from your existing designs, including your layouts, components, and tokens.
5. **Bring your design system.** You can encode your component library, usage rules, and brand guidelines into an agent skill, which is a persistent set of instructions the agent follows on every build. This is covered in depth in the next lesson.
6. **Build complex features in parallel.** You can request a 3D globe animation or interactive data visualization and continue designing other parts of the prototype while the agent implements it.
7. **Collaborate in real time.** Multiple designers, PMs, and engineers can work in the same project simultaneously, editing and reviewing together in a shared environment.
What designers have built [#what-designers-have-built]
A motion designer at a large consumer app company built an automation connecting multiple APIs that eliminated external localization agencies for 28 languages across 3 video formats, reducing annual spend by over $1M. At a creative services company, a designer built a script-to-storyboard pipeline that previously required engineering support. At a large real estate technology company, designers now bring working Replit prototypes to design reviews instead of static mockups, cutting the feedback loop from weeks to hours.
Open Replit, bring in your project materials, and start iterating.
Extended walkthrough: the Canvas design workflow [#extended-walkthrough-the-canvas-design-workflow]
# Making Graduation Repeatable with GitHub Actions
import { Quiz } from '@/components/Quiz'
Enterprise
\~6 min
Lesson 8 described the production handoff in general terms, where the agent generates deployment artifacts and an operations team provisions the database and secrets. This lesson covers a more automated path, for teams that standardize on GitHub Actions and require their applications to run on company-controlled infrastructure and databases rather than on Replit's native Deployments. The goal is to keep engineers out of the critical path of everyday app building, so that adding an application or a builder does not add engineering work. Engineering configures shared infrastructure once, and from that point a builder ships by asking the agent to prepare the application and pushing to the main branch.
The design rests on one principle: the deployment pipeline is fixed and owned by engineering, and the only thing that varies per application is a small file that an agent skill writes. A reusable GitHub Actions workflow holds all the deployment logic and is identical for every application. Each application carries a short file that calls it. Because the reusable workflow cannot be edited from inside an application, builders cannot alter the pipeline, and engineering retains control of how every release is built and shipped.
The recommended stack [#the-recommended-stack]
Standardizing the stack is what makes a single fixed workflow possible. Applications the agent builds default to a TypeScript and Node runtime with a PostgreSQL database, and Drizzle as the schema and migration layer. When every application follows this convention, one migration step, `drizzle-kit migrate`, applies to all of them, and the reusable workflow needs no per-application branching to handle migrations. Teams can support additional stacks, but each additional convention adds a corresponding path to the workflow, so most organizations standardize on one.
The fixed reusable workflow [#the-fixed-reusable-workflow]
Engineering writes this once in the organization's central repository. It accepts typed inputs and contains the deployment logic that every application runs at release:
* Authenticate to your cloud using short-lived credentials.
* Build and publish a container image labeled with the commit.
* Prepare the application's data layer according to its inputs.
* Release the new version.
The inputs are the only way an application influences what the workflow does:
* `app_name` names the image, the database, and the deployed service.
* `data_source` selects how the data layer is prepared: `provision`, `connector`, or `none`.
* `connector_name` names an approved data source when `data_source` is `connector`.
```yaml
# .github/workflows/deploy-reusable.yml (in the org's central repo)
on:
workflow_call:
inputs:
app_name:
required: true
type: string
data_source:
required: false
type: string
default: provision
connector_name:
required: false
type: string
default: ""
permissions:
contents: read
id-token: write # exchange for short-lived cloud credentials
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Authenticate to cloud (OIDC)
run: |
echo "Use your cloud's login action with the org's workload identity."
- name: Build and publish image
run: |
echo "docker build and push, tagged with ${{ github.sha }}"
- name: Provision database
if: ${{ inputs.data_source == 'provision' }}
env:
ADMIN_DB_URL: ${{ secrets.SHARED_PG_ADMIN_URL }}
run: |
# Create the app's database and least-privilege role if absent,
# using ADMIN_DB_URL, then assemble the scoped connection string.
APP_DATABASE_URL="$(./scripts/ensure-database.sh "${{ inputs.app_name }}")"
echo "::add-mask::$APP_DATABASE_URL"
echo "DATABASE_URL=$APP_DATABASE_URL" >> "$GITHUB_ENV"
- name: Apply migrations
if: ${{ inputs.data_source == 'provision' }}
run: npx drizzle-kit migrate
- name: Deploy
run: |
echo "Release ${{ inputs.app_name }} to your cloud."
```
What the skill decides [#what-the-skill-decides]
The platform or infrastructure team writes one agent skill that encodes these choices. A builder never sets an input or opens a workflow file. They ask the agent to prepare the application for deployment, for example by saying "get this ready for deploy via GitHub," and the skill performs the per-application work:
* Determine the data source the application uses.
* Confirm migrations follow the Drizzle convention.
* Write the calling workflow file with the matching inputs.
* Commit it so the next push to the main branch deploys.
```yaml
# .github/workflows/deploy.yml (written into each app by the skill)
name: Deploy
on:
push:
branches: [main]
permissions:
contents: read
id-token: write
jobs:
deploy:
uses: your-org/.github/.github/workflows/deploy-reusable.yml@main
with:
app_name: vendor-intake
data_source: provision
secrets: inherit
```
Handling different data sources [#handling-different-data-sources]
The `data_source` input covers the cases an application falls into. An application that uses the database Replit provisions in development sets `provision`, and the workflow creates a database for it on the shared server if one does not exist, applies migrations, and gives the running application a least-privilege credential scoped to that database. An application that reads from a source the organization has already approved sets `connector` with the name of that source, and the workflow maps the name to a specific organization secret from a fixed allowlist. The workflow never accepts a raw connection string from an application, so a builder cannot point a deployment at an unapproved system. An application with no database sets `none`.
Where the automation boundary sits [#where-the-automation-boundary-sits]
How much a release automates depends on what the skill and the workflow are allowed to do. Because migrations run inside the workflow, a routine release that adds a column or a table deploys itself with no engineering involvement, which reaches further than a manual handoff does. What remains with engineering is the shared infrastructure and the allowlists the automation draws on. Adding a new organization secret, approving a new external connector, or extending the shared server's capacity is a deliberate change to the fixed parts of the system, and the team makes it once for everyone rather than once per application.
Write the reusable workflow and the deployment skill once for your standard stack, then have a builder ask the agent to prepare an application for GitHub deployment and confirm it ships on the next push to the main branch.
# Encoding Your Design System
import { WistiaEmbed } from '@/components/WistiaEmbed'
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
Today, your design system lives in many different places (e.g., visual layouts live in Figma, but the code components are dictated by Storybook) and adherence depends on iteration as the project is handed back and forth between designers and engineers. In Replit, designers and engineers work in the same project simultaneously, and both the visual guidelines and the required code components can be enforced by the system under the hood. The mechanism for this is an agent skill: a persistent set of instructions, stored in the project, that the agent follows automatically on every build.
What a skill contains [#what-a-skill-contains]
A skill is a markdown file stored in the project that can include any combination of the following:
* **Component library.** Imported as a tar file from Figma, Storybook, or a component playground, so the agent builds using only those components.
* **Component usage rules.** Guidelines for when to use a checkbox vs. a toggle, when to use a modal vs. inline editing, and which variants are appropriate for which contexts.
* **Content and tone guidelines.** Sentence case vs. title case, voice and tone rules, and writing standards organized by app type.
* **Visual guidelines.** Color tokens, spacing rules, typography scales, and layout patterns (e.g., "if the app is a dashboard, the sidebar should follow this structure").
* **Brand assets.** Logos, fonts, and icon sets.
How it works in practice [#how-it-works-in-practice]
Without a skill, the agent makes probabilistic decisions about layout, component selection, and styling, which means giving the same prompt twice may produce different results. With a skill, those decisions become deterministic because the agent follows the encoded rules every time. When someone on your team prompts the agent, the relevant skill loads automatically, so there is no need to reference it manually or re-explain brand guidelines at the start of each session.
You do not need a complete library to start [#you-do-not-need-a-complete-library-to-start]
Teams that are building their design system incrementally can add components and rules as they go. When you add new components and update the skill with their usage rules, the agent picks them up on the next build, so the skill grows alongside your system.
Existing documentation works [#existing-documentation-works]
If your team already maintains documentation in zeroheight, Storybook, or internal wikis, you can feed that directly into a skill. The agent interprets human-written documentation and follows it, so you do not need to rewrite your guidelines in a special format.
What teams have built [#what-teams-have-built]
One enterprise team imported their full component library and achieved near-complete design system compliance across every prototype the agent produced. Another team built a live component playground in Replit (equivalent to a Storybook instance) where designers can select components, toggle variants and modes, and copy selections directly to the agent.
Export your component library, gather your usage and content guidelines, and ask your Replit team to create your first design system skill.
# Replit for Product Managers
import { WistiaEmbed } from '@/components/WistiaEmbed'
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
Most of a PM's day is spent coordinating work rather than shaping it. You write the spec, hand it to design, wait for mockups, hand those to engineering, wait for a build, then review something that may not match what you described. Each handoff is a translation step where meaning gets lost, and the PM becomes the bottleneck connecting all the pieces. In Replit, everyone works in the same environment at the same time, so coordination happens through the product itself rather than through meetings and documents.
Where to start [#where-to-start]
The most effective first move is to paste your current PRD or project brief and ask the agent to generate a first pass. Within minutes you have a working prototype you can iterate on, rather than a document you need to shepherd through three teams. From there, you refine directly: adjust the UI, add features, and share the running application with stakeholders instead of scheduling a review meeting.
Capabilities [#capabilities]
1. **Plan Mode.** Before the agent changes anything, it outlines what it intends to do. You review the plan, approve or adjust it, and then it executes. This gives you the same "approve before build" control you have in sprint planning, but at the speed of a conversation. If the plan includes work you want to defer, you remove it before the agent starts.
2. **Real-time collaboration.** Designers, engineers, and PMs work in the same project simultaneously with visible cursors, similar to collaborating in Google Docs. One engineer can submit a payments integration while another submits onboarding while you queue a slide deck, and all three run concurrently.
3. **Task board and review queue.** Every person's work shows up as a task on a shared board. You can see what is in progress, who submitted the request, and what is ready for review. When a task is complete, you approve it and it merges into the main application, or you send it back with feedback.
4. **Multi-artifact output.** PMs do not just ship features; they ship decks, docs, and dashboards alongside the product. From the same project, you can generate a working prototype and then ask the agent to create a stakeholder presentation explaining it, all sharing the same context. Nothing gets lost in the "translate what we built into a format leadership understands" step.
5. **Queue.** You can stack multiple instructions while the agent processes earlier tasks. Instead of waiting for one feature to finish before describing the next, you queue an entire sprint's worth of requests and let them execute.
6. **Connected services.** The agent can query and take action in tools your team already uses (BigQuery, Linear, Slack, Notion) directly from chat, so you do not need to context-switch to pull data or update tickets.
From managing conversations to managing the product [#from-managing-conversations-to-managing-the-product]
The traditional PM workflow involves translating between disciplines: turning stakeholder requests into specs, turning specs into tickets, and then reconciling the output with the original intent. When your team works in a shared environment, you skip the translation. A stakeholder request becomes a prompt that produces a working prototype in minutes. Instead of describing what you want in a document and hoping it survives two handoffs, you show a working version and iterate from there. The conversation shifts from "here is what I meant" to "here is what we have, what should we change?"
What makes the review workflow different [#what-makes-the-review-workflow-different]
You are reviewing working software. When you approve a task in the review queue, you are approving the artifact that ships. This is the structural change that eliminates the "it does not match the spec" problem: the spec and the implementation are the same artifact.
What PMs have built [#what-pms-have-built]
One large technology company made it company policy to bring working Replit prototypes to meetings instead of 10-page PRDs. At a consumer health company, the product team validated 8 out of 100 backlogged ideas in three weeks by building working prototypes instead of writing specs, then handed engineering working code rather than static wireframes.
Paste your current PRD into Replit and ask the agent to generate a first pass.
# Managing Projects Efficiently with Parallelism
import { WistiaEmbed } from '@/components/WistiaEmbed'
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
Traditional project management assumes a fixed capacity constraint: your team can build a limited number of things per sprint, so the PM's job is to decide which features make the cut. Parallelism removes that constraint. Instead of choosing between three features, you start all three simultaneously, evaluate the results, and decide which to ship based on working software rather than estimates. The question changes from "what should we build this sprint?" to "which of these working prototypes should we ship?"
How parallel execution works [#how-parallel-execution-works]
When you describe a feature, an orchestrator agent receives the request and breaks it into discrete tasks. Each task gets assigned to its own task agent with a full, isolated copy of the project, so multiple agents can build different parts of the same application simultaneously without interfering with each other. One person submits a payments integration, another submits an onboarding flow, a PM queues a stakeholder slide deck, and all three run concurrently in isolated environments.
This is different from simply having more developers work on the same codebase. Each task agent operates on its own fork of the project, the orchestrator understands the dependencies between tasks and sequences them intelligently, and a merge agent resolves conflicts automatically before applying changes to the main application. You never see a merge conflict. You see completed work ready for review.
What parallelism changes about planning [#what-parallelism-changes-about-planning]
When the cost of exploring an idea drops to the time it takes to describe it, the economics of prioritization shift fundamentally. In a traditional sprint planning process, you invest significant effort in estimation and sequencing because building the wrong thing is expensive. With parallel agents, building a prototype costs minutes instead of weeks, so you can validate ideas before committing engineering resources to them.
This also changes how you handle your backlog. Instead of a ranked list of features waiting for capacity, the backlog becomes a source of hypotheses you can test rapidly. You can prototype multiple directions concurrently, evaluate the results with real users, and hand engineering working code rather than static wireframes.
Multi-artifact parallelism [#multi-artifact-parallelism]
Parallelism is not limited to building multiple features. From the same project, you can simultaneously run a web application, a data dashboard, and a training deck for stakeholders, all sharing the same context. At a communications platform company, a team used parallel agents to build a headcount capacity app in 2 days that previously required 2 weeks of engineering time, producing the application and supporting documentation concurrently from the same project.
Where to start [#where-to-start]
Pick the three features at the top of your backlog. Describe each one in its own thread. Let them build in parallel while you move on to your next meeting.
# Replit for Citizen Developers
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
Most organizations run on processes that no one has built software for: expense approvals routed through email threads, vendor onboarding tracked in a shared spreadsheet, support escalation managed in Slack with tribal knowledge about who handles what. These workflows exist because the people who own them cannot build software, and the engineering team has higher priorities than internal tooling.
In Replit, you describe the workflow and the agent builds the application. No ticket, no sprint slot, no engineering dependency.
Where to start [#where-to-start]
Pick the process you are most tired of managing manually. Describe it to the agent the way you would explain it to a new hire: "We get vendor applications by email. Someone on the team reviews the application, checks it against our compliance criteria, and either approves or rejects it. Approved vendors go into our master list. Right now this happens in a shared Google Sheet with a lot of manual copy-pasting." The agent generates a working application with forms, review workflows, status tracking, and notifications. You iterate from there.
Capabilities [#capabilities]
1. **Describe the workflow, get the application.** Tell the agent what your process looks like (intake, review, approval, notification) and it builds a working app with forms, logic, and data storage. You do not need to know how to code. You need to know how your process works.
2. **Built-in databases and auth.** Every app the agent builds gets a real database (not a spreadsheet pretending to be one) and authentication, so you control who can see what. Admins see everything. Reviewers see their queue. Submitters see their own requests.
3. **Connect to the tools your team already uses.** Native integrations with Slack, email, Google Workspace, Notion, Salesforce, HubSpot, and 100+ other services. "When a new request comes in, post to #ops-intake in Slack" or "when an approval is granted, send a confirmation email," described in natural language, wired by the agent.
4. **Iterate without starting over.** After the first version, you add complexity by prompting: "add an approval chain where managers approve first, then finance" or "add a dashboard showing how many requests are pending by department." Each change applies to the running application.
5. **Deploy to your team instantly.** One click to publish. Your team gets a URL, logs in, and starts using it. No infrastructure, no DevOps, no waiting. Password protection and SSO are available for enterprise teams.
What this changes for operations teams [#what-this-changes-for-operations-teams]
The traditional path for an internal tool is: identify the need, write a requirements doc, file a ticket with engineering, wait for prioritization, wait for build, review, iterate, deploy. That path takes weeks to months, and most internal tool requests never make it through the queue because they cannot compete with customer-facing product work.
The new path is: describe what you need, iterate on a working version, deploy it to your team. The person who owns the process builds the tool, because they are the one who actually understands the edge cases, the exceptions, and the real workflow, not the simplified version that fits in a Jira ticket.
What operations teams have built [#what-operations-teams-have-built]
At a consumer finance company, the operations team replaced a multi-tool expense management system with a single Replit-built application, saving $100K per month in SaaS costs and manual processing time. At a private equity firm, the legal team built a contract review tool that automated document analysis, saving 48 hours per week across the team.
In a workshop at another private equity firm, 30 senior managing directors built working internal tools in 90 minutes, including competitive intelligence dashboards and price comparison tools. None of them are engineers.
Pick the spreadsheet your team shares most often. Describe to the agent what that spreadsheet tracks and who does what with it. That is your first app.
# Making Sense of Your Data
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
Across an organization, different roles accumulate information that needs to be shared: a designer has user research transcripts to synthesize, a PM has customer feedback to pull themes from, a sales lead has pipeline data to visualize, an analyst has warehouse tables to turn into dashboards. In each case, turning that information into something visual, interactive, and shareable requires either engineering support or hours of manual spreadsheet and slide work.
In Replit, you describe what you want to see and where the data lives, and the agent generates a complete, interactive visualization in a single prompt. The person with the information builds the interface.
Where to start [#where-to-start]
The entry point depends on where your data lives. If you have a warehouse (BigQuery, Snowflake, or Databricks), connect it through Replit's data connectors and ask a business question: "Show me the top 10 customers by revenue this quarter with trend lines" or "What does customer churn look like by cohort over the last 12 months?" If your data is in a spreadsheet, upload the CSV or connect Google Sheets and describe what you want to see. If your information is in documents, paste it or point the agent at it and ask for a synthesis.
You do not need to specify table names, write SQL, or design a layout. Describe what you want to know, and the agent figures out the rest.
Capabilities [#capabilities]
1. **One-shot dashboard generation.** Describe your goal and data source in a single prompt, and the agent builds a complete dashboard with charts, metrics, filters, and layout. The output is a real web application (not a static report), and you refine it by prompting: "add a date range filter," "break this down by region," "add a drill-down on each row."
2. **Parallel schema exploration.** When you connect a warehouse with thousands of tables, the agent uses multiple sub-agents to explore your schema in parallel, discovering which tables are relevant, what joins are needed, and which fields map to your question. This is the difference between "I need to tell it exactly which tables to query" and "I describe what I want to know and it figures out where the data lives."
3. **Any data source.** Warehouse connectors (BigQuery, Snowflake, Databricks), PostgreSQL databases, Excel files, CSV uploads, Google Sheets, and external APIs are all supported. The spreadsheet you email around every Monday can become a live, filterable dashboard that updates when the underlying data changes.
4. **Export and sharing.** Every dashboard includes export to PDF (for the full dashboard), export to CSV (for individual chart data), and refresh controls including auto-refresh for near-real-time monitoring. You can also ask the agent to produce a detailed analysis document based on the dashboard's data, so findings reach stakeholders in whatever format they prefer.
5. **Multi-artifact projects.** A data visualization can share the same project as other artifacts connected to the same data layer. Your SLA dashboard, the alert automation that pages on-call when SLAs breach, and the quarterly executive summary can all draw from the same backend in one project, without duplicating infrastructure or re-explaining the data model.
6. **Connected services.** The agent can query and take action in tools like Slack, Notion, and Linear directly from chat. This means a dashboard can be connected to an operational workflow: "when this KPI drops below threshold, post to the #ops-alerts Slack channel."
Data safety and governance [#data-safety-and-governance]
Connector credentials are managed at the workspace level by admins, who control which connections are available and scope them by team. Credentials are not exposed to end users. Data access follows least-privilege principles, and the platform supports dev/prod separation so you can build against a development dataset before pointing at production data. The platform is SOC 2 compliant, and dashboards can be deployed with password protection or SSO gating.
What this changes [#what-this-changes]
The traditional bottleneck is the gap between having information and being able to present it. An analyst can write the query but needs engineering to build the dashboard. A PM can identify the themes in customer feedback but needs a designer to make it presentable. A sales lead can pull the pipeline data but spends hours formatting it in slides before each QBR.
Replit does not replace your warehouse or your BI tooling. What it does is let anyone with information build the interface to share it, without filing a ticket or waiting for a sprint slot. When you need a one-off analysis tool, a monitoring dashboard for your team, or a way to visualize findings for a stakeholder meeting, you build it directly.
What people have built [#what-people-have-built]
At a financial services company, an operations team member built an SLA monitoring dashboard that gave the team 10x faster access to performance data, saving approximately 96 hours per employee per year. At a large financial institution, non-technical teams achieved a 10x increase in prototype creation across departments, with analysts building their own reporting tools instead of waiting for engineering support.
Connect your data source and try: "Show me the top 10 customers by revenue this quarter with trend lines." For a full technical walkthrough, see the [Replit documentation](https://docs.replit.com/replitai/data-apps).
# Replit for Infrastructure Engineers
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
The first question infrastructure engineers ask about any new development tool is: "What does this mean for our stack?" The concern is reasonable. A platform that produces proprietary artifacts, requires a custom runtime, or bypasses your CI/CD pipeline creates operational risk. Replit produces standard, portable code with full Git history. It connects natively to your existing Git provider, pushes to a branch where your normal review and merge process applies, and requires zero involvement from your infrastructure after code leaves the platform. Nothing about your pipeline, your hosting, or your incident response needs to change.
Code portability [#code-portability]
Every Replit project is a standard Git repository. The agent makes real commits as it works, so the full history of every change is preserved from the first prompt. The code is uncompiled source: standard file trees with package manifests, configuration files, and the complete Git log. There are no proprietary artifacts, no custom runtime requirements, and no vendor lock-in in the output. Your pipeline handles the build and compile step the same way it would for code written by any engineer on your team.
Replit-specific configuration files (`.replit` and `replit.nix`) configure the development environment only. They are inert outside the platform, do not conflict with standard build tooling like Dockerfiles or CI configs, and can be excluded via `.gitignore` or stripped automatically by a skill before pushing.
Git integration and branch protection [#git-integration-and-branch-protection]
Replit integrates natively with GitHub, GitLab, and Bitbucket. Code pushes can happen continuously (every agent change is committed) or on demand. Replit pushes to a branch, and your existing branch protection rules, review requirements, and merge process apply from there. This is not a deployment platform that bypasses your pipeline. It is a development environment that produces standard code and pushes to your repo. Once code lands in your repository, your pipeline handles everything: your security scans, your build step, your test suites, your promotion flow.
In conversations with large enterprises during evaluation, the moment infrastructure teams understand this workflow, the question shifts from "is this safe?" to "how do we configure it?"
Governance and admin controls [#governance-and-admin-controls]
Enterprise admins configure governance at the organization level. These controls are enforced org-wide and cannot be overridden by individual users:
1. **Git remote requirements.** Every app must have a Git connection before it can be published, ensuring nothing gets built in isolation.
2. **Repository restrictions.** Code can be restricted to private repositories only and limited to whitelisted Git organizations, so code only flows to your approved destinations.
3. **Security scanning.** A built-in security scanner checks for vulnerabilities, exposed secrets, outdated dependencies, and potential leaks of sensitive data. Admins can require scans to pass before code can be published or pushed to Git.
4. **Source code export controls.** ZIP downloads can be disabled entirely, making Git the only path for code to leave Replit.
5. **SBOM export.** Generate Software Bill of Materials in standard formats for compliance and supply chain transparency, for individual apps or across the entire organization.
6. **Publishing visibility.** Control whether apps can be published publicly, to the workspace only, or restricted further.
7. **Spending controls.** Per-user or per-team budget limits prevent unexpected compute costs. Your cloud budget governance extends to Replit usage without requiring separate tooling.
Identity, compliance, and data governance [#identity-compliance-and-data-governance]
User provisioning is managed through your existing identity provider via SSO and SCIM (Okta, Azure AD, or equivalent). Users authenticate through your IdP, deprovisioning is automatic, and role-based access is enforced at the organization and workspace level. There are no manual invites to manage.
Replit is SOC 2 Type 2 compliant. On enterprise plans, prompts and code context are not stored or used for model training, which means zero data retention for the inputs your teams provide.
Org-wide visibility [#org-wide-visibility]
Enterprise admins have visibility into every application built across the organization: who built it, whether it is deployed, usage metrics, and cost. This directly addresses the "shadow IT" concern. When business users across departments are building applications, the infrastructure team can see everything that exists in the environment at any time, rather than discovering unmanaged applications after the fact.
Secure connectivity during development [#secure-connectivity-during-development]
While teams build in Replit, applications often need to connect to your existing data services. Replit has first-party connectors for major data warehouses (BigQuery, Snowflake, Databricks), and applications can connect to any externally accessible service over HTTPS/TLS.
For organizations that require network isolation, a single-tenant deployment option provides dedicated compute, full network isolation, and static outbound IPs that can be allowlisted on your security groups, database instances, or network policies. This option has been a key factor in moving conversations forward with financial services and healthcare organizations during evaluation.
The recommended connectivity pattern is to use a dedicated, least-privilege service account scoped to dev or staging resources, with an API gateway in front of internal resources. This means Replit sees only endpoints, never your internal network, and gives you rate limiting, firewall rules, and a single revocation point. Production credentials should never touch the development environment.
Operational model [#operational-model]
For applications deployed on Replit, hosting, SSL, uptime, and patching are managed by Replit infrastructure. Your team does not inherit operational burden: no paging, no patching, no uptime management. For applications that graduate to your own infrastructure via Git, your normal operational model applies. Many organizations use both paths, keeping internal tools on Replit while graduating customer-facing applications to their own cloud. The choice is per-application and does not require architectural changes.
Agent Skills as your control mechanism [#agent-skills-as-your-control-mechanism]
The infrastructure team's most common concern during evaluation is consistency: "How do we ensure that every application built by a non-technical user meets our deployment standards?" The answer is agent skills, which are persistent instruction sets the agent follows automatically.
A concrete example: your team requires a multi-stage Dockerfile, a GitHub Actions workflow that runs your security suite, and all secrets replaced with environment variable references. You write those requirements as a skill once. From that point on, any user in your workspace tells the agent "graduate this for production" and the agent applies your exact requirements automatically. This is more reliable than documentation, training, or code review checklists, because the enforcement happens at build time rather than after the fact.
What infrastructure teams have verified [#what-infrastructure-teams-have-verified]
A large real estate technology company adopted the platform across 7,000+ applications and 600 seats, operating within their existing infrastructure standards. A regulated financial services institution in the UK approved adoption after evaluating the governance controls, Git-native workflow, and compliance posture. In both cases, the infrastructure team's evaluation focused on the same questions this lesson covers: portability, pipeline fit, governance, and operational risk.
Map the steps between "code is ready" and "code is in production" in your current pipeline, and write those steps as a graduation skill so any Replit user in your org follows your exact process automatically.
# The Production Handoff
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
This lesson assumes your organization has already evaluated and approved Replit as a development platform. It covers the mechanics of moving an application to your own cloud. For the evaluation itself (governance, compliance, security posture, and pipeline fit), see Lesson 7.
Some teams host production applications directly on Replit. Others prefer to run production on their own cloud infrastructure through their existing CI/CD pipeline. Both paths are fully supported, and many organizations use a mix depending on the application. What follows is the graduation path: the step-by-step process of moving an application from Replit to your cloud.
The graduation lifecycle [#the-graduation-lifecycle]
The process follows four stages.
**Build.** Your teams build in Replit using natural language or code. The agent makes real Git commits as it works, so the full history of every change is preserved from the first prompt. During development, applications use the built-in PostgreSQL database, and secrets are stored in the platform's encrypted secrets manager and referenced as environment variables in code (never hardcoded).
**Review.** Before code leaves the platform, it goes through several checks. The security scanner identifies vulnerabilities, exposed secrets, outdated dependencies, and potential leaks of sensitive data. If the scan fails, the agent stops, surfaces the specific findings, and blocks the push until the issues are resolved. Automated application testing launches a real browser, navigates the application like a user, and validates functionality across UI elements, forms, and integrations. The shared task board lets team leads inspect changes and approve or reject them before merging to the main branch.
**Graduate.** This is where the application moves to your environment. The agent generates deployment artifacts for your target cloud: Dockerfiles (multi-stage, production-optimized), CI/CD workflow files for your specific platform, and cloud-specific configuration such as ECS task definitions or Cloud Run configs. It also generates an environment variable manifest listing every secret and credential the application requires, so your ops team knows exactly what to provision. Code pushes to your Git provider on a branch, and your existing PR, review, and merge process applies from there.
**Operate.** Once in your cloud, your existing operational model applies, including monitoring, alerting, patching, and on-call rotation. Replit is no longer involved in the production path. Ongoing development can continue in Replit, with changes pushing via Git and your CI/CD deploying as usual.
What travels with the code [#what-travels-with-the-code]
All source files, package manifests, configuration files, the full Git history, and any agent-generated build artifacts (Dockerfiles, CI workflow files, cloud-specific configs) travel with the code. The output is standard, uncompiled source code with no proprietary format and no custom runtime dependency. Your pipeline handles the build and compile step the same way it would for code written by any engineer on your team.
What requires separate handling: the development database contents (exported separately), development secrets (provisioned fresh in your secrets manager), and platform-specific hosting and authentication (replaced by your cloud's equivalents). Everything your pipeline needs to build and deploy the application is in the repository, and everything environment-specific is handled through your existing provisioning process.
Database migration [#database-migration]
If the application uses the built-in PostgreSQL database during development, you export the schema and data using standard PostgreSQL tooling (such as `pg_dump`) from the platform's shell, then restore into your own managed database instance. The export captures the final schema and data state, not the incremental migration history, so your DBAs receive a clean snapshot regardless of how many schema changes occurred during development.
This is the same process your team would use for any PostgreSQL migration. No proprietary export format or special tooling is required. The queries and data logic the agent writes are fully portable: update the connection string to point at your managed instance, and the application connects without code changes.
If the database export encounters an issue (an unsupported extension, a large binary column, or a schema feature specific to the platform's PostgreSQL version), the agent surfaces the specific incompatibility and suggests a resolution. In practice, development databases are small and schema-simple, so these edge cases are rare, but the tooling handles them explicitly rather than failing silently.
Secrets and credentials [#secrets-and-credentials]
Production credentials should be provisioned fresh in your own secrets manager. Development secrets are stored in the platform's encrypted secrets manager and are scoped to the development environment only. The agent references secrets as environment variables in code, never as hardcoded values, so by the time code reaches your repository, every credential is a variable reference that your deployment process populates.
To streamline provisioning, the agent generates an environment variable manifest listing every secret and credential the application requires, with descriptions of what each one is for. Your ops team can use this manifest to provision the correct values in your secrets manager (AWS Secrets Manager, Parameter Store, Azure Key Vault, or whatever you use) without needing to trace through the application code.
Cloud-specific deployment paths [#cloud-specific-deployment-paths]
The graduation workflow adapts to whichever cloud and CI/CD tooling you use:
1. **AWS.** Code flows from Git to GitHub Actions (or CodePipeline) to ECR and deploys to ECS Fargate, EKS, or Lambda. The agent can pre-generate Dockerfiles, GitHub Actions workflows, and ECS task definitions. Database exports go to RDS or Aurora, and secrets are provisioned in AWS Secrets Manager or Parameter Store.
2. **Azure.** Code flows through Azure Pipelines to Azure Container Registry and deploys to Azure App Service or AKS. The platform also supports Azure-managed deployment environments for teams that want a more integrated path.
3. **GCP.** Code flows through Cloud Build to Artifact Registry and deploys to Cloud Run or GKE. The agent can generate Cloud Build configs for serverless containers or Kubernetes deployments.
4. **Any CI/CD platform.** The pattern is the same regardless of tooling, whether Jenkins, CircleCI, GitLab CI, Buildkite, or anything else. Code lands in Git, your pipeline picks it up, and the build system handles it like code from any other source.
Ongoing iteration after graduation [#ongoing-iteration-after-graduation]
Graduation is not a one-time event. The development cycle repeats: make updates in Replit, push via Git, your CI/CD deploys. The agent works against the development environment and does not have direct access to your production database schema, cloud-specific configuration, or the secrets provisioned in your cloud. When changes require awareness of the production environment (a schema migration, a new secret, or a configuration change), your team handles those through your normal deployment process, informed by the agent's updated environment variable manifest and schema exports.
Late graduation [#late-graduation]
A common scenario: a business user builds an internal tool, deploys it on Replit, it gains traction, and six months later the infrastructure team wants to bring it into managed infrastructure. The graduation process is the same regardless of when it happens. The full Git history is preserved from the original build, the database can be exported at any point, and a graduation skill generates the same deployment artifacts whether the application is one day old or one year old. The only additional consideration is that a long-running application may have accumulated more data in its database, which means the `pg_dump` export may take longer.
Making graduation repeatable [#making-graduation-repeatable]
For organizations that want a consistent graduation process across teams, a graduation skill encodes your specific pipeline requirements into a persistent instruction set that the agent follows automatically. The infrastructure or platform team writes the skill once, and any user in the workspace can ask the agent to prepare an application for production using it. The skill handles the steps that would otherwise be a manual checklist: running the security scan, generating the Dockerfile, creating CI workflow files, replacing platform-specific services with environment variable placeholders, restructuring code to match your production layout, exporting the database schema, and generating the environment variable manifest. For teams that standardize on GitHub Actions and deploy to their own infrastructure, the final lesson in this course, Making Graduation Repeatable with GitHub Actions, shows an alternate path where a fixed reusable workflow provisions databases and applies migrations automatically rather than handing a snapshot and manifest to an operations team.
Pick an application your team has built in Replit, run a graduation skill against it, and review the output (the Dockerfile, the CI/CD workflow, the environment variable manifest) to see exactly what your pipeline would receive.
# Replit for Sensitive Data Use Cases
import { Quiz } from '@/components/Quiz'
Enterprise
\~5 min
In regulated organizations, teams need to build applications that ultimately handle sensitive data (PHI, PII, financial records, confidential documents), but the development process itself must never touch that data. This is standard practice across regulated industries. For example, healthcare developers work against synthetic patient records, financial services teams use anonymized datasets, and legal teams store confidential contracts separately from software development and staging environments.
Replit fits into this model by acting as your development environment, while your cloud handles staging and production. Your teams will build against schemas and dummy data in the development environment, and you will connect applications to real data only in your owned and siloed staging and production layers.
The three-environment model [#the-three-environment-model]
The structure follows the same separation that regulated engineering teams already use, with one important difference: Replit handles the development layer, and your cloud handles staging and production.
**Development (Replit).** Your team provides the database schema: table structures, field names, relationships, and data types, without any real records. The agent builds the application logic, queries, and interface against that schema. If you want realistic test data, you generate synthetic records that match the shape of your real data but contain no actual sensitive information. Development credentials are scoped to the Replit environment and point to empty-schema or synthetic-data instances. At this stage, the application is functionally complete but has never seen real data.
**Staging (your cloud).** When the application is ready, it graduates through your Git and CI/CD pipeline into a staging environment in your own cloud. This is where you swap the dummy data for real data connections. Your team provisions staging database credentials in your secrets manager, points the application at a staging instance of your production database (or a sanitized copy), and validates that the application behaves correctly against real schemas and data volumes.
**Production (your cloud).** Once validated in staging, the application promotes to production through your normal promotion flow. Production database credentials, encryption keys, and API keys for sensitive services are provisioned in your secrets manager. Real data flows only through infrastructure you control, with your existing compliance monitoring, access controls, and incident response in place.
At every stage, the separation is explicit: Replit handles development with no sensitive data, and your cloud handles staging and production with full data governance.
Build against the schema, not the data [#build-against-the-schema-not-the-data]
This phrase captures the core principle. Your team exports the database schema (tables, fields, relationships, constraints) without any records and brings it to Replit. The agent builds the complete application: forms, validation logic, database queries, role-based access, dashboards, and integrations. Every query is written against the real schema structure, so when the application connects to a real database instance in staging, the queries work without modification.
If your team wants to test with realistic data during development, they generate synthetic records that match the schema's shape. A patient intake portal can be built and tested with dummy patient names, synthetic insurance IDs, and placeholder referral codes. The application logic is identical whether it processes synthetic data in development or real data in production.
What lives where [#what-lives-where]
| In the development environment (Replit) | In your staging and production environment (your cloud) |
| ----------------------------------------- | ------------------------------------------------------- |
| Application code and logic | Real sensitive data (PHI, PII, financial records) |
| Database schema (structure only) | Production and staging database credentials |
| Synthetic or dummy test data | Encryption keys and certificates |
| Development-scoped API credentials | Audit logging and compliance monitoring |
| Git history and agent-generated artifacts | Access controls and network policies |
What the platform provides for regulated environments [#what-the-platform-provides-for-regulated-environments]
Several platform capabilities support this model. On the enterprise plan, prompts, code context, and conversations are not stored or used for model training by any model provider, which means zero data retention for the inputs your teams provide. The platform is SOC 2 Type 2 compliant, with the audit report available to your security and compliance teams on request. Users authenticate through your identity provider via SSO and SCIM, with automatic deprovisioning, so no one accesses the platform through a personal email or unmanaged account. Code flows through your Git provider, restricted to whitelisted organizations and private repositories only, with your pipeline handling everything after the push. For development that connects to staging databases behind your network during the build phase, a single-tenant deployment option provides static outbound IPs that can be allowlisted on your security groups.
These capabilities are supporting infrastructure for the development model. The fundamental protection is architectural: sensitive data never enters the development environment regardless of what platform security features exist.
How this works in practice [#how-this-works-in-practice]
A major healthcare diagnostics company adopted this model to build patient-facing applications on Replit. The development team provided database schemas (patient demographics, appointment types, insurance fields, referral codes) without any real patient records. The agent built the application, the team iterated using synthetic data, and the finished application graduated through the company's CI/CD pipeline to their health cloud. PHI connections were established only at the production layer, behind the company's existing access controls, encryption, and HIPAA-compliant infrastructure. No PHI was ever uploaded to or connected from the development environment.
The same pattern applies across regulated industries. In financial services, customer account data stays in the production database behind the company's VPC, and developers build against the account schema with synthetic balances and transaction histories. In legal, confidential contract text stays in the document management system, and developers build contract review tools against schema definitions and sample documents. In insurance, claims data stays in the regulated data warehouse, and developers build claims processing interfaces against the claims schema with synthetic records.
Starting with non-sensitive use cases [#starting-with-non-sensitive-use-cases]
Many organizations begin by building tools that do not touch sensitive data at all: internal dashboards, operational workflows, reporting tools, or team utilities. This lets teams learn the platform, establish governance practices, and build confidence before expanding to sensitive-data applications. This progression is natural. Once the development model is established (schema-only development, Git-native graduation, secrets management in your cloud), applying it to sensitive data use cases follows the same process with the same controls.
Identify one application your team needs that touches sensitive data. Export the database schema (tables, fields, relationships) without any records, bring that schema to Replit, and build the first version.
