The Anti-Boilerplate Movement: Why Founders Are Skipping Frameworks

TL;DR: A growing wave of founders in 2026 is skipping framework scaffolding entirely. No 'rails new', no 'create-next-app', no starter templates. They prompt an AI app builder, get a working product, and ship --- bypassing the whole framework-conventions layer that defined SaaS building for 15 years. This isn't engineers being lazy; it's founders making a rational decision about where their leverage lives. This guide covers why founders are skipping frameworks, what they're skipping specifically, what they're using instead, the trade-offs they're accepting, and what the trend means for the next wave of indie SaaS.

Introduction

For 15 years, the first commands a new founder typed when starting a software project were variations of the same idea --- 'rails new my-app', 'npx create-next-app', 'django-admin startproject', 'create-react-app'. Frameworks provided the scaffolding --- conventions, structure, plumbing --- that engineering teams treated as the default starting point. The framework decision was one of the most consequential decisions early in a project's life.

In 2026, a growing wave of founders skips that step entirely. No framework scaffolding. No starter templates. No 'rails new'. They prompt an AI app builder (Greta, Lovable, Bolt), describe what they want, get a working product, and ship. The framework isn't replaced with a different framework; it's bypassed entirely. The underlying code is still Next.js or similar --- but founders never sit at a fresh framework install screen. They go from idea to working product without ever choosing a framework consciously.

This is the anti-boilerplate movement. Not the death of boilerplate code (AI generates the code that boilerplate produced). This is the death of framework-as-decision-point. Founders treat the choice of framework as an implementation detail handled by their AI app builder, not as a strategic decision they make personally. This guide covers why the movement is happening, what specifically is being skipped, the trade-offs founders are accepting, and what it means for indie SaaS.

What founders are specifically skipping

Framework scaffold commands

• rails new my-app
• npx create-next-app
• django-admin startproject
• create-react-app
• ng new my-app (Angular CLI)
• vue create my-app
• Phoenix mix phx.new
• Express generator

Starter template hunting

• Picking from 50+ Next.js starter templates
• Evaluating SaaS-specific starters
• Comparing GitHub stars and last-commit dates
• Reading documentation for each starter's opinionated choices

Boilerplate decisions

• TypeScript or JavaScript? (AI builder defaults to TypeScript)
• Tailwind or styled-components? (AI builder picks one)
• App Router or Pages Router? (AI builder picks)
• State management library? (AI builder picks contextually)
• Testing framework? (AI builder generates tests in its convention)
• Linter and formatter config? (AI builder defaults)

Initial setup work

• Auth library integration and configuration
• Database schema and ORM setup
• Environment variable management
• CI/CD pipeline setup
• Hosting platform configuration

Why founders are making this trade

Time-to-product is the dominant factor

• Framework decisions consume 1--3 days of upfront work for non-engineers
• Even for engineers, scaffolding + initial setup takes hours-days
• AI app builders compress that to minutes
• Founders prioritize getting to customer feedback fast over framework optimization

Framework expertise is no longer a moat

• Deep framework knowledge mattered when frameworks were the rate-limiter on shipping
• AI handles framework patterns competently
• Founder time better spent on customer development than framework mastery
• Engineering hires can handle framework-specific decisions later

Frameworks were designed for problems AI now solves

• Rails convention-over-configuration solved 'engineers need shared conventions to coordinate'
• Next.js scaffolding solved 'setting up React + routing + SSR is painful'
• Framework starters solved 'every project re-solves the same boilerplate problems'
• AI app builders solve all three problems at a different layer

Lock-in is lower than expected

• Founders worried about being locked into AI app builders
• Reality: AI app builders generate real Next.js/React code in GitHub
• Migration off AI builder to direct development is straightforward
• Lock-in fear was based on no-code platform history; doesn't apply to code-output builders

Who's leading the movement

Non-technical founders

• Domain experts (real estate, healthcare, fintech) without engineering background
• Designers shipping their own products
• PMs from larger companies starting indie
• Marketing/growth folks building products they can sell

Engineers running indie SaaS

• Engineers who know frameworks but choose to skip for indie projects
• Optimizing for shipping cadence over framework optimization
• Recognize their time is better spent on judgment-heavy work
• Often AI-IDE-augmented for parts of the build (Cursor for complex logic)

Solo founders post-layoff

• Engineers laid off in 2023--2025 starting indie SaaS
• Shipping product alone; can't afford framework optimization time
• Embracing AI app builders as accelerant

Designers shipping full products

• Designers using AI app builders to ship products without engineering hires
• Combine design skill with AI-generated implementation
• New category of cross-functional creators

What founders are using instead

AI app builders as primary tool

• Greta --- Prompt-native, full stack generation
• Lovable --- Design-focused prompt-driven builder
• Bolt --- Strong for lighter-weight apps
• Rocket.new --- Adjacent player in the category

Each platform handles framework conventions internally; founder never sees the scaffolding.

AI IDEs as augmentation

• Cursor for complex logic the AI app builder doesn't handle well
• Windsurf for similar augmentation
• Used after AI app builder for harden phase or complex feature work
• Engineers in indie SaaS often use both

