When a website actually needs machine learning — and when…

A website needs machine learning when the job is pattern recognition or prediction that rules and search cannot cover well at scale. Rules and search are often enough for clear policies, catalogs, and findability. Prefer a written decision before you hire anyone to “add AI.”

I get this from founders and product owners who were told to “add ML” and are unsure it is needed. This is a decide post, not an integrate how-to. If you already know you need a model in a Next.js product, jump to the sibling on how to integrate a machine learning model into a Next.js product. Here we stay on whether ML earns a seat at all.

Short answer

Use machine learning when patterns beat hand-written rules at the scale you actually have. Prefer rules and search when the problem is enumerable, policy-driven, or mostly about finding known content.

ML is a tool with data, ops, and failure modes. Rules and filters are often the honest product.

What people mean by “add ML to the website”

When someone says “add ML to the site,” they usually mean one of a few jobs. Naming the job stops fake-AI SOWs.

Ranking. Order results, feeds, or leads by predicted usefulness, not only by a fixed sort.
Recommendations. Suggest products, content, or next actions from behavior and similarity.
Classification. Label tickets, reviews, uploads, or spam risk into buckets.
Generation. Draft text, summaries, or structured fields from prompts and context.

Marketing buzz (“AI-powered”) is not a job. If the brief cannot name ranking, recommendations, classification, generation, or another concrete prediction task, you have a slide, not a model requirement yet.

When rules are enough

I push teams toward rules when most of these are true.

Business policy is clear and stable (eligibility, pricing tiers, access, compliance gates).
The state space is small enough that a human can list the cases and expected outcomes.
You need explainability for audits, support, or regulated flows. “The model said so” is not enough.
Errors have a known fix path: change the rule, publish, done.

Rules are software you can read. If a spreadsheet or a config table already captures the decision, start there. You can always add a model later if the rule set becomes a mess of exceptions that no one can maintain.

When search (and filters) are enough

Findability problems are often mislabeled as ML problems.

Catalogs, docs, help centers, and blogs usually need better indexing, synonyms, facets, and filters before a recommender.
Users asking “where is X” need retrieval, not a black-box score.
Empty results and bad taxonomy hurt more than the absence of a model.

Improve search and filters first. Measure whether people find what they came for. If ranking still fails after clean metadata and solid query handling, then talk about learned ranking. Do not skip the boring layer because “AI” sounds better in a deck.

When ML earns its keep on a site

ML starts to earn its keep when the product has a real pattern problem.

Noisy inputs. Free text, images, messy user behavior, or signals that do not map cleanly to if/else.
Personalization at scale. Too many users and items for hand-tuned segments to stay honest.
Signals rules cannot enumerate. Combinations and weak cues that only show up in volume, not in a policy meeting.

Even then, write a measurement plan before you hire. Define what “better” means in product terms: fewer false labels, better click quality on known sets, faster triage, fewer support loops. Without a measurement plan, you are buying a model and hoping, and hope is not acceptance criteria.

I will not invent ROI percentages or case-study clients here. Your decision should rest on the job, the data you can own, and whether you can tell when the model is wrong.

When not to

No labeled data and no owner. If nobody will label, maintain, or review outputs, the model will rot.
“AI” as a slide. If the only requirement is to say the product is AI-powered, stop. That is branding, not Build scope.
Problems that are really UX or content debt. Confusing navigation, thin copy, broken taxonomy, and slow pages do not need a model, they need product work.
Assume everyone needs ML. Many sites ship well with rules, search, and clear product logic.

Killing a fake-ML SOW early is a win, and it saves budget for the constraint you actually have.

If you decide yes

If the decision is yes, the next job is integration shape, not another definition essay. For a Next.js product, start with a thin input/output contract, a versioned inference path or worker, auth, logging, and a fallback. I walk that path in how to integrate a machine learning model into a Next.js product (without boiling the ocean).

This post stops at the decision. Do not treat it as a remake of SEO-with-AI tips or a generic “optimize the website with AI” checklist. Those are different intents.

If you have written the decision, named the job, and still need help scoping or shipping the Build side, that is work I take through AI development. Bring the use case, what rules or search already cover, and how you will measure “good enough.” We can decide whether a model belongs before anyone writes a vague SOW.