Software Project Initiation Checklist

Write a one-page brief: in-scope, explicitly out-of-scope, and the measurable success criteria (SLOs, adoption targets, business KPIs). Vague scope is the root cause of most missed deadlines — name what you are not building.

Identify the named sponsor accountable for the project, the budget envelope (engineering headcount + cloud spend), and the governance forum where status will be reviewed. Projects without a single accountable sponsor stall on cross-team dependencies.

Name the tech lead, product manager, designer, QA owner, and on-call rotation. RACI doesn't need to be exhaustive — it needs to disambiguate who approves the architecture, who signs off on releases, and who owns post-launch support.

Document the language, framework, datastore, and cloud provider with a short rationale per choice. Default to what the team already operates — a new language or new cloud account is its own multi-month project.

Create the repo in GitHub/GitLab, set branch protection on main with required status checks, add a CODEOWNERS file, and enable secret scanning. Pre-commit hooks (gitleaks) prevent the most common day-one mistake — committing an API key to history.

Interview the customer-facing teams (sales, support, CS) plus 3-5 actual users. Capture jobs-to-be-done and the workarounds they use today; the workarounds tell you what's broken about the current state.

Write the PRD or spec doc. Include non-functional requirements explicitly — latency targets, expected QPS, data retention, regulatory scope (SOC 2, HIPAA, GDPR). NFRs left implicit get discovered during load testing, which is too late.

Break the spec into stories with acceptance criteria the QA owner can test against. Tag stories with the epic and the milestone they belong to so velocity tracking actually reflects scope.

Produce low-fidelity wireframes for every primary user path. Wireframes catch UX gaps before code is written — the cost of moving a button in Figma is minutes; in production it's days.

Walk the sponsor and lead users through the spec and wireframes in a single review session. Capture decisions in writing — verbal approvals evaporate when the original participant leaves the team.

Apply the requested changes, re-circulate the diff, and re-run the validation session. Don't proceed to architecture work until you have a written approval — building against a moving spec is the most expensive way to discover scope ambiguity.

Produce a C4-style diagram covering services, datastores, external dependencies, and trust boundaries. Hold an architecture review with at least one engineer outside the project — fresh eyes catch the assumptions you've stopped questioning.

Configure GitHub Actions / GitLab CI with build, lint, test, and SAST stages. Wire required status checks into branch protection so red builds cannot merge — the team that ignores red CI ends up shipping flakes that mask real regressions.

Write migrations as code, reviewed in PRs. Plan for online schema changes from day one: add columns without defaults, backfill in batches, set defaults in a follow-up. A 4-hour exclusive lock on a 50M-row table during peak is the kind of incident that ends careers.

Ship features behind feature flags so you can dark-launch and gradually roll out. Cap PR size at ~400 lines of diff to keep code review meaningful — "LGTM" on a 1,200-line PR isn't a review.

Unit tests for business logic, integration tests against a real database, and Playwright/Cypress e2e tests for the critical user paths. Set a coverage floor in CI so coverage doesn't quietly erode.

Run Snyk or Dependabot for SCA, Semgrep or CodeQL for SAST, and walk the OWASP Top 10 against the new endpoints. Generate the SBOM (CycloneDX or SPDX) for any project that may end up in a federal-contract pipeline.

File tickets for each Critical and High finding, fix or document a compensating control, and re-run the scan. Mediums and Lows go on the backlog with a named owner — "we'll get to it later" is how Log4Shell-grade exposure compounds.

Document the deploy order (migration first, backend canary, backend full, frontend) and the rollback path for each step. The rollback section is the part that gets skipped and the part you need at 2am — write it like the on-call hasn't seen the system before.

Stand up VPC, subnets, security groups, IAM roles, RDS, and the EKS/ECS cluster as code. Click-ops infrastructure cannot be reproduced for DR or audited for SOC 2 — both will bite within the year.

Wire Datadog or Grafana dashboards for the four golden signals (latency, traffic, errors, saturation). Route pages through PagerDuty with a documented escalation policy — alerts going to a deprecated Slack channel is how cert-renewal outages happen.

Execute the critical user paths against the release-candidate build in staging, plus a load test at expected peak QPS. QA signs off in writing before the production cutover window opens.

Deploy migration first, then 5% canary for 10 minutes, then 25% / 50% / 100%. Watch error rate and p99 latency between each stage. Avoid Friday-afternoon cutovers — the weekend on-call burden isn't worth the calendar slot.

Review the SLO dashboard weekly with the on-call rotation. When the error budget is burning faster than expected, freeze feature work and shift capacity to reliability — the budget exists to make that decision automatic, not optional.

Run a daily triage of Sentry/Bugsnag and the support inbox. Assign severity (SEV1/2/3), name an owner, and link the ticket — bugs without owners stay open forever and erode trust with the support team.

Hold a blameless retro covering what went well, what didn't, and 3-5 action items with named owners and due dates. Track action items to closure — retros without follow-through are theater.

Restore the most recent production backup into a non-prod environment and confirm the application boots against it. A green backup-success metric is not evidence the backup is usable; the restore drill is.