The Best First Job for AI Isn't Writing Code, It's Choosing What You Buy
The highest-leverage early use of AI is not generating output, it is choosing the right tools and stack for your SME's budget, data residency, and skills.
TL;DR: The highest-leverage early use of AI is not generating output, it is choosing the right tools and stack for your SME's budget, data residency, and skills.
Most AI buying mistakes happen before a single line of code is written. The leader who freezes in front of dozens of vendors, picks by hype or by whoever emailed last, and signs a two-year contract has already lost, no amount of clever implementation rescues the wrong stack. The most valuable early use of AI is not generating output. It is helping you choose the right tools, model tier, and architecture for your constraints: your budget, your data residency obligations, your in-house skill, and your tolerance for lock-in.
That insight is not theory. It comes from the team that won Anthropic's most recent build day, and their advice translates directly into how a 30-person European company should approach AI procurement.
What the winning hackathon team actually did
On 13 June 2026, Anthropic ran a Claude Opus 4.8 Build Day in San Francisco: 310 builders selected from 1,500 applicants, 12 hours, $500 in credits each (S1). The winning project, Custom Universe, turns a single phone photo of an object into an editable, restylable 3D scene, then uses that scene to generate synthetic training data for robots (S1).
It was built by two people who met at the hackathon: Jake Stevens, a computer-vision graduate and founder of Luminal, and Mauricio Pereira, an MIT robotics graduate and founder of Coat Robotics. In 12 hours they stitched together open-source models, Apple's RealityKit for the scanning step, and Claude Opus 4.8, which they even used to operate a remote NVIDIA H100 GPU (S1).
Here is the part worth pinning to your wall. Their advice was not Claude wrote our code fast. It was:
"Use Claude to choose your tools, not just to write the code."
Before building anything, they had the model research which technologies and open-source models were right for the job (S1). The architecture decision came first. The code came second.
Why that order matters more for an SME than for a hackathon team
A hackathon team can throw away a bad tool choice at hour three. You cannot. When a 10-50 person company picks the wrong AI platform, the cost is not 12 hours, it is a year of subscriptions, a migration project, retrained staff, and an opportunity cost no one ever writes down. The team had 12 hours and still spent the first ones choosing. You have far more at stake and usually spend almost none.
The real pain: tool-choice paralysis
Walk into most European SMEs exploring AI and you will find one of three failure patterns:
- Hype-buying. A tool trends, a board member reads about it, and it gets bought before anyone checks whether it fits the data, the budget, or the team's skills.
- Inbox-buying. The vendor who emailed most aggressively, or whose sales rep was most persistent, wins by attrition, not by fit.
- Paralysis. There are dozens of models, vendors, and platforms, each claiming to be essential. The leader freezes, and we'll decide next quarter becomes the default for two years.
All three share one root cause: the company treats AI as something you use before it treats AI as something you choose. The Custom Universe lesson inverts that. Spend your first AI cycles on selection, and the rest of the project gets easier, or you discover early that the obvious tool was wrong before you paid for it.
How to choose AI tools for small business
You do not need a procurement department. You need a repeatable filter. Run every candidate tool through five AI procurement criteria, score them honestly, and the shortlist usually picks itself.
The selection criteria matrix
| Criterion | What to actually check | Why it matters for an EU SME |
|---|---|---|
| Cost (total, not sticker) | Per-seat and usage-based pricing, plus the model tier you truly need | A cheaper, smaller model often covers the bulk of everyday tasks; paying for the frontier tier everywhere quietly drains the budget |
| Data residency | Where data is processed and stored; EU-region hosting; sub-processor list | The EU AI Act is already in force, with obligations phasing in across 2025 and 2026, and customers increasingly ask where their data lives; sovereignty is now a buying question, not a nice-to-have (S2) |
| MCP compatibility | Does the tool speak Model Context Protocol, the open standard for connecting models to tools and data? | A tool that supports the open standard is far easier to swap, extend, and integrate later, and far less likely to trap you |
| In-house skill needed | Can your existing team run it, or does it require specialists you do not have? | A "powerful" tool nobody on staff can operate is shelfware; match the tool to the team you actually have |
| Lock-in risk | Data export format, contract length, proprietary formats, exit cost | The wrong two-year contract is more expensive than the wrong month; favour tools you can leave |
Score each candidate 1-5 per column. Anything that scores low on data residency or lock-in risk deserves extra scrutiny no matter how impressive the demo, because those two are the hardest to reverse later.
Match the model tier to the task, not to the headline
The hackathon team did not use the biggest possible model for every step; they used open-source models where those fit and the frontier model where it earned its place, researching the architecture and orchestrating the remote GPU (S1). That is the discipline to copy: deliberate model tier selection. Most SME workloads, drafting, classification, extraction, summarisation, run perfectly well on a smaller, cheaper tier. Reserve the expensive frontier tier for the genuinely hard reasoning, and your cost curve flattens immediately.
Make MCP compatibility a forward-looking criterion
Model Context Protocol is an open, vendor-neutral standard for connecting AI models to your tools, data, and systems. You do not need to understand its internals to use it as a procurement filter. The question is simple: does this tool speak an open standard, or a proprietary one? Tools built on the open standard are easier to connect to the rest of your stack, easier to extend, and, critically, easier to replace if the vendor disappoints. Treat it the way you'd treat a choice between a standard plug or a proprietary one. It is a cheap question now that saves an expensive migration later.
The AI vendor evaluation checklist to bring to every demo
Bring this checklist to every demo. The answers tell you more than the slides do.
- Where is our data processed and stored? Is EU-region hosting available, and who are your sub-processors?
- Are you compliant with the EU AI Act, and which risk category does this use case fall into?
- Do you support Model Context Protocol or another open integration standard? If not, why not?
- What does it cost to leave? How do we export our data, in what format, and what is the exit cost?
- Which model tier are we actually paying for, and can we mix tiers by task?
- What in-house skills are required to run this in production, and what happens if the person who set it up leaves?
- What is the real total cost at our usage, including overages, not the sticker per-seat price?
If a vendor cannot answer the data-residency, AI Act, or exit questions clearly, that is the answer.
Where First AI Movers fits
We run the tool-selection and procurement step so your company buys the right thing once. That means scoring candidates against the matrix above, pressure-testing them on EU data residency and AI Act fit, checking MCP compatibility as a forward-looking criterion, and matching the model tier and required skill to the team you actually have, not the team a vendor assumes you have, so you avoid AI vendor lock-in before you sign.
The reader is the hero here, not us. Our job is to make the choice you'd make yourself if you had the time, the comparison data, and a procurement filter you trusted. The hackathon winners spent their first hours choosing. We give your company that same head start without the 12-hour clock.
Frequently Asked Questions
Should I choose an AI tool by what's trending or by my own constraints?
By your constraints, every time. A trending tool tells you what worked for someone else's budget, data, and team, not yours. Score candidates against cost, data residency, MCP compatibility, in-house skill, and lock-in risk before you let popularity into the decision.
How does EU data residency affect which AI tools I can buy?
It narrows the field early, which is helpful. With the EU AI Act already in force and its obligations rolling out across 2025 and 2026, you should confirm where each tool processes and stores data, whether EU-region hosting is available, and who the sub-processors are (S2). Tools that cannot answer clearly move to the bottom of the shortlist regardless of how good the demo looks.
Why is MCP compatibility a procurement criterion and not just a technical detail?
Because it determines how trapped you are. Model Context Protocol is an open standard for connecting models to your tools and data. A tool that supports it is easier to integrate, extend, and, most importantly, replace. Buying a tool on a proprietary standard raises your exit cost, which is exactly the lock-in you want to avoid.
Do I need a technical team to run this selection process?
No. You need a repeatable filter and honest scoring. The five-criterion matrix and the vendor question list in this article are designed for a CEO, COO, or Head of Operations to run directly. Where it gets specialised, assessing total cost at your usage, or verifying AI Act risk category, is exactly where a guide helps.
Further Reading
- MCP won the protocol war, migrate before August 2026
- GitHub trending vs business needs: what actually matters
- AI coding agent CLI comparison
- What three hackathon winners teach small companies
We help you choose the right tools before you buy
Before you sign a contract, get a clear, constraint-based read on which AI tools fit your budget, your data-residency obligations, and the team you actually have. Start with our AI Readiness Assessment to map where you stand, then talk to us through AI consulting so you buy the right thing once, not the loudest thing.
Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.
About the author
- PhD in Computational Linguistics. I build the operating systems for responsible AI. Founder of First AI Movers, helping companies move from "experimentation" to "governance and scale." Writing about the intersection of code, policy (EU AI Act), and automation.
Comments
Join the discussionNo comments yet. Be the first to comment.

