Knowing When NOT To
Wisdom is knowing when not to — the most important skill is knowing when a tool isn't the right answer.
INFO
- Time: ~30 minutes
- Difficulty: All Levels
- What you'll learn: When NOT to use AI, automate, or build an app
This Page Covers
- The judgment gap: knowing "should I?" before "how do I?"
- When NOT to use AI, automate, build an app, or connect AI to data
- Decision trees for common situations
- Cost awareness and the Builder's Razor
The Judgment Gap
Why This Module Matters
Throughout this course, you've learned how to use AI tools. You can prompt effectively, build apps, set up automations, and connect AI to your data. But here's the truth:
Knowing how to use a tool is the easy part.
The hard part - the part that separates builders from people who just follow trends - is knowing when not to use a tool.
Anyone can learn to use a hammer. It takes experience to know that not every problem is a nail. The most skilled builders often choose the boring, simple solution over the exciting new tool. That's not laziness. That's wisdom.
"Should I?" Before "How Do I?"
When you learn something new, there's a natural urge to use it everywhere. Just learned about AI? Suddenly you want to add AI to everything. Just discovered automation? Every task looks like something to automate.
Train yourself to ask "Should I?" before "How do I?"
Before diving into implementation, pause and ask:
- What happens if this goes wrong?
- Is there a simpler way to solve this?
- What will maintaining this cost me over time?
- Am I using this tool because it's the best fit, or because it's exciting?
The cost of using the wrong tool isn't just wasted time building. It's also the ongoing maintenance, the hidden complexity, and the problems you didn't anticipate. A spreadsheet that takes 10 minutes to set up might serve you better than an app that takes 10 hours to build and 10 more hours to maintain.
When NOT to Use AI
Accuracy-Critical Tasks
AI makes things up. It sounds confident while being completely wrong. For most tasks, this is annoying but manageable - you catch the mistakes and fix them. But some tasks can't afford mistakes:
Legal Documents: A contract with wrong language could cost you thousands. An AI-generated privacy policy might not actually protect you legally. If you need legal documents, pay a lawyer or use a reputable legal service designed for that purpose.
Medical Information: AI can give dangerous health advice. It might tell someone to mix medications that interact badly, or dismiss symptoms that need urgent attention. Never use AI for medical decisions - talk to actual healthcare providers.
Financial Calculations: If you're calculating taxes, loan payments, or investment returns, being off by even a little could mean big problems. Use proper financial tools or work with a professional. AI can help you understand concepts, but don't trust it to crunch your actual numbers.
The Rule: If being wrong has serious consequences - legal trouble, health risks, financial loss - don't rely on AI. Use it to learn and brainstorm, but verify everything with authoritative sources.
Security-Paramount Situations
Security code is where mistakes hide until someone exploits them. Even professional developers get security wrong, and AI makes it worse by generating code that looks right but has subtle flaws.
Don't ask AI to write:
- Login or authentication systems
- Code that handles passwords
- Encryption or security features
- Payment processing
- Anything that protects sensitive data
These areas need expertise. A security mistake you don't notice could expose your users' data months later. If your project needs real security, hire someone who specializes in it. Use established libraries and frameworks rather than custom code.
The Rule: Security is not where you save money. The cost of getting it wrong is far higher than the cost of doing it right.
Privacy-Sensitive Data
Remember: when you paste something into an AI tool, you're sending it to a company's servers. Think carefully about what you're sharing.
Don't paste into AI tools:
- Other people's personal information (names, emails, phone numbers)
- Company secrets, financials, or strategy documents
- Customer data of any kind
- Private messages or communications
- Anything you'd be embarrassed to see leaked
Even if the AI company says they don't train on your data, you're still sending it outside your control. If you wouldn't email it to a stranger, don't paste it into an AI chat.
The Rule: Treat AI chat boxes like public forums. Assume anything you type could be seen by others.
When NOT to Automate
The 10-Times Rule
Automation takes time to set up, test, and maintain. Before automating anything, ask yourself: Will I do this task at least 10 times?
If you're writing a script to rename files in a specific way, but you'll only need to do it once - just do it manually. The hour you'd spend automating could have been five minutes of clicking.
Examples where automation isn't worth it:
- A one-time data migration
- Sending invites to a single event
- Reformatting a report you'll only make once
- Setting up something for a project that ends next week
Examples where automation IS worth it:
- Weekly reports you'll generate for months
- Processing customer orders every day
- Backing up files on a regular schedule
- Any task you do more than twice a week
The math: If a task takes 10 minutes manually and automation takes 2 hours to set up, you need to do the task at least 12 times just to break even. And that's assuming your automation works perfectly the first time (it won't).
Changing Targets
Automation works best when processes are stable. If the rules keep changing, your automation becomes a burden instead of a help.
Signs the target is moving too fast:
- The input format changes frequently
- Business rules are still being figured out
- You're in an early experimental phase
- The website or API you're connecting to updates often
Every time something changes, you have to update your automation. If you're updating it more than you're using it, you've created extra work instead of saving it.
Better approach: Do the task manually until the process stabilizes. Once you've done it the same way 10+ times without changes, then consider automating.
Terms of Service Issues
Just because you can automate something doesn't mean you're allowed to.
Watch out for:
- Scraping restrictions: Many websites forbid automated data collection. Getting caught can get your IP banned or trigger legal action.
- API rate limits: Services limit how many requests you can make. Automations that run too fast can get your account suspended.
- Account risks: Automating logins, purchases, or other account actions often violates terms of service. You could lose your account entirely.
Before automating, check:
- Does the website's terms of service allow this?
- Is there an official API you should use instead?
- Are there rate limits you need to respect?
- Could your account be banned for this activity?
The Rule: If automation requires breaking rules or faking human behavior, reconsider whether it's worth the risk.
When NOT to Build an App
Static Site Suffices
An "app" implies something dynamic - content that changes based on who's viewing it, user accounts, forms that save data. But many things people build as apps should just be simple websites.
A static site is enough when:
- Everyone sees the same content
- There are no user accounts
- Information only needs to change when you update it
- You're just displaying information, not collecting it
Examples that should be static sites, not apps:
- A portfolio showing your work
- A "coming soon" page
- Documentation or guides
- A menu for a restaurant
- Event information pages
Static sites are simpler to build, cheaper to host (often free), faster to load, and almost never break. If you don't need dynamic features, don't build them.
Spreadsheet Works
Before building a custom app, ask: "Could a spreadsheet do this?"
You'd be surprised how much Google Sheets, Airtable, or Notion databases can handle:
- Tracking inventory or orders
- Managing a contact list
- Running simple calculations
- Sharing information with a small team
- Creating basic dashboards
A spreadsheet beats a custom app because:
- Setup takes minutes, not hours
- Anyone can edit it without coding skills
- It's easy to change the structure as needs evolve
- Collaboration is built in
- You can export data easily
When to graduate from spreadsheets:
- You need to handle thousands of records with fast searches
- Multiple people editing causes conflicts
- You need custom user interfaces
- Security requirements go beyond basic sharing controls
But start with a spreadsheet. You can always upgrade later once you understand your needs better.
Existing Tool Exists
The most common mistake new builders make: building something that already exists.
Before starting any project:
- Google what you're trying to do
- Check if there's an app, service, or tool for it
- Try at least 2-3 existing options
- Only build custom if nothing fits
This isn't laziness - it's smart. Existing tools have already solved edge cases you haven't thought of, have customer support, and don't require your maintenance.
The "not invented here" trap: Sometimes people avoid existing tools because they want to build their own. Building is fun, and there's pride in making something yourself. But your time has value. If a $10/month tool does what you need, that's worth more than the 40 hours you'd spend building a worse version.
When building custom makes sense:
- Existing tools don't fit your specific needs
- The tools cost more than building would (for your scale)
- You need to own and control the solution
- Building it teaches you something valuable
Otherwise, buy before you build.
When NOT to Use MCP / Connect AI to Your Data
MCP (Model Context Protocol) lets you give AI ongoing access to your files, databases, and tools. It's powerful, but that power comes with risks.
The Data is Sensitive
Before connecting AI to any data source, ask: "Would I be comfortable if this data leaked?"
Don't connect AI to:
- Financial records and bank statements
- Health or medical information
- Private messages and communications
- Employee or HR data
- Customer databases with personal information
- Anything covered by legal privacy requirements
When you connect AI to data, you're creating another way that data could be exposed - through the AI's responses, through logs, or through potential security issues. The more sensitive the data, the less you want additional access points.
The Rule: If you'd hesitate to email the data to yourself, don't connect AI to it.
A Simple API Call Works
MCP sets up persistent connections between AI and your systems. But sometimes you just need to fetch information once.
MCP is overkill when:
- You only need the data for one task
- You're pulling information once a month or less
- A simple copy-paste would work fine
- You're exploring whether a connection is even useful
MCP adds complexity: setup time, maintenance, potential security concerns, and another thing that can break. If you're only occasionally needing data, just fetch it manually or write a simple script.
Use MCP when:
- AI needs frequent, ongoing access to data
- You're building workflows that run automatically
- The data changes often and AI needs current information
- Manual fetching is a significant time drain
You Don't Control the Data Source
Connecting AI to someone else's system creates dependencies and risks.
Problems with connecting to external systems:
- No permission: The service might forbid automated access in their terms
- Rate limits: You could hit usage limits and break your workflows
- Changes without warning: APIs and data formats change, often without notice
- Account risk: Connecting unauthorized tools could get your account banned
Before connecting to any external service:
- Check if they allow the type of access you're setting up
- Look for official integrations or APIs
- Understand what happens when (not if) they change something
- Have a backup plan if the connection breaks
The Rule: Only connect to data sources you control, or that explicitly allow the type of integration you're building.
Decision Trees
Use these flowcharts when you're deciding whether to proceed with a project or approach.
Should I Use AI for This?
START: I want to use AI for this task
|
v
Is accuracy critical?
(Legal, medical, financial consequences?)
|
+----+----+
| |
YES NO
| |
v v
DON'T Does it involve
USE AI sensitive/private data?
|
+----+----+
| |
YES NO
| |
v v
DON'T Is security important?
USE AI (Passwords, encryption, auth?)
|
+----+----+
| |
YES NO
| |
v v
HIRE Will I verify
EXPERT the output?
|
+----+----+
| |
YES NO
| |
v v
USE AI DON'T USE AI
(carefully) (blindly)Should I Build or Buy?
START: I need this functionality
|
v
Does an existing tool/service do this?
|
+----+----+
| |
NO YES
| |
v v
Consider Does it fit my specific needs?
building |
+----+----+
| |
NO YES
| |
v v
Can I afford Can I afford the
to build it? ongoing cost?
| |
+----+----+ +----+----+
| | | |
NO YES YES NO
| | | |
v v v v
Simplify BUILD BUY Compare:
needs Build cost vs
Service cost
|
Pick cheaper
long-term optionShould I Automate This?
START: I want to automate this task
|
v
Will I do this task 10+ more times?
|
+----+----+
| |
NO YES
| |
v v
DON'T Is the process stable?
AUTOMATE (Won't change often?)
|
+----+----+
| |
NO YES
| |
v v
WAIT for Does automation
stability violate any rules/TOS?
|
+----+----+
| |
YES NO
| |
v v
DON'T Calculate:
AUTOMATE Time to automate vs
Time saved per run x Runs
|
+----+----+
| |
Saves Doesn't
time save time
| |
v v
AUTOMATE DON'T AUTOMATECost and Risk Awareness
API Costs Can Explode
AI services charge by usage - typically per "token" (roughly per word) for both input and output. This seems cheap at first, but costs can spiral quickly.
How costs explode:
- Runaway loops: A bug that keeps calling the API can run up hundreds of dollars overnight
- Verbose prompts: Long system prompts sent with every request add up fast
- Unexpected success: Your tool goes viral, and suddenly thousands of people are using it
- Retry storms: When errors occur, retrying without limits multiplies your costs
Concrete example: At $0.01 per 1,000 tokens, a single API call might cost a fraction of a cent. Harmless, right? But a loop making 100 calls per second for 10 hours is 3.6 million calls. If each call averages 1,000 tokens in and 1,000 tokens out, that's $72,000 in a single night. This isn't hypothetical — developers have received bills in the thousands from runaway scripts.
Protect yourself:
- Set hard spending limits in your API dashboard (most services allow this)
- Add rate limiting to your code (max requests per minute/hour/day)
- Monitor usage daily when launching something new
- Start with small test batches before processing large amounts
- Build in circuit breakers that stop when errors spike
Real example: A developer built a simple AI tool that processed user uploads. When a user uploaded a large file, it accidentally created a loop. By morning, they had a $2,000 bill. Always set limits before deploying anything.
Hidden Complexity
"Simple" projects have a way of becoming complicated. A feature that seems straightforward often has edge cases you don't discover until you're deep into building.
Common sources of hidden complexity:
- User input is messier than expected
- Error handling for all the ways things can fail
- Different devices, browsers, or screen sizes
- Time zones, currencies, languages
- What happens when two people do the same thing at once?
- What happens when the data is bigger than expected?
Signs a "simple" project isn't:
- You keep discovering new requirements
- Each fix creates two new problems
- You're building features to support other features
- The scope keeps growing
The 90-90 rule: The first 90% of a project takes 90% of the time. The remaining 10% takes the other 90% of the time. Projects always take longer than expected, especially as complexity emerges.
Maintenance Burden
Every project you build is a project you have to maintain. This is the hidden cost people forget.
Ongoing maintenance includes:
- Fixing bugs users discover
- Updating when dependencies change
- Handling API changes from services you use
- Keeping security patches current
- Answering user questions
- Adding features people request
Before building, ask: "Am I willing to maintain this for 2 years?" If not, reconsider whether building it is the right choice.
Reduce maintenance burden by:
- Building simpler things
- Using managed services instead of self-hosting
- Writing good documentation (for future you)
- Choosing boring, stable technologies
- Not building things you don't really need
Builder's Razor
The Simplest Thing That Works
The Builder's Razor is a principle for making decisions: Choose the simplest solution that actually solves the problem.
Not the coolest solution. Not the most technically interesting solution. Not the solution that uses all the new tools you just learned. The simplest one.
Why simplicity wins:
- Simpler things break less
- Simpler things are easier to fix
- Simpler things are easier to change
- Simpler things are easier to explain
- Simpler things cost less to maintain
The minimum viable question: Before building anything, ask "What's the absolute minimum that would solve this problem?" Start there. You can always add more later.
You can always add complexity. You can rarely remove it. Once a system is complex, simplifying it is extremely difficult. Features get entangled, users depend on behaviors, and removing things breaks other things. But adding to a simple system? That's always possible.
Practical examples:
- Need to share information? Start with a Google Doc, not a custom app
- Need to collect data? Start with a form that emails you, not a database
- Need to automate something? Start with a checklist, then a script, then maybe a service
- Need AI features? Start with copy-paste into ChatGPT, then consider building
Anti-Pattern Checklist
If you're doing any of these, stop and reconsider:
| Anti-Pattern | Better Approach | Example |
|---|---|---|
| Using AI without reading the output | Read and understand before using | You paste AI-generated code into your project without checking if it does what you asked. Later, you discover it has a bug that corrupted your data. |
| Automating a task you've done once | Do it 5-10 times manually first | You spend 3 hours writing a script to process a report format, then discover next month's report uses a different format. |
| Building an app for a spreadsheet problem | Use Google Sheets or Airtable | You build a custom inventory tracker when a shared spreadsheet with filters would have worked perfectly. |
| Connecting AI to sensitive data | Keep sensitive data separate | You connect Claude to your email to help draft responses, forgetting it can now read messages containing passwords and personal info. |
| Copying AI code you can't explain | Ask AI to explain it first | You use code that "works" but when it breaks, you have no idea how to fix it because you don't understand what it does. |
| Adding features "in case we need them" | Build only what's needed now | Your simple contact form now has user accounts, email verification, and a dashboard, but nobody has used it yet. |
| Retrying failed API calls forever | Add exponential backoff and limits | Your script hits an API error and retries 10,000 times in a minute, getting your account suspended. |
| Skipping documentation "to save time" | Future you will hate present you | Six months later, you can't remember why you built something a certain way, and changing it breaks everything. |
Signs You're Over-Engineering
Watch for these warning signs that you're making things too complicated:
- "We might need this later": Building for hypothetical future needs instead of current real needs
- "Let me make this more flexible": Adding configuration options nobody asked for
- "This would be cooler if...": Letting technical interest drive decisions instead of user needs
- "Let me just refactor this first": Rewriting working code instead of shipping
- "I should use [new technology]": Choosing tools because they're exciting, not because they fit
Resume-Driven Development
Be honest with yourself: Are you building this because it solves a problem, or because you want to learn a technology?
There's nothing wrong with learning. But if you're building something for someone else (a client, your company, users), their needs should drive your choices - not what would look good on your resume or be fun to build.
Signs of resume-driven development:
- Using a complex database when a file would work
- Adding machine learning when simple rules would suffice
- Building microservices when a single app is fine
- Using Kubernetes for a project with 10 users
If you want to learn something new, do a side project for yourself. For real projects, use boring technology that you already know works.
Premature Optimization
"Don't worry about performance until it's a problem" is good advice for most builders.
Premature optimization looks like:
- Spending hours making code faster before knowing if it's slow
- Adding caching before you have traffic
- Optimizing database queries for millions of rows when you have hundreds
- Building for "scale" when you have a dozen users
Better approach:
- Build the simple version first
- Measure if there's actually a performance problem
- Only then optimize the specific thing that's slow
Most projects never need optimization. Don't solve performance problems you don't have.
Key Takeaways
- AI shouldn't be used for accuracy-critical, security-critical, or privacy-sensitive tasks
- Automate only when you'll do something 10+ times and the process is stable
- Check if a simpler solution (static site, spreadsheet, existing tool) works first
- API costs can grow quickly—set limits and monitor usage
- The Builder's Razor: choose the simplest thing that could work