Chapter 36: Checklists

Ready-to-Use Checklists for POS Development and Operations

This chapter provides comprehensive checklists for common development, deployment, and operational tasks. Print these and use them to ensure nothing is missed.

Table of Contents

1. New Feature Checklist
2. Code Review Checklist
3. Security Review Checklist
4. API Endpoint Checklist
5. Database Migration Checklist
6. Deployment Checklist
7. Go-Live Checklist
8. Tenant Onboarding Checklist
9. End-of-Day Checklist
10. PCI-DSS Audit Checklist

1. New Feature Checklist

Use this checklist when implementing any new feature in the POS platform.

Planning Phase

• Requirements documented - Clear acceptance criteria defined
• Architecture review - /architect-review completed for major features
• ADR created - If architectural decision was made
• Database schema designed - Entity models and relationships defined
• API contracts defined - Endpoints, request/response formats documented
• UI mockups approved - For features with user interface changes
• Tenant impact assessed - How does this affect multi-tenancy?

Implementation Phase

• Domain entities created - Following DDD patterns
• Domain events defined - Named in past tense, all relevant events
• Repository interfaces - Abstraction layer defined
• Repository implementations - EF Core implementations
• Service interfaces - Business logic abstraction
• Service implementations - Business logic with proper logging
• API controllers - RESTful endpoints with proper authorization
• DTOs created - Request/response models separate from domain
• Validation added - FluentValidation or DataAnnotations
• Error handling - Proper exception handling and responses

Testing Phase

• Unit tests written - Cover all business logic branches
• Integration tests written - Test with real database
• API tests written - Verify endpoint contracts
• Tenant isolation tested - Verify data doesn’t leak
• Edge cases covered - Null values, empty lists, max values
• Error scenarios tested - Verify proper error responses

Documentation Phase

• API documentation updated - Swagger annotations complete
• README updated - If setup/configuration changed
• CHANGELOG updated - Feature listed with version
• User documentation - If user-facing feature

Final Review

• Code review completed - /engineer review passed
• Security review - No vulnerabilities introduced
• Performance verified - No N+1 queries, proper indexing
• Migrations tested - Applied and rolled back successfully

2. Code Review Checklist

Use this checklist when reviewing code (or when preparing code for review).

General Quality

• Code compiles - No build errors or warnings
• Tests pass - All existing and new tests green
• No dead code - Unused variables, methods removed
• No commented-out code - Remove or document why
• Meaningful names - Variables, methods, classes have clear names
• Small methods - Functions do one thing well
• Proper indentation - Consistent formatting

Architecture & Design

• Single Responsibility - Each class has one reason to change
• Dependency Injection - No new for services, use DI
• Interface segregation - No fat interfaces
• Proper layering - Controllers don’t contain business logic
• Repository pattern - Data access abstracted
• No circular dependencies - Clean dependency graph

Error Handling

• Exceptions caught appropriately - Not swallowing exceptions
• Meaningful error messages - Users and developers can understand
• Logging on errors - Stack traces logged for debugging
• Graceful degradation - Feature fails safely

Security

• Authorization checked - Proper [Authorize] attributes
• Input validated - All user input sanitized
• No SQL injection - Parameterized queries only
• No XSS vulnerabilities - Output encoded
• Secrets not hardcoded - Use configuration/vault
• Tenant isolation - Data scoped to tenant

Performance

• No N+1 queries - Use Include/eager loading
• Proper async/await - No blocking calls
• Appropriate caching - Frequently accessed data cached
• Database indexes - Queries use indexes
• No memory leaks - Disposable objects disposed

Documentation

• XML comments on public APIs - Summary, params, returns
• Complex logic documented - Why, not just what
• TODO items tracked - Linked to issues if deferred

3. Security Review Checklist

Use this checklist before deploying features that handle sensitive data.

Authentication

• Strong password policy - Minimum length, complexity
• Password hashing - bcrypt/Argon2, not MD5/SHA1
• Account lockout - After failed attempts
• Session management - Proper timeout, secure cookies
• Multi-factor authentication - For admin accounts
• JWT properly validated - Signature, expiration, issuer

Authorization

• Role-based access - RBAC properly implemented
• Least privilege - Users have minimum necessary permissions
• Authorization on all endpoints - No unprotected APIs
• Tenant isolation enforced - Users can’t access other tenants
• Resource ownership verified - Users can only modify own resources

