Why Your First AI Project Should Be Boring

Founders pick AI projects for visibility. The ones that ship are narrow, repetitive, and boring. Here's the gap between those two facts.

Somewhere between 80 and 95 percent of AI projects fail before they reach production, according to Pertama Partners and SP Global data reported by CIO Dive. That range is wide enough to be uncomfortable. What makes it worse is that the causes are not technical. Pertama Partners identifies misaligned project purpose and absent success metrics as the leading failure drivers — both of which get decided before a single engineer writes a line of code.

The project you want to build is the one most likely to stall

Founders gravitating toward ambitious first AI projects are not being irrational. McKinsey and QuantumBlack argue that organizations need high-visibility "lighthouse" projects to sustain AI investment, and that narrow use cases fail to justify the cost or reach strategic goals. That argument is coherent. It is also built on an assumption the data does not support: that ambitious projects generate the visible wins needed to keep funding alive.

A project that stalls in pilot, burns through six months of engineering capacity, and never ships generates no investor story. It generates a write-off. The lighthouse argument skips that outcome entirely.

What actually ships

SME adoption case research shows a consistent pattern. Narrow, workflow-specific AI projects reach production and stay in use. The reason is structural, not motivational. A single-workflow project with one measurable output eliminates misaligned scope by construction. You cannot misalign scope when there is only one job. You cannot lack success metrics when you have defined one output. The data gap problem shrinks because you are pulling from one process you already own, not assembling a cross-functional dataset you have never touched.

The ACM/IJIM study on AI critical success factors identifies clear organizational purpose and defined success metrics as the two conditions most correlated with implementation success. A narrow, single-metric project satisfies both before the build begins. A high-visibility transformation project reliably satisfies neither.

I have watched founders spend four months scoping an AI feature that would "reimagine the customer onboarding experience" — complete with a Notion doc, a Figma prototype, and a vendor demo from a company whose name I will not say but whose pricing page requires a sales call. Nothing shipped. The founder who spent three weeks automating their own support ticket triage with a fine-tuned classifier had a working feature in production by week four and a measurable drop in first-response time by week six.

The checklist that removes the decision

Practitioner guides from engineers and consultants who have run these builds independently converge on the same selection criteria. Before committing to a first AI project, work through these:

• One job. The project does one thing. Not "improves the workflow" — names the specific task.
• One metric. You have defined what success looks like in a number you already track.
• Data you own. The training or context data exists in a format you control right now, not after a six-week integration.
• A workflow you understand without AI. If you cannot describe the manual process step by step, you are not ready to automate it.
• A human review step. Someone checks outputs before they affect a customer or a downstream system.

If a project fails any of these, it is not a candidate for your first build. Put it on a list for later.

The unsexy project is the proof point

The narrow project is not the end state. It is the thing that gives you real production data, a working deployment, and a concrete number to show. A founder with a working AI feature in production has something to build from. A founder with a stalled ambitious project has a story about why AI is harder than expected.

Pick the boring one first.