While the AI community debates which framework is best (LangChain, LlamaIndex, Haystack, DSPy), few engineers step back to ask a more fundamental question: should I use a framework at all? The most successful AI companies often build their core systems with plain Python. Meanwhile, many teams struggle with framework complexity that promises productivity but delivers friction.

This isn’t about frameworks being bad. It’s about making an intentional decision rather than following defaults. The right choice depends on your specific context, and that choice significantly impacts your team’s velocity, your system’s maintainability, and your production reliability.

The Real Cost of Frameworks

Frameworks promise productivity through abstraction. What they don’t advertise:

Learning curve is ongoing. Frameworks evolve quickly. The LangChain you learned six months ago has different patterns than today’s version. Keeping up consumes engineering time.

Abstraction obscures debugging. When something fails in production, you debug framework internals rather than your own code. Understanding where tokens are spent or why latency spiked requires deep framework knowledge.

Dependencies multiply. AI frameworks have substantial dependency trees. Updates can break working code. Version conflicts with other libraries create maintenance burden.

Opinions constrain options. Frameworks encode opinions about how AI applications should work. When your requirements don’t match those opinions, you fight the framework.

These costs aren’t always visible during initial development. They accumulate over time.

The Real Cost of Building

Building from scratch also has hidden costs:

Reinventing solved problems. Proper retry logic, rate limiting, streaming responses, error handling: frameworks have solved these problems. Building them yourself takes time.

Integration burden. Connecting to multiple LLM providers, vector databases, and tools requires boilerplate. Frameworks provide this, reducing initial setup.

Fewer examples available. When you build custom, Stack Overflow can’t help. Your team figures things out independently.

Onboarding complexity. New team members learn your custom patterns rather than industry-standard frameworks. Documentation burden falls on your team.

Edge cases missed. Framework maintainers have encountered edge cases you haven’t. Their code handles issues you don’t know exist.

Neither approach is free. The question is which costs you prefer to pay.

The Framework Decision Matrix

Use this matrix to think through your decision:

Factor	Favors Framework	Favors Building
Timeline	Short deadline	Flexible timeline
Team size	Larger team, mixed experience	Small team, strong skills
Requirements stability	Evolving requirements	Stable requirements
Integration count	Many integrations	Few integrations
Production maturity	MVP/prototype	Mission-critical system
Debugging priority	Speed of development	Speed of debugging
Maintenance horizon	Short-term project	Long-term maintenance

No single factor is decisive. The combination determines the right approach.

When Frameworks Win

Frameworks provide the most value when:

You’re exploring rapidly. Early-stage projects benefit from quick iteration. Frameworks let you test ideas without building infrastructure. The exploration speed matters more than the long-term costs.

Your team is new to AI development. Frameworks provide patterns and guardrails. Teams learning AI development benefit from the structure frameworks impose.

Integration breadth matters. If your application needs many integrations (multiple LLM providers, various vector databases, external tools), frameworks save significant boilerplate.

You need community support. When your problem matches common patterns, framework communities have likely solved it. That existing knowledge accelerates development.

The framework matches your use case. If you’re building exactly what the framework was designed for, it accelerates development without fighting its assumptions.

For practical framework implementation, my LangChain tutorial and LlamaIndex guide cover the core patterns.

When Building Wins

Custom code provides the most value when:

Production reliability is paramount. Understanding exactly how your system works enables faster debugging and more confident deployments. There’s no framework magic to investigate.

Performance matters. Framework overhead adds latency and resource consumption. For high-throughput applications, removing this overhead matters.

Requirements are clear and stable. When you know what you’re building, the investment in custom code pays off through maintainability. You build exactly what you need.

Your team has strong Python skills. Engineers who understand Python deeply can build more robust systems with plain code than with frameworks they don’t fully understand.

Cost optimization is critical. Controlling exactly when LLM calls happen and how prompts are constructed is easier without framework abstractions.

As I explain in my guide on ditching frameworks for plain Python, the pattern is simpler than frameworks make it appear.

The Hybrid Path

Most successful teams don’t choose one extreme:

Framework for prototyping, custom for production. Use frameworks to validate ideas quickly, then extract working patterns into production code.

Different tools for different components. Your retrieval service might use LlamaIndex, your agent logic might be plain Python, and your API layer might use standard web frameworks.

Framework components, custom orchestration. Use framework integrations and utilities while writing your own orchestration logic.

Start framework, extract when painful. Begin with a framework, then replace specific components as they become bottlenecks or sources of bugs.

The hybrid path gives you framework productivity where it helps and custom control where it matters.

Practical Evaluation Process

Before committing to either approach:

1. Build the simplest version manually. Write the core loop in plain Python: call LLM, process response, handle tools. See how complex it actually is without abstractions.

2. Build the same thing with a framework. Implement the same functionality with your candidate framework. Note where the framework helps and where it constrains.

3. Simulate production issues. Introduce failures, add logging requirements, optimize for cost. See how each approach handles production realities.

4. Consider your team honestly. Which approach will your actual team maintain more effectively? Theoretical best practices matter less than practical team capabilities.

This evaluation takes a day or two. That investment prevents months of living with the wrong choice.

Signs You Should Switch

Signs framework is hurting:

• Debugging sessions focus on framework internals
• Framework updates break your code frequently
• You’re working around framework limitations constantly
• Simple changes require understanding complex abstractions
• Team knowledge concentrates in one or two “framework experts”

Signs custom code is hurting:

• You’re reimplementing standard patterns repeatedly
• Integration code dominates your codebase
• New team members take too long to become productive
• Edge cases cause production issues you didn’t anticipate
• Development velocity keeps declining

Neither approach is permanent. Switching has a cost, but continuing with the wrong approach has costs too.

Making the Decision

The build vs framework decision is really about where you want to invest engineering effort:

Invest in frameworks when your challenge is getting started, integrating many services, or leveraging community patterns. The framework handles complexity you don’t want to think about.

Invest in building when your challenge is production reliability, performance optimization, or long-term maintenance. The custom code gives you control over what matters most.

For most AI applications, I recommend:

Start with understanding. Build the core pattern in plain Python, even as an exercise. Understanding what’s actually happening makes you better at using frameworks and at building custom.

Add abstraction deliberately. If specific complexity genuinely warrants framework abstraction, add it. If plain Python handles it cleanly, you might not need more.

Evaluate continuously. The right choice can change as your requirements, team, and application evolve. Periodically ask whether your current approach still serves you.

The engineers building the most successful AI applications aren’t framework zealots or framework skeptics. They’re pragmatists who use the right tool for each specific need, and who aren’t afraid to change course when the evidence suggests they should.

For more implementation guidance, watch my tutorials on YouTube.

Ready to discuss build vs framework decisions with engineers who’ve made these choices in production? Join the AI Engineering community where we share real experiences building AI systems with both approaches.