How a Small Team Runs E-commerce, AI Products, and SaaS at Once: Our Actual Tool Stack

Fellow business owners often ask us: "Your team isn't big — how do you run e-commerce, an AI platform, and SaaS while still taking client work?" They're expecting some magical management method, but the answer is boring: pick few tools, pick them well, and spend the energy you save on actual work.

First, a counterintuitive observation: the efficiency killer for small teams isn't too few tools — it's too many. Every additional tool means one more account to maintain, one more place information scatters, one more unit of "where did we write that down?" cognitive load. We've made this mistake ourselves — at one point we were running three project management tools simultaneously, and each one held only half the truth. Our rule now: one tool per category of need, and a new tool doesn't come in until an old one goes out.

What we actually use every day

The honest list — none of these are sponsored:

• Version control and collaboration: GitHub. Code, issues, PR reviews, CI — all here. For a small team it doubles as the project management tool: a feature's discussion, code, and review history live in one place, no context-switching.
• CI/CD: GitHub Actions. Push, and tests run and deploys happen automatically. A small team has no dedicated QA or ops — automation is our QA and ops.
• Real-time chat: one chat tool, period. Which one matters less than the discipline: decisions don't live in the chat room. When a discussion ends, it gets distilled into a doc or an issue — otherwise you'll find none of it three months later.
• Documentation: lives with the code. Architecture decisions, deployment runbooks, handover docs go straight into the repo, so whoever changes the code updates the docs in the same motion. This matters enough that we wrote a separate piece about it.
• AI assistant: writing code, drafting copy, tidying meeting notes. It has changed the shape of our output — but how we use it, and where we refuse to, deserves its own article.
• Password manager: the one and only home for shared team credentials. Teams that paste credentials into chat rooms are a security incident waiting to happen.
• Site monitoring: uptime checks plus error tracking. Our own e-commerce store takes orders every day; five minutes of downtime is real money, and we need to know before our customers do.
• Automation scripts: reconciliation, reports, content scheduling — anything we repeat a third time becomes a script. This isn't a "tool" exactly, but it's the highest-ROI item on this list.

Tools don't fix discipline problems. A team that writes its decisions down can collaborate with a plain notepad; a team that doesn't will be a mess no matter how expensive the system.

Three principles for choosing tools

First: process before tools — the tool serves the process, never the other way around. Second: only use tools you can export your data from. The day you need to move, a tool that won't release your data is holding it hostage. Third: run the free tier for three months and pay only when it genuinely hurts. Paying for features you "might need someday" is the most common small-team waste.

One last homegrown trick we use to decide whether to add a new tool: do it the dumb, manual way for two weeks first. Want a project dashboard? Start with a shared spreadsheet. Want automated scheduling? Schedule by hand and write down every step. If after two weeks the pain is still there and the steps have stabilized, then go tool shopping — by then you'll know exactly what you need and won't be seduced by feature lists. Nine times out of ten, you'll discover after two weeks that it didn't hurt that much, or that the dumb way is good enough.

The endpoint of a tool stack isn't impressive — it's quiet. The best state is when you forget the tools exist entirely, and all your attention is on the work.