# Ship the Minimum Viable Automation: the WIRE Method first-build pattern Source: https://getstartedwithai.net/tutorials/wire-method-minimum-viable-automation Site: Get Started With AI Tagline: Build AI automations that actually run your business. Audience: solo professionals, freelancers, consultants and AI implementers in training Contact: hello@getstartedwithai.co.uk This Markdown companion is generated from the prerendered page for AI crawlers. # Ship the Minimum Viable Automation: the WIRE Method first-build pattern A logistics company I worked with automated invoice processing in three hours. The first version handled 85 percent of invoices cleanly and flagged the rest. Week one the human review queue was busy. By week four the queue was nearly empty because the edge cases turned out to be patterns, and patterns can be trained. Had they waited until the build was perfect before deploying it, they would have spent weeks anticipating edge cases that only show up on live data. The Minimum Viable Automation is the WIRE Method build cadence: ship the smallest version that proves the outcome, observe it daily for two weeks, then decide whether to polish. ## What you need - The first build picked by the Fastest Win rule. Build days estimate under 6, dependencies under 2, risk low or medium. - A named operator who runs the build daily for the first two weeks. Without the operator the daily review fails. - A monitoring sheet with three columns: outputs reviewed, outputs accepted, outputs corrected. The sheet is the source of truth for the polish decision. - 14 calendar days from kick-off to the polish decision. Most of those days are observation, not building. ## The MVA cadence in one paragraph Build the smallest version that produces the outcome on the happy path. Skip the edge cases and the polish, and ship in days. Watch it run on live data for two weeks. Log every output, mark accepted or corrected, note the pattern. Decide on day 15 whether to polish or move on. The discipline that makes this work is shipping early, not shipping perfect. ## Step 1: Define the happy path only (30 minutes) The happy path is the case the build handles 80 percent of the time. Define it precisely. Edge cases are deferred until the data justifies the work. 1. Write the happy path in one paragraph. Trigger, three to five steps, output. If it does not fit on one paragraph, the build is too big to be an MVA. 2. List the edge cases you know about. Do not handle them. Park them in a sheet for the polish decision. 3. Define the human-review rule: every output goes through the operator before going to the customer or the regulator for the first 14 days. ## Step 2: Build the happy path only (1 to 5 days) Build the smallest version. No clever logic, no edge case handling, no polish on the prompts. The point is to ship something running. 1. Use tools you already pay for. New tool procurement is a Fastest Win violation; the build is not the place to procure. 2. Ship in pairs. Trigger plus first step, test, add the next step, test. Building the whole thing before testing is the most common time-eater. 3. Stop at the happy path. The instinct to add the second branch is the instinct that kills MVA cadence; resist it. 4. Hand the build to the operator with a one-page runbook. The runbook says how to start it, how to stop it, how to log outputs, and who to call if it breaks. ## Step 3: Run the daily review for 14 days (15 minutes a day) The daily review is the discipline. Without it the MVA produces silent failures and the polish decision is made on guesswork. - Operator opens the monitoring sheet before logging off. Logs outputs reviewed, outputs accepted, outputs corrected. - Practitioner reviews the sheet on day 3, day 7 and day 14. Three checkpoints, each one a 5-minute scan. - Any correction gets a one-line reason in the sheet. Reasons cluster into 3 to 5 patterns by the end of week one. - Day 7 sanity check: if accepted-rate is below 70 percent the build needs a fix before continuing. Pause the build, fix, restart the 14-day clock. ## Step 4: The polish decision on day 15 (30 minutes) Day 15 you have 14 days of data. Three outcomes are possible. - Accepted-rate above 90 percent: the build is good as is. Move human review to a weekly sample, leave the rest of the build alone, and start the next build. - Accepted-rate 70 to 90 percent: polish is justified. Pick the top two correction patterns from the sheet and add the handling. One day of polish work, not five. - Accepted-rate below 70 percent: the happy path was wrong. Go back to the audit step and check the workflow assumption. The build is not the problem; the scope is. ## Step 5: Ship the polished version or move on (variable) If polish is justified, ship the polished version on day 17 or 18. If not, the operator runs the MVA as-is and you start build two. Either way, the daily-review discipline drops to weekly from day 15 onwards. ## What you ship A working automation in days, observed for 14 days on live data, with a polish decision based on a real number rather than gut feel. Most MVAs land at 80 to 90 percent accepted-rate by day 14; about a third need a one-day polish, the rest run as-is. ## What to build next Once the build is running for two weeks, hand it off properly. The wire-method-bus-test-handover tutorial walks through the documentation and named-owner protocol that turns the MVA into a build the business owns. After that, wire-method-four-breaks-monitoring keeps it alive past month three. ## Common mistakes - Building the polished version on day one. Three weeks lost to edge cases that the live data would have shown were not edge cases at all. - Skipping the daily review because the build "looks fine". The silent failures are exactly what the daily review catches. - Treating the 14-day clock as flexible. It is the discipline that makes MVA work; sliding it produces the same indecision the polish decision is meant to cut. - Adding edge case handling on day 6 because the operator complained. Note the complaint, log the pattern, decide on day 15. Building reactively inside the 14 days corrupts the data. ## Related builds More tutorials in WIRE Method. Each one runs in 60 to 90 minutes and ships a finished asset. ### The Monday Morning Test: find the work waiting to be automated in 15 minutes 30 to 60 minutes. Beginner + Solo Pro. [Open tutorial](/tutorials/wire-method-monday-morning-test) ### Calculate the Time Tax on every recurring process: the WIRE costing build 30 to 60 minutes. Solo Pro / Implementer. [Open tutorial](/tutorials/wire-method-time-tax-calculator) ### Pick the right first automation: the WIRE Method Fastest Win selection rule 30 to 60 minutes. Solo Pro / Implementer. [Open tutorial](/tutorials/wire-method-fastest-win-rule) ### Run the Bus Test before signing off: the WIRE Method handover protocol 30 to 60 minutes. Implementer. [Open tutorial](/tutorials/wire-method-bus-test-handover) ## Questions people ask before they start ### How is MVA different from MVP? MVP is about shipping the smallest version of a product to a customer. MVA is the same idea applied to an automation inside a business. The customer is the operator; the metric is accepted-rate, not paying users. ### Does this work for customer-facing automations? Yes, with a stricter human-review rule for the first 14 days. Every output goes through a named human before reaching the customer. The MVA cadence is the same; the safety net is wider. ### What if the operator does not have time for the daily review? The daily review is 15 minutes. If 15 minutes is not affordable, the build is not yet a priority and the candidate goes back to the queue. Do not ship an MVA without the operator review; the data is the build. ### Can the practitioner skip the daily review and rely on weekly sampling? No, not for the first 14 days. Weekly sampling is the steady state after day 15. The first two weeks need daily review because patterns surface fast and a missed week loses the polish decision. ### What does a failed MVA look like? Accepted-rate below 70 percent on day 7 with no obvious pattern in the corrections. The fix is to go back to the audit step. A failed MVA is rarely a tooling problem; it is usually a workflow assumption that did not match the real work.