# Pick the right first automation: the WIRE Method Fastest Win selection rule Source: https://getstartedwithai.net/tutorials/wire-method-fastest-win-rule 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. # Pick the right first automation: the WIRE Method Fastest Win selection rule A recruitment firm I worked with had five candidates from their WIRE audit. The biggest Time Tax sat on interview scheduling at £42,000 a year. They wanted to start there. I pushed back. Scheduling involves candidates, hiring managers, internal calendars and four exception types; it was a third or fourth automation, not a first. We compromised and ran scheduling alongside CV screening. CV screening shipped in two days and was working in week one. Scheduling took six weeks to get right. The Fastest Win rule is what I should have insisted on more loudly. It picks the build that ships fastest from the top three, not the build with the biggest theoretical saving, and the rule has paid for itself on every project since. ## What you need - The top three candidates by Time Tax from the calculator step. - A scoring sheet with three columns: build days, external dependencies, risk score. - Honest input from the operator who currently does the work. The build-days estimate fails when the practitioner guesses without the operator in the room. - 20 minutes uninterrupted to score and pick. ## Why the biggest Time Tax is rarely the right first build The build that ships fastest produces real data, builds team confidence, and funds the second build. The biggest theoretical saving usually carries the most edge cases, the most external dependencies and the longest scoping cycle. It also takes longer to break, which means longer before you learn what is actually wrong. - A two-day build that saves £8,000 a year ships in week one and the savings start in week two. - A six-week build that saves £40,000 a year ships in month two; six weeks of cash flow lost to the build, plus the operator confidence that erodes when the build slips. - On freed-hours economics, the two-day build pays back inside the first 30 days and funds the bigger build out of saved time. ## Step 1: Score build days for each candidate (5 minutes) Build days is the realistic number of working days from kick-off to a working version that the operator uses. Round up; under-estimating build days is the single most common WIRE error. - Single-trigger, single-output, single-tool: 1 to 2 days. Email triage, file naming, simple data entry. - Multi-step inside one tool, no integrations: 2 to 4 days. Status report drafting, FAQ generation, document review. - Two or three tools wired together with one Zap or Make scenario: 3 to 6 days. Onboarding sequences, simple CRM updates. - Four or more tools, multiple decision branches, exception handling: 8 to 20 days. Interview scheduling, multi-step quote generation, complex routing. ## Step 2: Score external dependencies (5 minutes) A dependency is anything outside your control that the build needs. Each dependency adds risk and slows the build. Score 0 for none, 1 for one, 2 for two, 3+ for danger. - 0 dependencies: tools you already pay for, data that already exists in the format you need. Ships clean. - 1 dependency: one new tool, or one data export the operator can produce. Manageable. - 2 dependencies: a new tool plus a new data feed, or two new APIs. Build days double. - 3+ dependencies: external API access, IT sign-off, vendor integration. The build moves out of Fastest Win territory and into a project plan. ## Step 3: Score risk (5 minutes) Risk is the cost of the build going wrong publicly. Customer-facing builds carry higher risk; internal admin builds carry lower risk. Score low, medium or high. - Low risk: internal admin, internal reporting, file management. A bad output is a 5-minute fix. - Medium risk: internal-facing decisions, draft-then-human-send. A bad output is a 30-minute review and resend. - High risk: customer-facing automation with no human review, regulator-facing output, financial calculation. A bad output is a complaint, a refund, or worse. - Default rule: the first build is always low or medium risk. High-risk builds wait until the team has shipped two or three smaller automations and the monitoring is proven. ## Step 4: Apply the Fastest Win rule (5 minutes) The rule has three parts. Run them in order and the answer falls out. 1. Eliminate any candidate scoring 3+ dependencies or High risk. They are not first builds. 2. Of the remaining candidates, pick the one with the lowest build days. If two are tied, pick the one with fewer dependencies. 3. If the chosen candidate has the smallest Time Tax of the three, accept it anyway. Confidence and freed hours fund the bigger build next. 4. Sanity check: the chosen build ships in under 6 working days and saves at least £5,000 a year of Time Tax. Anything outside those bounds is the wrong first build. ## The freed-hours flywheel The Fastest Win rule sets up the compounding pattern that funds every build after the first. The hour saved every week from build one funds the operator time on build two. The hours saved across builds one and two fund build three. Three or four small builds in the first 90 days produce the freed-hours budget for a bigger build in month four. ## What you ship The first build picked, with build days under 6, fewer than 2 external dependencies, and a Time Tax of at least £5,000 a year. The other two candidates from the top three move to the queue for builds two and three. The full three-build sequence usually ships in 8 weeks and frees 6 to 10 hours per week of operator time. ## What to build next Now go and ship the chosen build. The wire-method-minimum-viable-automation tutorial walks through the build cadence: smallest version that proves the outcome, daily review for two weeks, then decide whether to polish. ## Common mistakes - Letting the partner pick the first build because the saving is biggest. The partner has not done the build days estimate; the operator has, and the operator is right more often than the partner. - Treating dependencies as a procurement problem. Each dependency is a build-day multiplier; resolving them up front is cheaper than discovering them in week three. - Skipping the risk score because the team is keen. A high-risk first build that fails kills team confidence in AI for six months. - Picking the same kind of automation as the practitioner has built before. The point of the Fastest Win is to ship for this team on this stack; old patterns can mislead. ## 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) ### Ship the Minimum Viable Automation: the WIRE Method first-build pattern 30 to 60 minutes. Solo Pro / Implementer. [Open tutorial](/tutorials/wire-method-minimum-viable-automation) ### 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 ### Is the Fastest Win rule just MVP for AI? Related, not identical. MVP is about shipping the smallest version of a single product. Fastest Win is about choosing which automation gets built first across a list. The MVP cadence applies inside the build that the Fastest Win selected. ### What if all three candidates score 3+ dependencies? Go back to the candidate list and pull the next three by Time Tax. If the next three also score 3+ dependencies, the business is not yet ready for an AI build; the audit step needs to surface lower-dependency loops first. ### How do I score build days if I have never built this kind of automation before? Take your gut estimate and double it. The first time you build any new pattern, it takes twice as long as the second time. The second build of the same pattern slots back to the gut estimate. ### Should I always pick low risk over medium risk? For a first build, yes. For build two and onwards, medium risk is fine because the team has the operator confidence and the monitoring discipline from build one. ### What if the chosen build only saves £4,000 a year? Accept it as a learning build but treat it as a confidence builder, not the saving. The smaller saving funds the operator hours for the next build, and the next build is where the big number lands.