# Startup Operations Checklist Bundle Version 1.0 By ReadyOps AI Seven practical checklists for early-stage startup teams that need cleaner execution without building a full ops playbook from scratch. Built for teams with 2 to 20 people. ## How To Use This Bundle Copy each checklist into your docs tool, assign one owner, add dates, and trim anything that does not apply. The goal is not to complete every line forever. The goal is to prevent obvious misses during busy weeks. Recommended operating rule: 1. Put one directly responsible owner on every checklist. 2. Mark each item as done, not done, or not applicable. 3. Add due dates to anything that depends on timing. 4. Review misses within 48 hours and update the checklist once. ## Quick Template Use this header before any checklist: ```text Checklist owner: Team: Use case: Review date: Success condition: ``` --- ## 1) New Hire Onboarding Checklist **Use when:** A new full-time or part-time team member is joining. **Owner:** Hiring manager or ops lead **Success condition:** The new hire can access the right tools, understands priorities, and knows who to ask for help by the end of week one. ### Before Start Date - [ ] Confirm role title, manager, compensation, and start date in writing. - [ ] Create company email, calendar, chat, and password manager access. - [ ] Grant only the systems needed for the role on day one. - [ ] Prepare laptop, peripherals, shipping details, or office setup. - [ ] Draft a 30-day ramp plan with expected outcomes. - [ ] Schedule intro meetings with manager, founder, and closest collaborators. - [ ] Assign an onboarding buddy for practical questions. - [ ] Add the new hire to payroll, benefits, and required compliance steps. ### Day One - [ ] Share the week one schedule before the first meeting starts. - [ ] Walk through company mission, current goals, and how the role connects to them. - [ ] Review communication norms, meeting cadence, and documentation expectations. - [ ] Confirm the new hire can log in to every critical tool. - [ ] Explain what success looks like in the first 30 days. - [ ] Set up one regular manager check-in. ### Week One - [ ] Review current priorities, key metrics, and open risks. - [ ] Give the new hire one real task with a clear owner and deadline. - [ ] Confirm access to historical docs, plans, and past decisions. - [ ] Ask what still feels unclear after the first few days. - [ ] Capture onboarding issues so the process improves for the next hire. --- ## 2) Weekly Team Standup Checklist **Use when:** Running the core team sync for a small startup. **Owner:** Team lead, founder, or function head **Success condition:** Everyone leaves knowing top priorities, blockers, and decisions needed this week. ### Before the Meeting - [ ] Share the agenda and expected duration. - [ ] Ask each person to post their top priority, blocker, and help needed. - [ ] Pull forward any open actions from last week. - [ ] Confirm the metrics or project dashboard is updated. ### During the Meeting - [ ] Start with company or team goal for the week. - [ ] Review wins quickly without letting updates drift long. - [ ] Confirm the top one to three priorities for each function. - [ ] Surface blockers that need cross-team help. - [ ] Decide what needs escalation versus what stays local. - [ ] Record owners and dates for decisions made live. - [ ] End on risks, dependencies, and deadlines for the next seven days. ### After the Meeting - [ ] Send notes with owners and due dates the same day. - [ ] Move unresolved blockers to the right follow-up thread. - [ ] Cancel work that no longer supports the week’s priorities. --- ## 3) Product Launch Checklist **Use when:** Shipping a feature, campaign, or new product. **Owner:** Launch lead or product owner **Success condition:** The team knows what is launching, why it matters, what could break, and who is on point on launch day. ### Scope and Readiness - [ ] Define the launch goal in one sentence. - [ ] Confirm target users, release date, and success metric. - [ ] Freeze the scope or document what is explicitly out of scope. - [ ] Confirm launch owner, engineering owner, and comms owner. - [ ] Check that support, sales, and leadership know what is changing. ### Product and Operations Checks - [ ] QA the primary user flow in production-like conditions. - [ ] Confirm analytics, tracking, and error monitoring are live. - [ ] Review rollback plan and who can trigger it. - [ ] Confirm help docs, FAQs, and internal support notes are ready. - [ ] Check pricing, billing, permissions, and access rules if relevant. - [ ] Review legal or compliance sign-off if the release touches sensitive data. ### Launch Day - [ ] Post the go or no-go decision before launch starts. - [ ] Confirm owners are available during the launch window. - [ ] Monitor adoption, errors, and inbound support issues. - [ ] Send the internal launch note once the release is live. - [ ] Capture issues and next actions before the team logs off. ### 48-Hour Follow-Up - [ ] Compare early results against the launch goal. - [ ] Document the top three lessons while details are still fresh. - [ ] Schedule the first iteration or cleanup work. --- ## 4) Vendor Review Checklist **Use when:** Considering a new software tool, agency, or external service. **Owner:** Function lead with ops or finance support **Success condition:** The team chooses vendors based on clear need, risk, cost, and implementation effort instead of urgency alone. ### Need and Fit - [ ] Write the problem the vendor is supposed to solve. - [ ] Confirm the current workaround and why it is no longer enough. - [ ] Identify who will use the vendor weekly. - [ ] Check whether an existing tool can solve the same problem. - [ ] Define the minimum outcome required in the first 60 days. ### Risk and Implementation - [ ] Review security posture, data handling, and admin controls. - [ ] Confirm contract terms, renewal terms, and cancellation policy. - [ ] Estimate implementation time, owner, and hidden migration work. - [ ] Check integrations with your current stack. - [ ] Identify what breaks if the vendor underperforms or goes away. ### Commercial Review - [ ] Confirm total cost, not just starting price. - [ ] Check seat minimums, usage overages, and annual lock-ins. - [ ] Ask for startup pricing or pilot terms where possible. - [ ] Decide who approves the spend. ### Decision - [ ] Record the decision, rationale, owner, and next review date. - [ ] If approved, define the success metric for the first quarter. - [ ] If rejected, note the trigger that would justify revisiting later. --- ## 5) Quarterly Planning Checklist **Use when:** Setting priorities for the next quarter. **Owner:** Founder, team lead, or chief of staff **Success condition:** The team leaves with a short list of priorities, realistic capacity, and clear owners. ### Inputs - [ ] Review the last quarter’s goals, misses, and lessons. - [ ] Pull revenue, growth, product, customer, and operational metrics. - [ ] List major commitments already locked for next quarter. - [ ] Gather proposed priorities from functional leads. - [ ] Note key risks, hiring constraints, and cash limits. ### Prioritization - [ ] Choose the top three to five company priorities. - [ ] Cut or defer work that does not support those priorities. - [ ] Define one success metric for each priority. - [ ] Assign one accountable owner per priority. - [ ] Write the main dependencies and failure risks. ### Capacity Check - [ ] Compare planned work against actual team capacity. - [ ] Confirm headcount assumptions and hiring timing. - [ ] Flag any initiative that depends on one overloaded person. - [ ] Leave buffer for support, incidents, and unplanned work. ### Communication - [ ] Publish the final quarterly priorities in one visible place. - [ ] Explain what the team is not doing and why. - [ ] Set the review cadence for monthly checkpoints. --- ## 6) Tool Audit Checklist **Use when:** Reviewing software sprawl, cost, or access risk. **Owner:** Ops lead, finance lead, or IT owner **Success condition:** The company keeps only the tools that are useful, secure, and actively owned. ### Inventory - [ ] Export the current software list from finance, IT, or password manager records. - [ ] Confirm owner, purpose, renewal date, and annual cost for each tool. - [ ] Mark which tools contain customer, financial, or employee data. - [ ] Note tools with no clear internal owner. ### Usage and Value - [ ] Check seat utilization and last login data where available. - [ ] Identify duplicate tools solving the same job. - [ ] Ask teams which tools are mission-critical versus rarely used. - [ ] Flag tools that create friction but deliver low value. ### Access and Risk - [ ] Review admin access and shared account usage. - [ ] Remove access for former employees or inactive contractors. - [ ] Check SSO, MFA, and password hygiene for critical systems. - [ ] Confirm backup or export options for important data. ### Cleanup - [ ] Cancel unused or duplicate tools before renewal. - [ ] Downgrade plans where usage does not justify current spend. - [ ] Reassign ownership for tools that are staying. - [ ] Schedule the next audit date. --- ## 7) Incident Response Checklist **Use when:** A customer-facing outage, security issue, or severe internal disruption happens. **Owner:** Incident commander **Success condition:** The team stabilizes the issue quickly, communicates clearly, and captures lessons that reduce repeat failures. ### First 15 Minutes - [ ] Name one incident commander. - [ ] Confirm what is broken, who is affected, and current severity. - [ ] Create one live communication channel for responders. - [ ] Stop parallel speculation and assign one person to gather facts. - [ ] Decide whether customer communication is needed immediately. ### Stabilize - [ ] Protect users first: pause risky actions, roll back, or limit exposure. - [ ] Identify the fastest safe mitigation, not the perfect fix. - [ ] Log the timeline of actions taken. - [ ] Pull in only the people needed for the current stage. - [ ] Escalate to leadership if customer trust, revenue, or security is at risk. ### Communicate - [ ] Send an internal status update with impact, owner, and next update time. - [ ] Send an external update if customers are affected. - [ ] Keep updates factual, short, and timestamped. - [ ] Avoid promising root cause before it is confirmed. ### Recover - [ ] Confirm service is stable before declaring the incident resolved. - [ ] Identify any follow-up fixes that still need shipping. - [ ] Check for customer cleanup work such as credits, exports, or support replies. ### Postmortem - [ ] Hold a review within two business days. - [ ] Document root cause, contributing factors, and missed signals. - [ ] Assign owners and dates for prevention work. - [ ] Update the checklist or runbook based on what failed. --- ## Final Note These checklists should get shorter and sharper over time. If the same item is always skipped, rewrite it or remove it. If an avoidable problem keeps happening, add the missing check while the lesson is fresh.