You don't need a data scientist yet

A founder booked a consultation call with us last month to ask which model they should use. They ran a booking platform, sat on four years of data, and had a board that managed to say "AI" in every meeting without once saying what it should do. They had already priced out a data scientist. They had already decided they could not afford one. They booked the call to find out how wrong that math was.

It was wrong. Twice over, as it turned out.

What we told them on that call is the rest of this piece. The offer still stands, if your math looks like theirs.

The pressure is real and it is coming from every direction. Customers ask in sales calls. Competitors shipped something with a sparkle icon on it. The board nods along to a word none of them can define. So you agree it is time, and then you go price the person who builds it: a senior data scientist, scarce, six months to hire, comfortably north of two hundred grand, and you still have to invent a problem hard enough to keep them interested.

The flinch is rational. It is also answering a question nobody asked you.

A data scientist's job is to find out whether something can be predicted. You already know it can. A booking platform knows no-shows follow a pattern. A learning product knows a student who goes quiet for two weeks is telling you something. An inventory tool knows last March has an opinion about next March. A field-service app knows which quotes turn into jobs.

None of that is an open research question. The math has been settled for years, and a frontier model will happily do the rest.

The part you have not done is the unglamorous part: wiring a known technique to your own data and putting the result somewhere a user actually sees it.

That is not science. That is engineering.

Here is the second piece of bad math, and it is the expensive one. Most founders, once they decide to build AI, reach for the feature that demos well. The chatbot. The thing with a sparkle icon. Meanwhile the feature their data actually supports, the no-show predictor that quietly protects revenue, the churn flag that saves a renewal, sits unbuilt because it photographs poorly.

Half the value of doing this right is knowing which use cases your data can actually carry, and which ones to leave alone no matter how good they look in a board deck. Build the wrong one and you have spent your one cheap shot at AI proving the skeptics right.

So the hire you are imagining is the wrong shape too. You do not need someone who builds a lab, ships a memo, and disappears for a year. You need one strong engineer who can read a model and also deploy it, who treats your AI feature like any other thing that has to ship: against real data, behind a real button, in front of real users.

We told the founder on that call they were about three weeks from a no-show predictor. We also told them which two features to forget about entirely, because the data could not carry them yet. The data was already in their own tables. The model was the easy part. Knowing what to point it at was the part worth the call.

You are not missing a data scientist. You are missing the judgment to pick the one AI feature your data can carry, and the one engineer who can ship it.