Deploy the prototype
Vendor Review starts with one useful job: an employee describes a proposed software vendor, and AI identifies missing information and suggests a risk level.
Before improving it, establish what the application does today and who can reach it.
Deploy your copy
Deploy the main starter and create an owned GitHub copy in one step:
The flow forks the course repository into your GitHub account, creates a Vercel project from main, and deploys Vendor Review. Keep the project’s Root Directory at the repository root.
Run it locally
Clone the fork created by Vercel. The main branch is the starter, and the application lives at the repository root:
git clone <your-fork-url>
cd academy-enterprise-apps-agents
git remote add upstream https://github.com/vercel-labs/academy-enterprise-apps-agents.git
git fetch upstream --tags
git switch -c course-work
pnpm install
cp .env.example .env.local
pnpm devorigin is your copy. upstream is the canonical course repository, which keeps the later reference branch and exercise checkpoint available even if the one-click copy begins with only main.
Add an AI Gateway key to .env.local, then submit three requests:
- A low-cost design tool that handles no company data
- A support service that handles customer contact information
- An expensive analytics platform with an incomplete business purpose
Record the results you actually receive. Do not change the prompt to force a preferred answer.
Find the first production gaps
Trace one request through the code:
| Question | Where to look |
|---|---|
| What can an employee submit? | app/page.tsx |
| Where does the model call happen? | app/api/assess/route.ts |
| What shape comes back? | The route response |
| Where is the request stored? | It is not stored yet |
Refreshing the page clears the result. The application cannot yet prove what was submitted, which model produced the assessment, or what a person ultimately decided.
Open docs/readiness.md. Under Prototype baseline, record the three inputs, their results, and anything inconsistent or surprising. The template already exists so this lesson stays focused on the application instead of Markdown interior design.
Protect the deployment
Open the Vercel project created by the button and confirm the production URL renders Vendor Review and can complete an assessment. Leave AI_GATEWAY_API_KEY unset in Preview and Production so the AI SDK uses the project’s automatically supplied Vercel OIDC identity. A static key is still appropriate for local development or a non-Vercel runtime.
The complete branch is the finished reference. Keep main as the production branch for this baseline project so a later branch preview does not silently replace it.
Before sharing the URL, follow the Deployment Protection instructions and enable Vercel Authentication for the URLs you intend to test. Standard Protection is available on all plans, but it does not protect a custom production domain. Protecting all production and preview URLs requires Pro with the Advanced Deployment Protection add-on or Enterprise. Verify the exact production and preview URLs in a private browser window and record which ones are protected.
Make one small change on a branch and confirm the pull request creates a protected preview:
commit → protected preview → review → merge → protected productionAdd the production URL, the Vercel team that owns the project, the source repository, and the protection checks to docs/readiness.md.
Commit the baseline before the application changes:
git add docs/readiness.md
git commit -m "docs: record prototype baseline"Summary
A deployment is more than a URL. It creates an owned, inspectable history of what code reached each environment. Deployment Protection keeps an internal prototype private while the team decides whether it is ready for broader use.
Protection is the first baseline, not the whole governed path. As the application moves beyond a prototype, the team should be able to show which controls every deployment inherits and which changes require an explicit review. That distinction keeps routine delivery self-serve while making exceptions visible to the people accountable for them.
Check your work
Open the production URL in a private browser. It should require authentication. Then locate the exact Git commit behind that deployment in Vercel and name the team that can ship the next one. Record any URL that fails the private-browser check as a gap instead of giving it a hopeful checkmark.
The application is available and protected. The next lesson defines what it is—and is not—allowed to become.
Was this helpful?