Ship-and-Own Studio

The previous eight lessons gave you the concepts, frameworks, and vocabulary of responsible shipping. This lesson puts them together into a single workflow you can run on any project before you release it to the world. Treat this as a reusable process, not a one-time exercise.

The Ship-and-Own Checklist: A Structured Pre-Release Process

Professional engineering teams use pre-release checklists to ensure nothing critical is missed before code reaches users. The following checklist integrates everything from this module into a practical sequence. Work through it before shipping any project that others will depend on. PHASE 1: UNDERSTANDING WHAT YOU BUILT 1a. Can you describe in two to three plain sentences what your software does, including how it handles user data? 1b. Have you read every significant function in your codebase — especially any AI-generated code — well enough to explain what it does? 1c. Do you know what external services, APIs, or libraries your software contacts at runtime? PHASE 2: FUNCTIONALITY AND FAILURE 2a. Does the core function work reliably under realistic conditions — not just the happy path? 2b. What happens when inputs are missing, malformed, or malicious? Does the software fail gracefully? 2c. If a core dependency goes down, what does the user experience? PHASE 3: DEPLOYMENT AND CONFIGURATION 3a. Are all environment variables correctly set in the production environment? 3b. Have all necessary database migrations been run? 3c. Is there a monitoring or alerting setup that will notify you of errors? 3d. Do you have a rollback plan? PHASE 4: SAFETY AND RESPONSIBILITY 4a. Have you done a basic threat model (or STRIDE walk-through) on any features that handle sensitive data? 4b. Does the software collect only the minimum necessary data? 4c. Are all inputs validated before use? PHASE 5: LICENSING AND CREDIT 5a. Have you audited the licenses of all dependencies? 5b. Does your project have a LICENSE file? 5c. Have you attributed any external code you incorporated? PHASE 6: ACCESSIBILITY 6a. Can all interactive elements be reached and operated via keyboard? 6b. Do all images have appropriate alt text? 6c. Are all form inputs correctly labeled? 6d. Is color contrast sufficient for all text? PHASE 7: ACCOUNTABILITY 7a. Is there a way for users to contact you if something goes wrong? 7b. Have you documented what the software does, what it collects, and its known limitations — and made this available to users? 7c. Have you honestly assessed whether you can maintain this software after launch?

Running through the checklist is a process, not a one-pass scan. Some items will surface work you need to do: A gap in accessibility requires design and code changes before you ship. A missing environment variable in production requires coordination with your hosting platform. A GPL dependency in a commercial product requires a licensing decision before you go further. This is the purpose of the checklist: to surface these requirements while you still have time to address them, rather than discovering them through user harm or a failed deployment. The checklist also produces a record. If you keep the completed checklist — even informally — you have documentation that you exercised due diligence. This matters if a problem emerges later and you need to demonstrate that you acted responsibly.

When the Checklist Reveals You Are Not Ready

Running an honest pre-release checklist will sometimes tell you: not yet. This is the checklist working correctly. The pressure to ship — from yourself, from excitement, from a deadline — is real. Resisting that pressure when the checklist reveals unaddressed gaps is a professional discipline. Common responses to a failed checklist item: Address and recheck: fix the gap, then verify the fix addresses the criterion. Scope decision: explicitly descope a feature to avoid the problem, rather than shipping with a known gap. A feature that is not yet accessible should be clearly flagged or removed, not quietly shipped as-is. Document the limitation: for gaps you cannot address before launch, document them publicly. Known limitations disclosed honestly are far better than undisclosed problems discovered by users. Delay: sometimes the correct answer is a later launch date. A week of additional work that prevents a security incident or an accessibility failure is worth more than any launch-day momentum.