Software Project Initiation Checklist
End-to-end kickoff checklist a tech lead or engineering manager runs when starting a new software project, from scope and stack selection through requirements, build, deployment, and post-launch support.
Project Initiation
-
Define project scope and success criteria
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.
-
Confirm executive sponsor and funding
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.
-
Assign roles and build the RACI
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.
-
Select the technology stack
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.
-
Set up the project repository and CODEOWNERS
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.
Requirements Gathering
-
Run stakeholder discovery interviews
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.
-
Document functional requirements
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.
-
Write user stories in Jira or Linear
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.
-
Build wireframes in Figma
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.
Collects file -
Validate requirements with stakeholders
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.
Collects list -
Revise the requirements package
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.
Design and Development
-
Design the system architecture
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.
-
Stand up the CI/CD pipeline
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.
-
Implement the database schema and migrations
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.
-
Build the application features
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.
-
Write automated test coverage
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 the security and dependency review
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.
Collects list -
Remediate the security findings
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.
Deployment
-
Draft the deployment and rollback runbook
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.
Collects file -
Provision the production environment with Terraform
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.
-
Configure monitoring, logging, and alerting
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.
-
Run the pre-launch smoke test in staging
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.
-
Cut over to production with a canary rollout
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.
Support and Maintenance
-
Monitor SLOs and the error budget
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.
-
Triage inbound bug reports
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.
-
Run the post-launch retrospective
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.
-
Verify the backup and restore drill
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.
Collects list
Use this template
Copy it to your account, customize the steps, and run it with your team in minutes.
Browse hundreds of free templates across every team and industry.
Back to template libraryRun Software Project Initiation Checklist with your team
Customize the steps, assign roles, set a schedule, and keep a complete record for every run.