Data Protection

• Sensitive data encrypted - At rest and in transit
• TLS/HTTPS enforced - No plaintext transmission
• PII minimized - Only collect what’s necessary
• Data retention policy - Old data purged
• Backup encryption - Backups are encrypted

Input Validation

• All input validated - Type, length, format
• Whitelist validation - Accept known good
• SQL injection prevented - Parameterized queries
• XSS prevented - Output encoding
• CSRF protection - Anti-forgery tokens
• File upload restrictions - Type, size limits

Logging & Monitoring

• Security events logged - Login, logout, failures
• PII not logged - Passwords, card numbers excluded
• Log integrity - Logs protected from tampering
• Alerting configured - Suspicious activity triggers alerts
• Audit trail - Who did what, when

Infrastructure

• Firewall configured - Only necessary ports open
• Dependencies updated - No known vulnerabilities
• Secrets in vault - Not in code or config files
• Container hardened - Non-root user, minimal image
• Network segmentation - Database not publicly accessible

4. API Endpoint Checklist

Use this checklist when adding or modifying API endpoints.

Design

• RESTful naming - Resource-based URLs
• Proper HTTP methods - GET, POST, PUT, DELETE used correctly
• Versioning - /api/v1/ prefix
• Consistent naming - camelCase, plural resources
• Pagination - Large collections paginated
• Filtering/sorting - Query parameters for flexibility

Implementation

• Controller attribute - [ApiController] applied
• Route attribute - Explicit routes defined
• Authorization - [Authorize] with roles/policies
• Model binding - [FromBody], [FromQuery] specified
• Validation - ModelState checked or auto-validation
• Response types - [ProducesResponseType] specified
• Cancellation token - Async methods accept token

Request Handling

• Input validation - All inputs validated
• Idempotency - POST/PUT are idempotent where needed
• Rate limiting - Appropriate limits configured
• Request logging - Requests logged (excluding sensitive data)
• Content negotiation - Accept header respected

Response Format

• Consistent structure - Standard envelope if used
• Proper status codes - 200, 201, 400, 401, 403, 404, 500
• Error format - Standard error response structure
• No sensitive data - Passwords, tokens not in responses
• Proper content type - application/json

Documentation

• Swagger annotations - Summary, description, examples
• Request examples - Sample payloads documented
• Response examples - Success and error responses
• Authentication documented - How to authenticate

5. Database Migration Checklist

Use this checklist when creating and applying database migrations.

Before Creating Migration

• Schema reviewed - Changes discussed with team
• Backwards compatible - Can roll back if needed
• Data preservation - Existing data won’t be lost
• Performance impact - Large table changes planned
• Index strategy - New indexes identified

Creating Migration

• Meaningful name - Descriptive migration name
• Single responsibility - One logical change per migration
• Up and Down - Both directions implemented
• Idempotent - Can run multiple times safely
• Data migration - If data transformation needed

Testing Migration

• Local test - Applied to local database
• Rollback tested - Down migration works
• Data verified - Existing data intact
• Performance tested - Large tables migrate acceptably
• All tenants tested - Works for all tenant schemas

Deploying Migration

• Backup taken - Database backed up before migration
• Maintenance window - Users notified if downtime
• Migration logged - Record of when applied
• Verification query - Confirm migration successful
• Rollback plan - Know how to undo if problems

After Migration

• Application tested - Features work with new schema
• Performance checked - No query regressions
• Monitoring reviewed - No errors in logs
• Documentation updated - Schema docs reflect changes

6. Deployment Checklist

Use this checklist for every deployment to staging or production.

Pre-Deployment

• All tests passing - CI pipeline green
• Code reviewed - All changes approved
• Security scan - No new vulnerabilities
• Dependencies updated - If applicable
• CHANGELOG updated - Version and changes documented
• Rollback plan - Know how to revert if issues

Environment Preparation

• Configuration updated - Environment variables set
• Secrets rotated - If scheduled rotation
• Database migrations - Applied before deployment
• Feature flags - New features disabled initially
• Monitoring ready - Dashboards and alerts configured

Deployment Steps

