Build and Operate with Replit

Capstone

The Cross-Department Decision Desk

Build a production-grade app that turns requests from several business departments into owned decisions with real data, authenticated roles, visible history, one safe external integration, tests, recovery, deployment, monitoring, and explicit cost boundaries.

What you must build

• ◆Serve at least three departments—such as operations, finance, people, support, or sales—through one shared request model with department-specific categories, required evidence, and service expectations.
• ◆Give requesters, reviewers, and administrators clearly different capabilities. Enforce authentication, record ownership, organization scope, and action authorization on the server.
• ◆Use Replit Database with reviewed migrations, constraints, synthetic seed data, development/production separation, and an append-only history of every consequential state transition.
• ◆Support intake, triage, assignment, request-for-information, approval/rejection, completion, search, filtering, and a detail view that makes the current state and next action obvious.
• ◆Add one least-privilege external integration. Persist operation IDs, attempts, provider references, and pending/succeeded/failed states; prevent duplicate side effects and provide a bounded recovery action.
• ◆Design the critical flow and its empty, loading, invalid, unauthorized, dependency-failure, and success states on Canvas before implementation; include wide and narrow layouts and a behavior contract.
• ◆Use Plan Mode to produce bounded vertical slices. Run at least one slice as an isolated background Task, inspect its plan, work log, Preview, tests, and diff, then Apply or Dismiss it deliberately.
• ◆Create unit tests for domain rules, integration tests for state and history, and browser journeys for happy, denial, duplicate, failure, reload, and mobile paths. Review App Testing replays where the app type supports them.
• ◆Maintain a current root replit.md with verified commands and project boundaries. Create or install one narrowly scoped, source-reviewed Skill and benchmark matching and non-matching prompts. Connect an MCP server only when its trusted account, tools, scopes, owner, read-only proof, and revocation path are documented; otherwise record the denied connection decision.
• ◆Maintain a known-good Agent checkpoint, coherent Git commits on an intentional branch, and a configured GitHub remote or a written reason the repository remains local. Do not represent GitHub as a database or secrets backup.
• ◆Complete and time a development recovery drill. Document separate code, configuration, development-data, production-data, credential, and deployment recovery paths.
• ◆Publish the named release on a workload-appropriate Replit publishing type, configure production resources and a custom domain if appropriate, then verify the release at the public URL.
• ◆Complete the Agents & Automations drill with a synthetic Timed Automation. Keep testing-pane evidence separate from a deployed scheduled-trigger receipt, and record the disable and cost path whether or not deployment is authorized.
• ◆Enable appropriate logs, health/uptime monitoring, resource analytics, critical-workflow signals, and an incident owner. Define response thresholds and a first-response runbook.
• ◆Set current Replit spending controls or alerts, establish a normal usage range, and document which product actions can materially increase Agent, database, compute, storage, request, or transfer cost.
• ◆Give a five-minute operator handoff in which another person can explain the project boundary, run the critical journey, find evidence, identify the current release, and invoke the safe recovery process.

How you prove it

• A signed-out user is denied; an authenticated requester can create and view only allowed requests; a reviewer can act only within scope; an administrator's consequential action is audited.
• A complete request can be traced through current record, transition history, actor, integration attempt, provider reference, and a safe correlation identifier.
• Database constraints and server rules reject invalid state, self-approval when forbidden, and cross-user access even when the browser interface is bypassed.
• Layered test results and reviewed browser/App Testing evidence cover happy, invalid, unauthorized, duplicate, dependency-failure, reload, and narrow-screen journeys.
• A background Task changes the main version only after an evidence review; root replit.md, the scoped Skill benchmark, and the authorized-or-denied MCP decision are inspectable.
• A development rollback restores the chosen code and data state, and the production recovery runbook names how current data would be protected and verified.
• The custom or platform production URL serves the named release; health, authenticated workflow, integration failure, and mobile smoke checks pass after publishing.
• The Timed Automation has a testing-pane receipt and either a timestamped deployed trigger receipt or an explicit not-deployed record; no background development Task is presented as automation proof.
• Monitoring shows service health, errors, latency/resources, and critical-workflow outcomes, with thresholds and a named responder.
• Current Replit usage controls show an intentional budget or alert boundary and the release packet records the cost assumptions used at launch.