Backend-as-a-Service

• Supabase for auth, database, storage
• Firebase as alternative
• Stripe for payments
• Resend for transactional email
• All bundled with AI app builder defaults

Hosting platforms with smart defaults

• Vercel for Next.js (default for most AI builders)
• Netlify as alternative
• Railway for backend-heavy apps
• Render for full-stack with database
• Choice often defaulted by AI builder; founder doesn't agonize over it

Trade-offs founders are accepting

Less framework-specific expertise development

• Founders don't learn Next.js patterns as deeply
• Framework expertise comes later, if/when engineering hires arrive
• Trade-off accepted: shipping speed > framework expertise development

Defaults instead of optimal choices

• AI builder defaults may not be optimal for every situation
• Most defaults are reasonable for most projects
• Optimization opportunities exist but rarely worth the time at v1

Some learning curve when handing to engineers

• When founder hires first engineer, engineer must understand AI-generated codebase
• Slight onboarding curve
• Manageable; AI-generated Next.js code is conventional

Platform risk in the AI app builder itself

• If AI app builder shuts down, code remains (in GitHub) but loses the prompt-driven workflow
• Lower risk than pure no-code platform lock-in
• Mitigated by AI app builders that generate real code in user-owned repos

What this means for framework ecosystems

Frameworks themselves remain (with different role)

• Next.js, Rails, Django, etc. still exist
• Used by AI app builders under the hood
• Less direct interaction from founders
• Framework communities continue developing the underlying tech

Framework starters become less critical

• Starter template ecosystems (SaaS starters, marketplace starters) compress
• AI app builders are the new abstraction layer
• Some starter templates pivot toward AI-augmented usage

Convention-over-configuration philosophy proven correct

• Rails' original philosophy (convention over configuration) was foundational
• AI app builders take it further --- AI selects conventions for founders
• Less choice = less time spent choosing

How the shift compares to past movements

The Rails movement (2005--2010)

• Rails replaced the Java/PHP enterprise development paradigm for many web apps
• Convention over configuration was the shift
• Productivity gains attracted founders and small teams
• Established that 'opinionated frameworks' could win

The Node.js / JavaScript everywhere movement (2012--2018)

• Same language frontend and backend
• Productivity for full-stack developers
• Established Next.js + React as dominant pattern
• Frontend tooling proliferated

The no-code movement (2018--2022)

• Bubble, Webflow, others tried to abstract away code entirely
• Worked for specific use cases (marketing sites, simple apps)
• Hit ceilings for complex applications
• Established that non-coders wanted to build software

The vibe coding / AI app builder movement (2024--2026)

• Combines AI generation with code output
• Solves the no-code ceiling problem (real code, no platform lock-in)
• Enables non-coders to ship real products
• Frameworks remain underneath, abstracted from founder

Common arguments against the anti-boilerplate movement

"Founders should understand the technology"

Counter: founders don't need to understand the technology at the level frameworks demand. Founders need to understand customer needs, business model, distribution, operational discipline. Framework expertise is engineering-level knowledge; founders make founder-level decisions.

"AI-generated code is poorly architected"

Counter: AI-generated code from modern app builders is reasonable architecturally. Not optimal for every case, but acceptable for v1. As products mature, engineering hires refactor as needed. The 'good enough' bar is met.

"You'll have to redo it all when you scale"

Counter: most products don't scale to the point where v1 architecture becomes a blocker. The ones that do refactor incrementally. AI-generated v1 code is rarely thrown away wholesale; it evolves. Premature framework optimization is a classic mistake.

"Real engineers won't want to work on this code"

Counter: real engineers are increasingly using AI tools themselves. Code quality from AI app builders + post-launch engineering refinement matches code from greenfield builds with similar level of attention. Engineers comfortable with modern stacks are also comfortable with AI-augmented codebases.

"This will produce a generation of founders who can't code"

Counter: many of the most successful tech founders historically didn't code. Founders who can't code but can articulate clear product vision, manage operations, sell to customers, and hire engineers can build real businesses.

The pattern emerging in indie SaaS in 2026

• Founder selects niche based on domain expertise
• Founder writes 1-page PRD describing product
• Founder prompts AI app builder; gets working product in days
• Founder uses Cursor or similar for harden phase if engineer; hires engineer if not
• Founder spends most time on customer development, marketing, operations
• Engineering investment scales with revenue, not with build complexity
• Hiring happens later than in old indie SaaS (post-$50K--$200K MRR)

What about engineers in the anti-boilerplate movement?

• Many engineers themselves are skipping frameworks for indie projects
• Engineers running indie SaaS use AI app builders for similar reasons (time-to-market)
• Engineers' framework expertise becomes valuable in different ways --- in larger codebases, complex features, mentorship
• Senior engineers leading lean teams use AI app builders + AI IDEs combination
• Framework expertise still matters for engineers at established companies and for complex products

Concerns this raises

