A real-life example of checklist-driven development
For a non-technical business owner who wants to build the right software without wasting time and money, the best approach is to use Checklist-Driven Development.
Here’s a real-life example of a checklist I used to build software that helped keep a solopreneur from needing to hire additional help for his back-office work.
When an email comes in for a design request, determine if the person emailing is on a monthly team plan, or if the request is a lá carte.
You can use Stripe to find a list of customers on the monthly team plan.
If the request is not on a monthly team plan, create a Stripe payment link and send it back to the person requesting the design.
If the requester is on a monthly team plan, create a new ticket in Trello on the appropriate team board and move it to the “Ready for Work” column.
Otherwise, create a ticket in the general Trello board, and place it under “Awaiting Payment”. Be sure to assign the email address and Stripe payment ID to the card so the ticket is associated with an outstanding payment.
When an email notification from Stripe says a payment was made, find the Trello card associated with the payment made via Stripe. Move that card to “Ready for Work”.
You can find the correct ticket by the Stripe ID that was assigned to the ticket in the previous step.
This is a simple example of what you would need to outline for someone to do this process reliably, repeatedly, and without errors. This example is a straightforward process that does not have a lot of logic, but notice how specific we needed to be to ensure things were done correctly. Some pieces could be explained in greater depth. There are assumptions and missing details. For example:
What if a team just signed up for a team plan and doesn’t have a board yet?
How do I create a payment link in Stripe?
What happens to payments that are never made? Do we eventually remove those tickets?
We see that to create a robust system, we must account for many unspoken rules that you, as the owner, just know intuitively. The act of writing them down codifies them so that they can be explained, repeated, and even built into an automated system.
🔑 Key Takeaways
Getting knowledge from inside your head down onto paper is an iterative process that can be simulated by creating a checklist.
A checklist highlights questions and assumptions that need to be answered before building your software.