The Sourdough Bakery's Ordering App

The strongest choice is the subscription order-form service plus a manual pricing step, not the custom app. Constraints point this way:

• Time: eight weeks is short, and the custom app has no specification, so requirements discovery alone could consume the available weeks. The subscription service is live in days.
• Budget: $3,800 up front consumes almost the whole budget with no contingency, and payment before delivery transfers all risk to the bakery. At $45 per month the service costs $360 over eight weeks, leaving room for a contingency.
• Skills and capacity: only six hours per week are available from one person, and the other owner is resistant. A low-configuration tool reduces the training burden and the change-management friction; a bespoke app would need ongoing maintenance nobody can supply.
• Fitness for purpose: the service cannot do tiered pricing, but that is a calculation, not a record-keeping problem. A staff member can price each order manually and enter the final figure, which is acceptable at 60 orders per week.

Risk accepted: manual pricing introduces human error and does not scale if orders keep growing. Mitigation is a second-person check on any order above a set value and a review at the end of the season. Rejecting the custom app is a judgement about unquantified scope, not a claim that custom software is bad.

Use an iterative cycle rather than a single waterfall pass, because the requirements are still moving.

1. Investigate and define (weeks 1-2): interview both owners, list every field an order needs, and write a one-page requirements statement including the tiered-pricing exception. Deliverable: agreed requirements and acceptance criteria.
2. Design (week 2): sketch the order form layout and the daily production checklist. Deliverable: wireframe and a data dictionary for order fields.
3. Build and configure (weeks 3-4): set up the subscription form, test it with ten real historical orders replayed as if new. Deliverable: working form plus a test log comparing expected and actual outputs.
4. Test and refine (week 5): have the reluctant owner place three orders unaided. Any confusion becomes a design change, not a training note. Deliverable: revised form and a short user guide.
5. Implement and train (week 6): run paper and digital systems in parallel for one week, then retire the paper book. Deliverable: cutover checklist and a rollback plan.
6. Evaluate (weeks 7-8): measure wrong-date incidents and time per order against the baseline. Deliverable: short evaluation report and a decision on whether to revisit custom software next season.

Each stage has an exit condition, so the project can be stopped or changed without losing the whole investment.

Treat this as a legitimate concern about disruption, not as resistance to be overruled. The spreadsheet has in fact failed: two wrong-date orders in one month is a measurable defect with a real cost in wasted ingredients and damaged reputation.

Gather evidence rather than argue:

• Count errors over the last eight weeks from the order book, not from memory.
• Estimate the cost of each error, including remade cakes and any discount offered.
• Time how long an order currently takes to record and how often the two owners duplicate or contradict each other.
• Ask the reluctant owner what specifically worries them, for example losing familiar records or being blamed for mistakes.

Then propose a low-risk trial: keep the spreadsheet as a read-only archive, run the new form alongside it for one week, and agree in advance what result would justify continuing. Give that owner a defined role such as checking daily orders, so the change is shared. If the trial shows no improvement, that is a finding worth acting on. Framing the decision as an experiment with an agreed exit criterion lowers the perceived risk and respects the person's expertise about the business.