• Skill development for junior engineers --- Where do juniors develop framework intuition if AI handles it?
• Long-term maintenance --- What happens when AI app builders evolve and codebases need updates?
• Diversity of approaches --- Does AI consolidating choices reduce ecosystem diversity?
• Quality bar --- Does the lower friction enable lower-quality products to proliferate?
• Education impact --- How do bootcamps and CS programs adapt to AI-first paradigms?

These are real concerns. Junior engineers benefit from understanding fundamentals AI abstracts; programs that emphasize fundamentals + AI fluency produce more competitive engineers than either alone. Long-term maintenance is real but manageable. Ecosystem diversity may compress somewhat. Quality concerns exist but markets sort low-quality products out over time.

What's emerging next

• AI app builders specializing by vertical (real estate, fintech, healthcare specifically)
• AI app builders specializing by app type (marketplaces, SaaS, internal tools)
• Better handoff workflows from AI app builder to engineer-led development
• AI agents that maintain and evolve codebases over time
• Specialized AI tools for harden phase, security review, performance optimization
• New roles: 'AI app builder operator' as a specific skill set

Common Mistakes in the Anti-Boilerplate Approach

• Treating AI app builder output as production-ready without harden phase --- Build cycles compressed but harden phase non-optional. Auth, RLS, error handling still need engineering attention.
• Skipping engineering judgment entirely --- Architecture, security, performance still require engineering thinking. Founders without engineering background should hire engineering consultation for production launch.
• Choosing AI app builder based on hype without project fit --- Different builders work for different use cases. Pick deliberately.
• Underestimating non-engineering work --- Time saved on build is best spent on customer development, not on more building.
• Resisting engineering hires for too long --- Eventually most indie SaaS hire engineers. Bring them in when complexity exceeds founder + AI builder capacity.
• Ignoring long-term maintenance --- Codebases need updates, security patches, dependency updates. Human attention required.
• Treating the movement as anti-engineer --- Engineers are increasingly part of the movement. The movement is anti-boilerplate, not anti-engineering.
• Skipping the customer empathy work --- AI app builders don't replace customer research. Building right things matters more than ever.
• Comparing v1 AI-generated code to mature framework codebases --- Different stages, different expectations. Most v1 codebases need refactoring as product matures.

Frequently Asked Questions

Q1: Is the anti-boilerplate movement anti-engineer? No. Many engineers are themselves part of the movement, using AI app builders for indie SaaS and lean team work. The movement is about skipping boilerplate decisions, not about eliminating engineering judgment.

Q2: Will frameworks disappear entirely? No. Frameworks remain underneath AI app builders. The change is that founders interact with AI app builders, not frameworks directly. Framework communities continue developing the underlying tech.

Q3: What about quality concerns with AI-generated code? Code quality from modern AI app builders is reasonable. Not optimal for every case but acceptable for v1. Engineering refinement happens as products mature. The bar of 'good enough to ship and learn' is met.

Q4: Should junior engineers still learn frameworks? Yes. Framework fundamentals enable judgment that AI can't replicate. Best path: learn fundamentals + AI fluency together. Pure framework specialism less valuable; pure AI prompting without underlying knowledge also limited. Both together is the strong position.

Q5: What if AI app builders fail or pivot? The code is in your GitHub. You own it. Migration off AI app builder is straightforward --- you lose the prompt workflow but keep the code. Much lower platform risk than no-code platforms with lock-in.

Q6: How do I onboard engineers to an AI-generated codebase? Standard Next.js/React patterns. Engineers comfortable with modern web stack will be comfortable. Some onboarding to AI app builder workflow if the engineer will continue using it; otherwise treat as normal codebase.

Q7: Is this a permanent shift or a phase? Structural shift. The economics support founders shipping faster without framework scaffolding. AI capabilities continue improving. The trend continues; the specific tools may evolve.

Conclusion

• Founders are skipping framework scaffolding entirely in 2026. No 'rails new'. No starter templates. No agonizing over framework choices. They prompt AI app builders and ship.
• Why: time-to-product dominates. Framework expertise is no longer a moat for founders. Frameworks solved problems AI app builders now solve at a different layer. Lock-in risk is lower than expected (real code in GitHub).
• Trade-offs accepted: less framework-specific expertise development, defaults instead of optimal choices, slight engineer onboarding curve when hiring, platform risk in AI app builder (mitigated by code ownership).
• Frameworks remain underneath; founders interact with AI app builders instead. The movement is anti-boilerplate, not anti-engineering. Engineers are increasingly part of the movement themselves.

If you're a founder starting a SaaS in 2026, the rational default is to skip framework scaffolding entirely. Prompt an AI app builder. Ship. Iterate. Hire engineers when revenue justifies. The decades-long ritual of 'choose framework → install scaffold → configure → build' compressed to 'prompt → ship'. The founders adopting this approach ship faster, learn from customers earlier, and reach product-market fit with less capital. The engineers and frameworks didn't disappear; the founder-facing layer changed. Take advantage of the change. Don't agonize over framework decisions that AI handles for you. Spend that time with customers. The anti-boilerplate movement isn't a fad; it's the structural pattern for how indie SaaS gets built in 2026 and beyond.