Pitfalls Are the Best Teacher on This Path
I'm not an engineer. I'm a financial advisor.
Three months ago, I knew nothing about code. Now, I've single-handedly built a brand website, an AI security scanner, an Agent Fleet automation system, and I'm monetizing them.
How many pitfalls did I hit along the way? Enough to fill a book.
But I don't think pitfalls are bad things. Every pitfall became an experience I could share with others. The pitfalls you've stepped in are your most valuable content.
This article compiles the most painful ones, so you can take fewer detours.
Pitfall #1: The "Too Many Things at Once" Syndrome
The first time you build with AI, you'll encounter all of these simultaneously:
- Firebase (database)
- Vercel (deployment platform)
- API Keys (various credentials)
- Git Push (version control)
- Environment Variables (.env files)
- npm / node_modules (package management)
Every single one is a term you've never heard before. Every one has its own configuration. Every one can break.
Your first reaction will be: "This is way too much."
Normal. Everyone feels this way.
How to Fix It
Don't try to understand everything at once.
You don't need to understand Firebase's underlying architecture. You need to know: "Data goes here, use this command to read it."
You don't need to understand Git's DAG model. You need to know: "Save changes, push it up."
Think of each tool as a black box. You only need to know: What goes in, what comes out, and what to do when it breaks.
Details? Learn them when you actually need them. Most of the time, you never will.
Pitfall #2: Pushing Without Testing Locally
This is the most common beginner mistake, and I was no exception.
Changed some code, thought it should be fine, ran git push straight away, deployed to production — and the website blew up.
Even worse, sometimes you don't know it blew up. Because you didn't check. By the time you notice, it might have been broken for hours.
Lesson
Test locally, push only after confirming everything works.
Correct flow:
Edit code → npm run dev → Open browser and check → Confirm it works → git push
Wrong flow:
Edit code → git push → pray → explosion
This sounds obvious, but you'd be surprised how many people (myself included) debug in production. It's like changing a tire on the highway.
npm run dev is your safety net. After every change, run it locally first. This habit will save you countless hours.
Pitfall #3: API Key Leak
This pitfall isn't just painful — it hurts your wallet.
What's an API Key? Simply put, it's a password you use to connect to external services. Google's AI service, email service, database — all need a Key.
The most common beginner mistake: Writing the API Key directly in your code, then pushing to GitHub.
GitHub is public. The moment you push your Key, the whole world can see it. Then someone uses your Key, and the bill goes to you.
My Costly Lesson
Once, a Gemini API Key was created from a Google Cloud project with billing enabled. Seven days, $127.80 USD.
Because billing was enabled, there were no free tier limits. AI thinking tokens cost $3.50 per million, with no rate limit cap.
How to Prevent It
1. API Keys ALWAYS go in .env files
2. .env files ALWAYS go in .gitignore
3. NEVER push .env to GitHub
4. Rotate Keys periodically
5. Set budget alerts on cloud services
If you remember only one thing: .env never goes in Git.
Pitfall #4: Having a Product but No Users
This was my biggest pitfall, and it's not a technical one — it's a mindset one.
When you start building with AI, you'll find that making products becomes incredibly fast. A few days and you can have a website, a tool, a system.
Then you'll fall into a trap: Constantly building products, forgetting to find users.
You spend two weeks building something cool. Launch it. Then what? Nobody knows, nobody uses it, nobody cares.
The Right Order
❌ Build product first → Then find people
✅ Find people first → Build product alongside
Marketing needs to start first.
Before your product is even done, you should already be:
- Documenting your development process on Threads/social media
- Getting your account interacting with people
- Sharing what you're building, letting people know you exist
By the time your product is done, you already have a group of people following you. They'll be your first users, first feedback-givers, first customers.
If you wait until the product is done to start marketing, you're starting from zero. And starting from zero is harder than you think.
Pitfall #5: Vercel Deployment Landmines
Vercel is a great deployment platform, and the free tier is sufficient. But it has some landmines beginners won't know about:
Landmine 1: Don't Create tsconfig.json in the api/ Folder
Vercel automatically handles TypeScript compilation. If you manually create a tsconfig.json, it'll actually break all your API endpoints.
Landmine 2: Newline Characters in Environment Variables
When setting environment variables, echo adds a trailing newline. Your API Key gets an invisible character at the end, and you can never connect.
Fix: Use printf instead of echo.
Landmine 3: Hobby Plan's 12 Function Limit
Vercel's free tier allows a maximum of 12 serverless functions. You won't hit this limit initially, but as your product gets more features, you'll suddenly be maxed out.
Fix: Merge related functionality into the same endpoint.
Pitfall #6: Firebase's "Free" Isn't Really Free
Firebase Firestore's free tier is 50K reads per day. Sounds like a lot?
If your page reads 10 documents on every load, 5,000 visitors per day will exhaust it. And Firebase bills by "number of reads," not "amount of data."
Even worse: if your code is poorly written, a single operation might trigger dozens of unnecessary reads.
How to Save
- Use
wherefilters, don't read entire collections - Cache infrequently changing data on the frontend
- Read once, don't repeatedly trigger reads in useEffect
The Right Attitude Toward Pitfalls
Most people's reaction to pitfalls: "Damn, wasted time again."
My reaction: "Great, another piece of content to write."
This isn't positive-thinking fluff. It's fact:
Every pitfall you've stepped in is experience others would pay money for.
- Stepped in Firebase pitfalls → You can help clients avoid the same ones
- Stepped in deployment pitfalls → You can write tutorial articles for lead generation
- Stepped in marketing pitfalls → You can give beginners genuinely useful advice
And sharing pitfall experiences is the best content. Because it's real, it resonates, it has value.
Nobody wants to read "I built a really successful product." What people want to read is "What I screwed up, how I fixed it, and how you can avoid it."
Pitfall Survival Guide for Beginners
□ After editing code, run npm run dev first — don't push directly
□ API Keys go in .env, .env goes in .gitignore
□ Set budget alerts on cloud services (especially AI APIs)
□ Don't try to learn all tools at once — one at a time
□ Start marketing before development — people first, product second
□ When you hit a pitfall, document it — it's your best content
□ Mistakes happen — what matters is what you learned
One Last Thing
Perfectionism is the biggest enemy of a solo business.
You don't need to wait until the product is perfect to launch. You don't need to wait until the article is perfect to publish. You don't need to wait until you know everything to start.
Launch → Get feedback → Fix → Launch again.
The faster this cycle, the faster you improve.
Pitfalls aren't scary. What's scary is being so afraid of pitfalls that you never start.
This is part three of the "Getting Started" series. Previous: The Art of AI Prompting: Why Your AI Conversations Never Give You What You Want
Want more free resources? Join the Solo Lab Discord.
Discord: https://discord.gg/ewS4rWXvWk
Originally published on Ultra Lab — we build AI products that run autonomously.
Try UltraProbe free — our AI security scanner checks your website for vulnerabilities in 30 seconds: ultralab.tw/probe
Top comments (0)