• Notify stakeholders - Team aware of deployment
• Health check ready - Endpoint to verify deployment
• Deploy to staging first - Verify in staging environment
• Smoke tests passed - Critical paths work
• Deploy to production - Rolling update or blue-green
• Health check verified - All instances healthy

Post-Deployment

• Smoke tests in production - Critical paths verified
• Monitoring checked - No errors, performance normal
• User validation - Key users confirm functionality
• Deployment logged - Record version, time, deployer
• Documentation updated - If operational changes

If Problems Occur

• Assess impact - How many users affected?
• Decide rollback - Roll back or fix forward?
• Execute rollback - If decided, roll back quickly
• Notify stakeholders - Communicate status
• Root cause analysis - Document what went wrong

7. Go-Live Checklist

Use this comprehensive checklist before launching the POS system for a new tenant.

Infrastructure

• Production environment ready - All containers running
• Database provisioned - Tenant schema created
• SSL certificates - Valid and not expiring soon
• DNS configured - Custom domain if applicable
• Load balancer - Configured and tested
• Backup system - Automated backups running
• Disaster recovery - Tested and documented

Security

• Security audit complete - No critical findings
• PCI-DSS compliance - If handling cards
• Penetration testing - Completed without issues
• Access controls - Proper roles configured
• Secrets secured - In vault, not in code

Data

• Data migrated - From legacy system if applicable
• Data validated - Migrated data is correct
• Seed data - Default settings configured
• Test data removed - No test records in production

Integration

• Payment gateway - Connected and tested
• Shopify integration - If applicable, syncing
• QuickBooks integration - If applicable, bridges connected
• Email service - Transactional emails working
• SMS service - If applicable, verified

Training

• Admin training - Tenant admins trained
• Staff training - Cashiers trained
• Documentation - User guides available
• Support process - Help desk configured

Operational

• Monitoring active - All dashboards live
• Alerting configured - On-call schedule set
• Support team ready - Staff available for issues
• Escalation path - Know who to call for critical issues

Final Verification

• End-to-end test - Complete transaction flow
• Offline mode tested - Works without internet
• Receipt printing - Printers configured
• Cash drawer - Opens correctly
• Reports - Generate correctly
• Stakeholder sign-off - Approval to go live

8. Tenant Onboarding Checklist

Use this checklist when setting up a new tenant in the POS platform.

Account Setup

• Tenant record created - In system database
• Tenant ID generated - UUID assigned
• Tenant schema created - Database schema provisioned
• Admin user created - Initial admin account
• Password sent securely - Not in plain email

Configuration

• Business information - Name, address, tax ID
• Timezone configured - Correct timezone set
• Currency configured - Default currency set
• Tax rates - Local tax rates configured
• Receipt template - Customized with logo
• Email templates - Customized branding

Locations

• Locations created - All store locations added
• Location settings - Hours, addresses configured
• Inventory locations - Mapped to physical areas
• Fulfillment settings - Shipping from locations

Users

• User accounts created - All staff accounts
• Roles assigned - Proper permissions
• PIN codes set - For quick clock-in
• Training scheduled - Users know how to use system

Hardware

• POS terminals - Configured and tested
• Receipt printers - Installed and tested
• Barcode scanners - Connected and working
• Cash drawers - Opening on command
• Customer displays - If applicable, configured

Inventory

• Categories created - Product categories set up
• Products imported - From spreadsheet or legacy system
• Barcodes mapped - SKUs linked to barcodes
• Initial counts - Starting inventory recorded
• Pricing verified - All prices correct

Payments

• Payment methods - Cash, card, etc. enabled
• Payment gateway - Connected to tenant’s account
• Refund policy - Configured in system
• Gift cards - If applicable, enabled

Testing

• Test transaction - Complete sale end-to-end
• Test refund - Return processed correctly
• Test receipt - Prints correctly
• Test reports - Generate correctly
• Test sync - Data syncs to cloud

Final Steps

• Go-live date set - Scheduled with tenant
• Support contact - Tenant knows how to get help
• Documentation shared - User guides provided
• Billing configured - Subscription set up

9. End-of-Day Checklist

Use this checklist for daily store closing procedures.

Register Closure

• No open tickets - All pending transactions completed
• Z-report generated - End of day report printed
• Cash counted - Physical cash counted
• Over/short recorded - Discrepancy documented
• Cash deposited - Taken to safe or bank

Reconciliation

