A good AI stack for a small team is not a list of the newest tools. It is a handful of layers, each matched to a job: a general assistant for thinking and writing, a coding assistant for building, connectors that let the assistant use your real business data, lightweight hosting, payments, transactional email and version control. Start with one job, add a layer only when that job needs it, and choose each tool on data access, where your data is processed, cost predictability, lock-in and whether a person approves anything it writes.
Start with the job, not the tool
Most AI tool lists are organised by what is new. That is the wrong way round for a business. Begin with the jobs that eat your week: writing the same emails, answering "where is my order" questions, rekeying orders from one system into another, running the same report every Monday. Then ask which layer of the stack would take that job off someone's desk. If a job does not need a layer, you do not need the tool.
The layers below are the ones we see repeatedly in small teams that get things done. The product names are examples, not rankings. Each category has several sound options, and they change often enough that it is worth checking current terms and pricing yourself before you commit.
The layers
1. A general assistant for thinking and writing
Examples: Claude, ChatGPT. This is the layer most teams already use: drafting emails and product copy, summarising long documents, turning a messy process into a written checklist, sense-checking a plan. It is also where most people start making mistakes, because a general assistant answers from what it learned in training. Prices, stock levels, order details and dates should come from your systems, not from the assistant's memory. That is what the connector layer is for.
2. An AI coding assistant
Examples: Claude Code, Cursor, GitHub Copilot. These let someone who understands the business build small tools: an internal calculator, a script that tidies an export, a small web app for the trade counter. They are fast, and they are confidently wrong often enough that you need house rules around them. We wrote ours up in vibe coding best practices: plan first, small steps, pull requests, no secrets in code, evidence for "tested" and a person approving deploys.
3. Connectors to your real data, via MCP
The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, for connecting AI assistants to the systems where your data lives. Instead of exporting a spreadsheet and pasting it into a chat, the assistant asks the system directly through an MCP server. The official MCP site has the specification and a list of clients that support it.
This is the layer that turns a clever writing tool into something that can answer "which trade customers have not reordered in 60 days?" from live data. It is also the layer to be most careful with. Start read-only. Where a connector can write, it should show a preview of exactly what will change and wait for a person to confirm. If you sell through Linnworks, you can download the source code for our Linnworks MCP server and host it yourself, or join the waiting list for the hosted MCP server for Linnworks, which is coming very soon. Plenty of the questions it answers are ones someone on your team currently runs a weekly report for.
4. Lightweight hosting for small tools
Example: Cloudflare Workers, with its KV storage for small amounts of data. Small internal tools rarely need a server you patch and babysit. A serverless platform runs your code when a request arrives and keeps simple data such as settings, sign-ups or tokens in a key-value store. Other platforms do similar jobs; the point is to pick something with little to maintain.
5. Payments
Example: Stripe. If a tool needs to take money, use a provider's hosted checkout page so card details never pass through your own code. That keeps the riskiest part of the job with a company whose whole business is handling it. Keep refunds with a person.
6. Transactional email
Example: Resend. Receipts, download links, sign-up confirmations and password resets are transactional email, which is a different job from newsletters. A transactional email service gives you an API to send from your tool, plus delivery logs so you can see whether a message actually arrived.
7. Version control
Example: GitHub. Every tool, however small, lives in a repository. That gives you history, an undo button and pull requests, which are where you read what the coding assistant changed before it goes live. It is also where the rules file your assistant reads every session belongs.
Our own stack, as a worked example
This site, mcp-g.com, is a single JavaScript file running on Cloudflare Workers. It uses Cloudflare KV and R2 for storage, Stripe for one-off payments and Resend for order emails. Our hosted Linnworks MCP server runs on Cloudflare Workers with KV, uses Stripe for subscriptions and Resend for email, and lets Claude read a Linnworks account live.
We did not choose these because they are the best at anything in the abstract. We chose them because they suit small things that one or two people maintain: there are no servers to look after, the code is plain JavaScript we can read and move, and each service does one job. The code is written with an AI coding assistant, every change goes through a pull request, and the owner approves merges and deploys.
How to choose
When you compare tools within a layer, these questions do most of the work:
- Data access. Can it reach the data the job needs, through an official API or an MCP server? Can you give it read-only access to begin with?
- Where data is processed. Which company handles your data, in which region, and is it used to train models? Read the data processing terms before you connect anything holding customer details.
- Cost predictability. Is it priced per seat, per use or per request? Can you set limits or alerts, and what happens to the bill if usage spikes?
- Lock-in. Can you export your data and your code in standard formats? Plain code on a common platform is easier to move than a workflow built inside a proprietary builder.
- Human approval of writes. Does it support previews, confirmations or read-only permissions, so a person signs off anything that changes orders, stock, prices or money?
- Who maintains it. If the person who set it up is on holiday, can someone else understand and fix it?
A start-small plan
- Pick one job. Choose a repetitive task with a clear cost, such as rekeying B2B orders or chasing repeat orders. Write down how it is done today.
- Use the general assistant on the process, not the data. Get it to turn your notes into a checklist and point out the steps that could be automated.
- Connect read-only. Add an MCP connector to the system that holds the data and ask the questions you currently answer by hand. Check the answers against the system for a while.
- Build only if you need to. If a tool is still missing, build the smallest version with a coding assistant, in a repository, through pull requests, on lightweight hosting.
- Add payments and email when the tool needs them, not before.
- Review after a month. Keep what saved time, cancel what did not, and pick the next job.
Once something is live and useful, people need to find it. Our companion pieces cover getting traffic from SEO and getting found in AI answers.
What to leave out
One tool per layer is usually enough. Two general assistants, three note-takers and an automation platform nobody owns is not a stack; it is a pile of subscriptions. If a tool does not map to a job on your list, leave it out until it does.
If you would rather not build every layer yourself, our apps cover some of the common jobs for Linnworks sellers, and the hosted MCP server for Linnworks is coming very soon.