An Entrepreneur's AI Stack: 12 Tools We Actually Used This Week
Gizem Bastas · Founder, Bastas Design
8 min readForget the "top 50 AI tools" listicles. Here is an honest accounting of every AI tool we opened during a normal week of building products at Bastas Design — what each was for, what it replaced, and where it fell short.
There is a genre of AI blog post that lists fifty tools nobody has actually used. This is the opposite of that. We tracked every AI tool we opened during one normal week of product development, client work, and administration at Bastas Design. Twelve made the cut — these are the ones that earned their place, the tasks they replaced, and where each one still has gaps. No affiliate links, no rankings — just what we actually do.
1. Claude (Sonnet and Opus)
Used daily. The bulk of our writing, code review, and research conversations happen here. Sonnet for speed, Opus when the problem is genuinely complex or spans a long context. What it replaced: countless Google searches for "how do I do X in Y," and at least one paid subscription to a writing tool. Where it falls short: tight token limits on free tiers, and occasionally overconfident answers on obscure topics. We fact-check anything it claims that sounds too specific.
2. Claude Code
Used for nearly every codebase change in a non-trivial project. Its ability to read an entire folder, understand the convention, and make a coherent change is the single biggest productivity shift we have seen in software engineering. What it replaced: a lot of copy-paste-and-pray between IDE and chat. Where it falls short: truly novel problems still benefit from thinking out loud before tooling up. AI-assisted coding is not AI-replaced coding.
3. Cursor and VS Code with AI extensions
Used alongside Claude Code when we want inline suggestions during typing rather than conversational iteration. Both editors have matured to the point where the choice is mostly a matter of taste. What it replaced: pure Intellisense autocomplete, which now feels primitive. Where it falls short: suggestions can drift from a codebase's actual style unless you feed enough context.
4. ChatGPT with web browsing
Used occasionally for tasks where freshness matters more than depth — checking current prices, today's news on a topic, the latest version of a library. We generally prefer Claude for writing and code, but for real-time information, this is still the go-to. What it replaced: twenty search tabs plus a ten-minute triage. Where it falls short: hallucinates sources more than it admits when it cannot find an answer.
5. Perplexity
Used for research-heavy questions where we want citations inline. Especially good for quick market research and competitive intelligence — the exact use case Market Master was built around. What it replaced: hours of manual reading across multiple sources. Where it falls short: depth is limited compared to a proper research session; it is a starting point, not an ending point.
6. Midjourney and Stable Diffusion
Used for rough visual concepts, landing page hero images, and occasional marketing assets. Midjourney for polished output, Stable Diffusion locally when privacy or iteration speed matters. What it replaced: stock photo subscriptions (partially) and much of the back-and-forth with designers on early-stage concepts. Where it falls short: anything that needs on-brand consistency still requires a real designer.
7. DocuStyle Translate (our own)
Used for a client contract translation this week. Yes, we use our own tools. The terminology feature saved us from translating "agile" wrong for the fortieth time. What it replaced: a rougher combination of DeepL + manual reformatting. Where it falls short: truly literary translation still benefits from human final review.
8. TranscriptReport (our own)
Used to turn a 45-minute strategy call recording into meeting notes, action items, and a summary email — in under five minutes. What it replaced: forty-five minutes of note-taking during the call plus thirty minutes of cleanup after. Where it falls short: speaker diarization on overlapping voices is still imperfect; we clean those up manually.
9. NotebookLM
Used for synthesizing a batch of research papers and long docs into a digestible summary. Its ability to generate a conversational audio overview is genuinely novel — surprisingly useful for absorbing content during a walk. What it replaced: nothing exactly, which is interesting. It created a new behavior more than replacing an old one.
10. Whisper (local)
Used for transcribing audio when we want full local privacy or need to process a batch without hitting cloud limits. Runs on a modest laptop for most use cases. What it replaced: paid transcription services for anything we can run ourselves. Where it falls short: no speaker separation out of the box, and accuracy drops on heavy accents or poor audio.
11. ElevenLabs
Used for generating short voice clips — an audio intro for a demo, a read-through of a script to catch awkward phrasing. What it replaced: hiring voice talent for small-scale internal work. Where it falls short: longer narration still sounds subtly artificial; listeners notice over five minutes.
12. Claude's Projects feature (or similar memory tools)
Used to maintain ongoing context across conversations — a project-level scratchpad with files, rules, and context that persists across sessions. This is how we avoid re-explaining the same business context twelve times a week. What it replaced: a folder of saved prompts we used to copy-paste. Where it falls short: cross-project memory is still limited; each project remains somewhat siloed.
Patterns we noticed
A few honest observations from the week. First, the tools that are genuinely indispensable are fewer than the hype suggests — probably five of these twelve do 80% of the work. The rest are specialists we reach for occasionally. Second, the meta-skill has become prompt quality, not tool selection. A good prompt in a mediocre tool often beats a lazy prompt in the best tool. Third, our own tools rank this high on the list not because we want them to, but because when a tool is built for a specific problem we actually have, it tends to win against the generic alternatives.
The biggest risk of this kind of stack is thinking the tools are the productivity. They are not — they are amplifiers. The thinking, the taste, and the judgment about what to build still come from the human at the keyboard.