• Credit card batch - Batch closed and settled
• Gift card balance - Reconciled with system
• Returns verified - All returns have receipts
• Voids reviewed - Manager approval on voids
• Discounts reviewed - All discounts authorized

Inventory

• Received inventory - All receipts processed
• Transfers complete - Inter-store transfers logged
• Damaged items - Recorded in system
• Low stock noted - Reorder list generated

Equipment

• Registers logged out - All users signed out
• Printers - Paper refilled if needed
• Scanners - Charging if wireless
• Terminals - Shut down or locked

Security

• Safe locked - All valuables secured
• Doors locked - All entrances secured
• Alarm set - Security system armed
• Lights - Appropriate lights on/off

Data Backup

• Sync completed - All data uploaded to cloud
• Local backup - If offline backup required
• Verify sync - Confirm data in cloud dashboard

Manager Sign-Off

• Reports reviewed - Day’s performance checked
• Issues logged - Any problems documented
• Next day prep - Opening tasks noted
• Shift closed - System day closed

10. PCI-DSS Audit Checklist

Use this checklist to verify PCI-DSS compliance requirements.

Requirement 1: Network Security

• Firewall installed - Protecting cardholder data
• Default passwords changed - No vendor defaults
• Network segmentation - CDE isolated from other networks
• Firewall rules documented - All rules justified
• Inbound/outbound restricted - Minimal access

Requirement 2: Secure Configuration

• Hardening standards - Systems hardened
• Unnecessary services disabled - Minimal attack surface
• Security parameters - Properly configured
• One function per server - Where possible
• Non-console admin encrypted - SSH, TLS for admin

Requirement 3: Protect Stored Data

• Cardholder data minimized - Only store what’s needed
• PAN masked - Display only last 4 digits
• PAN encrypted - If stored (avoid if possible)
• Encryption keys managed - Secure key management
• Sensitive auth data - Not stored after authorization

Requirement 4: Encrypt Transmission

• TLS 1.2+ - For all cardholder data transmission
• Certificates valid - Not expired, trusted CA
• No fallback - Insecure protocols disabled
• Wireless encryption - WPA2/WPA3 for WiFi

Requirement 5: Anti-Malware

• Antivirus deployed - On all systems
• Signatures updated - Automatic updates
• Scans scheduled - Regular scans running
• Logs reviewed - Alerts investigated

Requirement 6: Secure Development

• Secure SDLC - Security in development lifecycle
• Code review - All changes reviewed
• Vulnerability testing - Regular security testing
• Patches applied - Critical patches within 30 days
• Change management - Formal change process

Requirement 7: Access Control

• Need to know - Access based on job function
• Access approval - Documented authorization
• Default deny - Unless explicitly allowed
• Privileged access limited - Minimal admin accounts

Requirement 8: User Identification

• Unique IDs - Each user has unique account
• Strong passwords - Complexity requirements
• MFA for remote - Two-factor for remote access
• Account lockout - After failed attempts
• Session timeout - Idle sessions terminated

Requirement 9: Physical Security

• Physical access controlled - To systems with card data
• Visitor procedures - Logged, escorted
• Media handling - Secure storage and destruction
• POS terminal security - Protected from tampering

Requirement 10: Logging & Monitoring

• Audit logs enabled - All access to card data
• Log integrity - Protected from modification
• Time synchronization - All systems synced
• Log review - Daily review process
• Log retention - At least 1 year, 3 months online

Requirement 11: Security Testing

• Vulnerability scans - Quarterly external scans
• Internal scans - Quarterly internal scans
• Penetration testing - Annual pen test
• IDS/IPS - Intrusion detection in place
• Change detection - File integrity monitoring

Requirement 12: Security Policies

• Security policy - Documented and published
• Risk assessment - Annual risk assessment
• User awareness - Security training program
• Incident response - Plan documented and tested
• Service providers - Compliant or managed

Using These Checklists

Digital Tracking

Create issues or tasks for each checklist item in your project management tool:

# Example: Create GitHub issues from checklist
/dev-team create issues from deployment checklist

Print and Check

Print physical copies for:

• End-of-Day Checklist (daily use)
• Tenant Onboarding (per new customer)
• Go-Live Checklist (major deployments)

Team Responsibility

Assign checklist sections to team members:

Checklists ensure consistency. Use them every time, not just when you remember.