Six Weeks to Your First AI Pilot, No IT Team Needed

Most founders who fail at AI adoption do not fail because they chose the wrong tool. They fail because they started five experiments in the same month and finished none of them. A chatbot for customer questions, an AI writing assistant for proposals, an automation for invoice follow-ups — all running in parallel, all abandoned by week three when a client crisis arrived.

The comprehensive readiness frameworks from Microsoft, Google, and AWS were not built for this problem. They were built for organizations with a dedicated IT function, a change manager, and time to run steering committee reviews. Stripping those frameworks down to what a founder with no IT staff actually needs takes longer than most founders have. So they skip the framework entirely and scatter.

The sprint is not a cure, and naming that matters

A six-week sprint scoped to one business outcome does not make you AI-ready. It makes you ready for one specific AI task, in one specific context, using one specific tool. When the next use case arrives — a different workflow, a different data type — you will not have a decision architecture for evaluating it. You will have one working pilot and the same blank-page problem you started with, now at higher stakes because something is already running in production.

That is a real limit. Acknowledging it before week one changes how you run the sprint. You are not building AI readiness. You are building one concrete outcome and a repeatable six-week process you can run again. The second sprint will be faster. The third faster still. The organizational depth that comprehensive frameworks promise gets built in iterations, not in a single program, and for a sub-10-person business, iterations are the only realistic path anyway.

What the six weeks actually cover

Pick one business outcome before the sprint starts. Not "get better at AI." Something like: reduce the time spent drafting client proposals, or get a first-pass answer to customer questions without pulling someone off another task. One outcome. One workflow. Everything else waits.

Week one is a data audit. Open a shared Google Sheet — free, no setup — and list every place you store information relevant to that workflow. Your CRM, your inbox, your accounting tool, and your project management app each hold a different version of the same customer record, and none of them agree. That disagreement is what breaks AI tools before they start. You do not need to fix all of it in week one. You need to know where the disagreements are.

Week two is tool selection. For most single-workflow pilots, the free tier of ChatGPT, Claude, or Google's Gemini is sufficient. The selection criterion is not which tool is most capable in the abstract. It is which tool accepts the data format you already have and produces output your team will use without reformatting it. Run each candidate on five real examples from your workflow. The one with the lowest failure rate on your actual data wins, not the one with the best marketing page.

Week three is a policy decision, and founders skip this one most often. Before any AI tool touches customer data, you need one document — one page, not a policy manual — that answers four questions: what data goes into the tool, what data never does, who reviews the output before it leaves the business, and what happens when the output is wrong. Google Docs, one page, shared with everyone who will touch the workflow. Done.

Week four is a controlled pilot. Ten to twenty real tasks, real data, real output reviewed by a human before it goes anywhere. You are not measuring whether the AI is impressive. You are measuring whether the output is usable as-is, needs light editing, or needs to be thrown out. Track those three categories in the same Google Sheet from week one. The ratio tells you whether the tool earns a wider rollout or needs a different prompt structure.

Week five is prompt refinement based on what week four showed you. If forty percent of outputs needed to be thrown out, the problem is almost never the tool. It is the input. Tighten the prompt, add one or two examples of what good output looks like, and rerun the same twenty tasks. Compare the ratios.

Week six is a decision, not a celebration. Keep the pilot running and expand it, pause it and fix the data quality problem week one revealed, or stop and pick a different workflow. All three outcomes are valid. The sprint fails only if you end week six without a decision.

Free tools hold until they do not

The entire sprint runs on tools with free tiers: Google Sheets for tracking, Google Docs for the policy page, and whichever AI tool passed the week-two test. The free tiers of these tools are adequate for a pilot. They are not adequate for production at scale, and you will hit the limits faster than the pricing pages suggest if your workflow involves large files or high volume.

Build the pilot on free tools. Make the decision about paid tiers after week six, when you have actual usage data to justify the cost. Committing to a paid plan before the pilot runs is the same mistake as buying a gym membership in January.

What six weeks actually proves

A completed sprint gives you one working AI outcome, one data set showing what the tool does in your specific business, and a six-week process you now know how to run. It does not give you an AI strategy. It gives you evidence where you previously had only anxiety and vendor claims.

The founders who stall longest on AI adoption are not the ones who tried and failed. They are the ones who spent eighteen months reading about AI without running a single controlled test on their own data. Six weeks and a Google Sheet ends that.