As a software engineer, I've had the privilege of working alongside some of the smartest people I know in both technology and business. Through these experiences and my own study, I've developed the ability to evaluate product development through dual lenses: technical feasibility and business viability. Recently, a conversation with an aspiring founder illustrated something I've been thinking about: how easy it is to let AI-generated technical advice override critical thinking and domain expertise.
When Tools Replace Critical Thinking
Someone recently approached me with what they described as a revolutionary idea—a fashion and lifestyle e-commerce platform combining AI, VR, and AR capabilities. They presented an extraordinarily complex tech stack document featuring custom infrastructure, self-hosted ML operations, multiple database engines, and microservices architecture.
For someone with no technical background, this list was suspiciously comprehensive. It became clear they had assembled this entire technical strategy using AI tools. The architecture looked impressive on paper but revealed several critical misjudgments:
- No business validation - When I asked about market research, vendor relationships, or supply chain, the answer was minimal: two local shop conversations.
- Technology before business model - They wanted to build custom ML infrastructure and complex microservices before proving anyone wanted the core product.
- Misunderstanding of costs - They claimed their AI-generated stack would be "less expensive" than my recommendations, despite requiring custom development of everything from scratch.
- Dismissing domain expertise - When I suggested starting with e-commerce validation first, then layering features, they became defensive. The AI had provided a complete vision, and expertise that contradicted it wasn't welcome.
The Real Problem
Here's the issue: AI tools generate technically plausible architectures, but they lack context about your business stage, constraints, and actual needs.
An AI will recommend enterprise-grade solutions because it's trained on successful companies' architectures. But those companies didn't start there—they evolved to those systems after proving their business model and generating revenue.
Business First, Technology Second
When I asked about market validation—existing retail relationships, customer research, vendor partnerships—the answer was thin. No established supply chain, no customer base, no vendor network.
This is critical because in e-commerce, your app is not your business. Your business is:
- Your supply chain
- Your vendor relationships
- Your customer acquisition strategy
- Your fulfillment capabilities
- Your margins and unit economics
The technology is simply the tool that enables these core competencies. Companies that succeed in this space don't win because of their tech stack—they win because they understand operations, logistics, and customer needs.
The Right Way to Build: Start With Your Core Value
My recommendation was straightforward: build the e-commerce foundation first. Here's why:
- Validate your business model - Can you actually move products? Do customers want what you're selling?
- Build your user base - Real users engaging with real products
- Generate revenue - Prove the business fundamentals work
- Then layer on features - Once you have traction, add AI recommendations, AR try-ons, social features
This isn't about lacking ambition. It's about structured iteration. Every successful super app started as a focused product. They expanded once they had proven their core and built a user base.
The Cost Conversation
Despite having no technical background, this person claimed their proposed stack would be "less expensive" than my recommendations. Let me share some hard-earned wisdom about tech stack decisions:
Start With Leverage, Not Control
For a pre-revenue startup, services like WorkOS for authentication make perfect sense. They offer up to 1M users free. That's not vendor lock-in—that's business leverage.
Here's the math: If your business is good enough to get 100,000 paying users, you'll have revenue. At that point, migrating to a custom system becomes a planned business expense—a calculated investment funded by actual income.
Migration is Part of Growth Strategy
This is something non-technical founders often misunderstand: migration, refactoring, and technical evolution are normal parts of successful businesses.
When you're established with revenue:
- You have resources to hire specialized engineers
- You have actual usage data to inform optimization decisions
- You have business metrics to justify infrastructure investments
- You have operational margin to fund technical improvements
The cost of migrating 100K users from WorkOS to a custom auth system might be $50-100K in engineering time. Sounds expensive? Not when you're generating revenue. That's a manageable business expense.
Building that custom auth system from day one? That's $100K+ spent before you know if anyone wants your product. That's not being cost-conscious—that's burning money.
The Reality of "Vendor Lock-in"
When I suggested Cloudflare for CDN and edge services, the response was concern about vendor lock-in. This perfectly illustrated the disconnect between AI-generated fears and business reality.
Real vendor lock-in is when switching providers is technically impossible or prohibitively expensive relative to your business scale. Using Cloudflare's CDN isn't lock-in—your content is portable, and migrating to AWS CloudFront or similar services is straightforward when you have the scale to justify it.
Building Custom vs. Leveraging Services
The proposed stack implied building machine learning infrastructure from the ground up. This deserves scrutiny.
Production-grade ML systems require training data you don't have at launch, specialized engineering talent, expensive compute infrastructure, and ongoing operational overhead.
Modern AI APIs—offering vision, language, and recommendation capabilities—exist precisely to remove this burden. You get to offer sophisticated features without the infrastructure complexity.
The question isn't "can we build this?" It's "should we build this now, or focus resources on validating our business model?"
What Actually Reduces Costs
Here's what genuinely keeps startup costs down:
- Use generous free tiers - Supabase, Vercel, WorkOS, Cloudflare offer incredible free tiers
- Managed services over self-hosted - Your engineering time is your most expensive resource
- Monolith before microservices - A well-structured monolith scales to millions of users
- Proven tech over bleeding edge - Pick boring technology; it's boring because it works
- Buy don't build - Unless it's your core differentiator, use existing solutions
And crucially: Plan for migration as part of business growth. It's not a failure to start with managed services and migrate later—it's smart capital allocation.
The Real Expense
The real expense isn't Cloudflare or managed services. The real expense is building the wrong thing—spending months building a complex system with self-hosted infrastructure before validating if anyone wants the core product.
Every dollar and hour spent on custom infrastructure is a dollar and hour not spent on:
- Understanding your customers
- Building vendor relationships
- Refining your product-market fit
- Acquiring users
- Generating revenue
Where Guidance Falls Short
This experience highlighted something I've been observing: the risk of making decisions in domains where you lack expertise, without consulting those who have it.
Modern tools provide unprecedented access to information. You can research technical architectures, best practices, and industry standards with ease. But information without context can be misleading.
The challenge isn't access to knowledge—it's knowing what applies to your specific situation.
My Advice to Founders
If you're technical:
- Resist the urge to over-engineer
- Your goal is to validate assumptions as quickly as possible
- Pick tools that let you ship fast, not tools that look impressive on a diagram
- Build from experience, not from AI prompts
If you're non-technical:
- Find a technical advisor you trust, then actually listen to them
- Understand that comprehensive technical plans need business context
- "Complete" tech stacks don't guarantee successful products—solving real problems does
- Question technical decisions you don't understand, but respect domain expertise
- The best architecture is the one that gets you to validation fastest
When evaluating technical approaches:
- Treat AI-generated advice as input, not direction
- Validate recommendations with people who have relevant experience
- Understand that optimal and practical are different things
- Remember that successful companies evolved their infrastructure—they didn't start with it
The Bottom Line
Your tech stack should be the last thing you optimize, not the first. Start with:
- Validate the business model
- Build the minimum product that proves value
- Get real users
- Generate revenue
- Scale and refactor what works
Migration, refactoring, and technical evolution aren't problems—they're signs of success. They're the "problems" you want to have, because they mean your business is growing.
The mistake is spending months building comprehensive systems for unproven concepts, guided by impressive-sounding advice that lacks business context.
Top comments (0)