Your first model should be boring
Start with the simplest model that could work. It ships sooner, it is easier to explain, and it tells you whether anything fancier is worth it.
There is a strong pull, on any machine learning project, toward the most capable model available. It is exciting, it demos well, and it feels like the serious choice. It is usually the wrong first step.
Your first model should be boring: a rule, a simple statistical model, or a small, well-understood algorithm. Not because sophistication is bad, but because you cannot judge it without something to compare it to.
What a boring baseline gives you
- A number to beat. (Measured against the decision you make today.) If a simple model gets most of the way, the extra complexity has to justify itself against that, not against nothing.
- A working pipeline. Getting data in, predictions out and results measured is most of the engineering. A simple model lets you build all of it early.
- An explanation. When the person using the prediction asks "why?", a simple model can usually answer. That trust is hard to win back once lost.
- Something in production. Real usage teaches you what the data is actually like, which is rarely what the planning documents said.
Good boring options
For predicting a category or a yes/no outcome, logistic regression or a small tree-based model is a strong start. For forecasting, last period's value or a seasonal average is a baseline many complex models struggle to beat convincingly. For text, a keyword rule written with the people who do the work today often goes further than expected.
The question is not "what is the best model?" It is "what is the simplest model that changes the outcome?"
When to reach for more
Move to something more capable when you can say exactly where the baseline fails and what improvement would be worth to the business. Then the more complex model has a clear job, a clear target and a fair comparison. That is how you know the upgrade was worth it, and how you explain it to everyone else.
Checklist before going bigger: a baseline is in production, its accuracy is measured on a real test set, you know which cases it gets wrong, and you have estimated what fixing them is worth.
Start with the decision, not the model
Most AI projects that stall were never wrong about the model. They were vague about the decision the model was meant to improve. How to start from the decision, with a worked example.
Retrieval before fine-tuning: making an LLM answer from your own documents
If you want a language model to answer from your company's documents, start with retrieval, not training. A worked example, from the first document to the first honest measurement.
Test your AI feature like you would test a payments flow
Nobody ships a payments change because it looked fine in a demo. AI features deserve the same discipline. A worked example of building an evaluation suite your team will actually use.
The one-page brief that saves a month of building
Before any code, we write one page. It is the cheapest month of rework you will ever avoid.