{"title":"Deploying Projects","description":null,"content":"A project is easier to trust when a hiring manager can see it working.\n\nIf the README only says \"clone the repo and run it locally,\" many reviewers will not get that far. They are usually moving quickly. They will look for the fastest proof first: a live link, a screenshot, a short demo clip, or a clear terminal example.\n\nFor a web project, a working demo link is often the best evidence. It changes the message from \"I built this\" to \"you can try it here.\"\n\n---\n\n# What a Good Demo Needs\n\nDeploy the project in the simplest way that lets someone see the main idea.\n\nThis does not mean building production infrastructure. A portfolio demo does not need a complex release process, advanced monitoring, or a cloud setup you barely understand. It needs a stable link, useful sample data, and a first screen that makes the project easy to understand.\n\nThe right host depends on the project. A static site or frontend-only app can often run on Vercel, Netlify, GitHub Pages, or Cloudflare Pages. A backend or full-stack app may need a service that can run a server, store environment variables, and connect to a database, such as Render, Railway, Fly.io, or a cloud provider.\n\nBe careful with free and trial plans. Hosting limits change, and free tiers often come with trade-offs such as sleeping services, usage caps, build limits, bandwidth limits, database limits, or trial credits. That is fine for a portfolio project if you understand the limits and test the demo before sharing it.\n\nA good demo does three things well:\n\n- It loads without obvious errors.\n- It shows useful sample data right away.\n- It gives the reviewer a safe way to try the main workflow.\n\n---\n\n# Shipping a Live Demo\n\n### Choose a host that matches the project\n\nStart with the simplest option that fits.\n\nFor a static site, documentation site, or frontend-only app, use a static host. For a backend or full-stack app, use a platform that supports a running service and environment variables. If the project needs a database, decide whether your host provides one or whether you need a separate managed database.\n\nDo not choose a platform just because it sounds more advanced. Choose one you can deploy, maintain, and explain.\n\n### Deploy from the repo\n\nMost hosting platforms can connect to GitHub. The usual steps are simple: choose the repo, set the build command, set the output directory or start command, and add environment variables in the platform dashboard.\n\nDo not commit secrets to the repo. API keys, database URLs, sign-in secrets, and private tokens belong in environment variables or a secrets manager, not in source control.\n\nThe path from code to a live demo follows the same shape on most platforms.\n\n\n```mermaid\nflowchart LR\n A[Push to
GitHub]:::start --> B[Connect repo
to host]:::main\n B --> C[Set build +
start command]:::sec\n C --> D[Add environment
variables]:::teal\n D --> E[Build +
deploy]:::yellow\n E --> F[Live demo
link]:::good\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef main fill:#ffa94d,stroke:#000,color:#000\n classDef sec fill:#3bc9db,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef good fill:#69db7c,stroke:#000,color:#000\n```\n\n\nYou push the code, connect the repo, tell the host how to build and start it, add your environment variables in the dashboard, and the platform builds and deploys to a public URL. The secrets stay in the dashboard, not in the repo.\n\n### Make the first screen useful\n\nDo not send the reviewer to an empty dashboard or a login screen with no way in.\n\nUse one of these options:\n\n- Load the demo with sample data.\n- Provide a demo account in the README.\n- Add a \"Try demo\" button that opens a safe demo session.\n- For read-only tools, show the output immediately.\n\nThe reviewer should understand what the project does within a few seconds.\n\n### Use safe sample data\n\nNever seed a public demo with real user data, customer data, private tokens, or anything you would not want indexed by a search engine.\n\nUse fake but realistic data. If the demo allows editing or deleting, make it reset automatically or limit the demo account so it cannot damage anything important.\n\n### Account for cold starts and limits\n\nSome low-cost backend services sleep when they have not been used for a while. The first request after a quiet period may take several seconds. Some databases and deployment plans also have usage limits or trial windows.\n\nBefore you put the link on your resume, test it from a browser where you are logged out. If the demo takes a little time to wake up, mention it briefly in the README. If the delay makes the app feel broken, simplify the demo, choose another host, or consider a small paid option for your strongest project.\n\nDo not work around platform limits in ways the host does not allow. It is better to choose the right tier, reduce the scope, or be honest about a short delay.\n\n### Add basic guardrails\n\nA public demo can be opened by anyone. You do not need enterprise security for a portfolio project, but you do need common sense.\n\nAt minimum:\n\n- Keep secrets out of the client and repo\n- Use fake data\n- Restrict destructive actions\n- Reset demo data if users can edit it\n- Rate-limit expensive actions if the app has them\n- Watch usage so billing does not surprise you\n\nThese details show maturity. A hiring manager does not expect a beginner project to be perfect, but they do notice whether you handled the obvious risks.\n\n### Put the live link where people can find it\n\nAdd the demo URL near the top of the README, near the screenshot, and anywhere you list the project on your resume, GitHub profile, or portfolio site.\n\nIf the demo needs a login, put the demo credentials next to the link. Do not make the reader hunt for them.\n\nHere is a simple hosting decision path.\n\n\n```mermaid\nflowchart TD\n A[Your project]:::start --> B{Static or
frontend-only?}:::q\n B -->|Yes| C[Use a static host]:::yes\n B -->|No| D{Needs a server,
database, or jobs?}:::q\n D -->|Yes| E[Use an app host
and managed database]:::mid\n D -->|No| C\n E --> F{Limits hurt
the demo?}:::q\n F -->|No| G[Use the plan
and document limits]:::yes\n F -->|Yes| H[Simplify, switch hosts,
or use a small paid tier]:::warn\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef q fill:#ffd43b,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n classDef mid fill:#38d9a9,stroke:#000,color:#000\n classDef warn fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n---\n\n# Hosting Options\n\nHosting plans change, so always check current limits before relying on a platform. Use this table as a starting point, not as a pricing guide.\n\n\n| Platform | Good fit | Watch for |\n|----------|----------|-----------|\n| Vercel | Frontend apps, static sites, Next.js projects, and small serverless APIs | Usage limits, function limits, build settings, and plan rules |\n| Netlify | Static sites, frontend apps, deploy previews, and simple serverless functions | Build limits, usage limits, function limits, and plan rules |\n| GitHub Pages | Static project pages, docs, and simple portfolio pages | Static hosting only; no traditional backend server |\n| Cloudflare Pages | Static sites, frontend apps, and apps that can use Pages Functions or Workers | Platform limits, function limits, and whether the project fits the Workers model |\n| Render | Web services, background workers, and simple full-stack apps | Service sleep, database limits, usage limits, and plan changes |\n| Railway | Full-stack apps, services, databases, and quick prototypes | Trial credits, usage-based billing, and resource limits |\n| Fly.io | Apps that need running processes, regional deployment, or more infrastructure control | Usage-based billing and more infrastructure choices to understand |\n\n\nFor a beginner, the best choice is usually the one with the fewest moving parts. A static frontend demo is often easier to keep running than a full backend. For a full-stack project, choose a platform you understand well enough to explain.\n\n---\n\n# Two Demo READMEs Compared\n\nThe demo link should reduce effort for the reviewer. Compare these two README openings.\n\n**Weak:**\n\n\n```javascript\n# task-board\n\nA kanban board app. Clone the repo and run it locally to try it out.\nRequires Node 18, Postgres, and Redis.\n```\n\n\nThis may be true, but it asks a busy reviewer to do too much before seeing any value.\n\n**Stronger:**\n\n\n```javascript\n# task-board\n\nA kanban board for small teams with drag-and-drop tasks and real-time updates.\n\nLive demo: https://task-board-demo.example.com\nDemo login: demo@example.com / demo-password\n\nThe demo opens with a sample board and resets every night.\n\n[screenshot of the board]\n```\n\n\n**Why it works:** The reviewer can click, see real data, and try the main workflow without creating an account or configuring local services. The README also sets expectations by explaining that the demo resets.\n\n---\n\n# Deployment Mistakes to Avoid\n\nA missing link, a dead link, and a blank demo all end the same way: the reviewer never watches the project run.\n\n- **No demo link for a visual web project.** If the project has a UI, a live demo is usually worth the effort.\n- **A broken demo link.** Test the deployed URL from a logged-out browser before adding it to your resume.\n- **An empty demo.** A blank dashboard does not show what the project can do. Add realistic sample data.\n- **A login screen with no demo access.** Provide a demo account or a safe demo mode.\n- **Real data in a public demo.** Use fake data. Public links can be shared, indexed, and opened by people you did not expect.\n- **Ignoring platform limits.** Free and trial plans often have sleep, usage, billing, or database limits. Know what happens when the demo is idle or credits run out.\n- **Hiding the URL.** Put the link near the top of the README and near the project entry wherever you share it.\n\n---\n\n# What To Do Next\n\nPick one project you plan to show and test it like a reviewer would. Open the README, click the demo link, and try the main workflow from a logged-out browser.\n\nIf anything is confusing, slow, empty, or broken, fix that before adding the project to your resume. A simple demo that works is better than an ambitious demo that makes the reviewer guess.","pageType":"job-search"}

Get Premium