The three types of checklists we use on every project: Daily, Project, and Deliverable

Why checklists work (and why teams resist them)

Checklists show up in every profession where complex operations can't afford predictable failure. Aviation runs on them. Surgery uses them. Professional kitchens live by them. The unifying logic is the same: humans are good at judgment and bad at remembering routine items under pressure. Checklists take the remembering off the team's shoulders so the judgment can run at full capacity.

The common resistance we hear (including from our own team when we introduced more checklist discipline): "this feels bureaucratic." Well-designed checklists feel like the opposite. They free the team to think about the interesting parts of the work instead of constantly running a mental audit of "did I forget anything?" A team without checklists isn't a team with more freedom. It's a team with the same amount of freedom, plus a steady background anxiety about what's falling through the cracks.

We use three checklist types at SUFFIX, each solving a different kind of failure.

Daily Checklist

Daily Checklists are the in-the-moment kind. At the start of each day, each person posts what they're working on. At the end of the day, they post status on each item ([Done], [In-Progress], or [Struck] if blocked). The format and the reasoning are covered in detail in our remote work playbook, so we won't repeat all of it here.

The core value this checklist provides: the team can see what everyone is working on today, what's done, and where anyone is stuck, without anyone having to ask. In remote or hybrid setups, this replaces the ambient information an office used to provide. In co-located teams, it still helps because memory fades and hand-offs happen.

Daily Checklists fail when they become performative (people list everything they touched instead of the actual priorities) or when blockers get logged and then ignored. The [Struck] status is only useful if the team actually jumps in to help when it appears.

Project Checklist

Project Checklists are the milestone-level kind. At the start of a project, we lay out the full arc of the engagement, from brief to handoff, as a sequence of named milestones with the tasks that belong to each. Anyone on the team can look at the checklist and know where we are, what's next, and what depends on what.

Different project types need different templates. A typical web project looks something like:

- Brief intake: Client conversation, requirements gathered, scope clarified.

- Quote and agreement: Pricing, timeline, scope of work signed.

- Information architecture and wireframes: Structure validated before visual work starts.

- Design: Mockups developed, reviewed, iterated.

- Feedback and revisions: Structured client reviews, changes incorporated.

- Development: Front-end and back-end built against the approved design.

- QA and testing: Cross-browser, performance, accessibility checks.

- Launch preparation: Deliverable checklist cleared (see below), staging validated.

- Launch: Go-live with monitoring in place.

- Handoff: Documentation, training, transfer of any credentials, post-launch support window.

Campaign projects, content projects, and research projects have different templates. A marketing campaign, for example, runs through audience definition, creative development, media planning, asset production, launch, in-flight optimization, and post-campaign reporting. Each template lives in our shared workspace and gets updated after every project based on what we learned.

The practical value of the Project Checklist is that the project lead doesn't have to constantly ask the team "where are we?" They can check the list. The team doesn't have to constantly reconstruct the plan from memory. They can check the list. And new teammates joining mid-project can orient themselves in minutes instead of days.

Without one, projects drift. Work gets done out of order. Dependencies surface late. Someone realizes at week six that a decision needed in week three never got made, and the team backtracks.

Deliverable Checklist

Deliverable Checklists cover the small items that make or break a finished product at launch. Individually, none of them are exciting. Collectively, they're the difference between a launch that looks professional and one that looks unfinished.

For a web project, the typical deliverable checklist includes:

- Domain and hosting: Either configured by us or collected from the client with access credentials confirmed.

- SSL certificate: Installed and valid. Mixed-content warnings resolved.

- Google Analytics or equivalent: Tracking code installed, goal conversions configured, test events verified.

- Favicon: Present in the right sizes for browsers and devices. Not the framework's default square.

- Meta tags and Open Graph: Title, description, and social share preview for every page. Checked across social platforms.

- Sitemap.xml and robots.txt: Submitted and indexed appropriately.

- 404 page: Custom, branded, and actually helpful (not just "Page Not Found").

- Redirect rules: Old URLs mapped to new URLs so SEO and bookmarks don't break.

- Legal pages: Privacy policy, terms of service, cookie notice where required.

- Performance baseline: Page speed and Core Web Vitals tested before launch, noted as the comparison point for future work.

- Accessibility pass: Contrast, keyboard navigation, alt text, focus states, form labels all validated.

- Tracking pixel:. Ad platform pixels installed if the brand runs paid campaigns, with events firing correctly.

Any of these can be missed. Most teams have missed most of them at some point. The Deliverable Checklist exists because these items are individually forgettable and collectively mandatory.

An additional benefit of defining the Deliverable Checklist at project kickoff: the team knows from day one what to collect from the client. Instead of asking for the Google Analytics ID three weeks before launch and finding out the client doesn't have one, we ask at the start and the team has time to set things up properly.

Campaign and content projects have their own deliverable lists. For a campaign: assets in every required format and size, tracking URLs set up, approval documentation filed, handoff to the media team with a briefing document, and so on. Build the template once per project type, refine it over time.

How to design a checklist that actually gets used

The checklist that sits in a shared doc and nobody opens isn't helping anyone. Principles we use:

- Items are concrete and binary: "Configure Google Analytics" is checkable. "Set up analytics properly" is not. You either did it or you didn't.

- Ordered by when they happen: The list follows the actual workflow, not a logical grouping. This makes it usable in the moment instead of requiring the user to search for the relevant item.

- Named owner per item: If it's everyone's responsibility, it's nobody's. Write the owner's name or role next to the item.

- Short enough to actually use: A 50-item checklist nobody reads is worse than a 10-item checklist everyone does. Trim ruthlessly. If an item is always done, take it off the list. If it's rarely relevant, make it a conditional sub-list.

- Reviewed and updated after every project: Things that caused problems this time become items next time. Things that never caused problems get cut. A checklist that doesn't evolve stops reflecting the real work.

Where checklists live matters less than whether they're used. Notion, Asana, Linear, Trello, a Google Sheet, or a printed sheet on the wall can all work. What matters is that the team agrees where the checklist lives, keeps it current, and actually refers to it rather than working from memory.

What NOT to checklist

Checklists aren't universal. They work for repeatable, operational tasks with clear pass/fail states. They fail in three common ways:

- Applied to creative work: You can't checklist the process of figuring out a brand direction or designing a landing page layout. Those require judgment, iteration, and taste. Checklisting them produces compliance theater: items get checked without the underlying work being better.

- Bureaucratic compliance, not operational aid: When checklists exist so managers can tick boxes for reporting rather than to help the team, they become paperwork. Teams stop engaging with them honestly. The value disappears.

- Confusing "checked" with "quality.": Checklists are floors, not ceilings. A passed deliverable checklist means the basics are in place. It doesn't mean the work is good. Teams that treat the checklist as the full quality assessment end up shipping technically complete but substantively weak work.

The rule of thumb: checklists belong on the repeatable, high-consequence-if-missed parts of the work. The creative, judgment-based parts still belong to the team's thinking. When we get this boundary right, the team focuses on the interesting decisions and stops spending energy on remembering the routine ones.

The cultural effect

Beyond the operational value, sustained use of checklists changes how a team works together. Handoffs get cleaner because the receiving party can see exactly what was done. New teammates ramp faster because the institutional knowledge is written down rather than locked in senior heads. Projects run more predictably because the common failure modes are captured and prevented rather than rediscovered each time.

The three checklists above aren't the only ones we use. They're the three that scale across every project type, and they're the backbone of how we make sure complex work ships on time without the things that make finished work look unfinished.