When can you get away with Next.js and Netlify, and when not

When we first set out on building letsroll.ai, we were a small, part-time duo with big ideas and a prototype built on Next.js and deployed to Netlify. We had used n8n, google sheets and a chatGPT powered chatbot. All of this felt like the perfect match for rapid prototyping, a recipe that allowed us to get something in front of people quickly. But as letsroll started to gain traction, we encountered the inevitable friction between rapid prototyping and the demands of a growing, real-world application.

The early days: when Netlify and Next.js were just right

Our initial tech stack was simple and elegant. Next.js powered our frontend, offering a modern developer experience, while Netlify’s hosting capabilities meant our deployment was as smooth as our code. It was an environment that let us iterate at lightning speed, ideal for a prototype. Yet, as user feedback began rolling in, we realized that our setup was showing cracks. One of the biggest shocks was our realization that there was no simple way to disable caching on Next.js server routes. Simple or not, you can add

export const dynamic = "force-dynamic"

on a route, and `Cache-Control: no-store` on requests for added measure. But then you realize Netlify has an even higher affinity to caching, to the point of even ignoring your directives.

Normally 'Cache-Control: no-store' should do the trick, but our confidence was lost the moment we still saw Cache-Status: "Netlify Edge"; hit

Netlify’s caching mechanisms, an asset for a mostly static prototype, now felt like a barrier to the custom optimizations we needed for a data heavy interactive application like ours.

The tipping point: needing more control

It was a turning point. Our growing user base and the complexities of our application pushed us to rethink our approach. In the meantime, we had introduced Supabase and were tried deployments with AWS Amplify. AWS Amplify never quite worked out with way too many build errors simply because it didn't play well with Next.js. We decided to go old school and transitioned to AWS EC2 instances, using Terraform to manage our infrastructure as code. This change granted us the control we craved: the ability to fine-tune server configurations and manage costs more effectively. However, it wasn’t without its challenges. The migration underscored a vital lesson: when you outgrow a platform like Netlify, you’re stepping into a realm where operational complexities multiply.

Embracing a new era: from EC2 to Serverless with ECS Fargate

Managing our own servers on EC2 was a necessary evolution, but it soon became clear that we needed a balance between control and simplicity. Enter AWS ECS Fargate: a serverless solution that promised automatic scaling and reduced operational overhead. The migration to Fargate was transformative. Not only did it align with our goals for a more efficient infrastructure, but it also reaffirmed the importance of knowing when to pivot your strategy.

When can you get away with Netlify and Next.js, and when should you take the leap?

Our journey wasn’t just about technical migration: it’s a story of understanding trade-offs:

Prototype Stage: If you’re testing ideas and your product is in its infancy, Netlify/Vercel and Next.js offer a fast, cost-effective path. They let you focus on building without the overhead of managing infrastructure.
Growth and Scale: As your user base expands and your application’s complexity increases, you may need the granular control offered by AWS EC2 and Terraform. But be prepared: this transition demands a deeper dive into DevOps practices, specially around managing down-time free deployments and handling failed builds.
Optimizing for Efficiency: When operational overhead becomes a bottleneck, consider serverless options like ECS Fargate. It’s about finding the sweet spot between control, scalability, and ease of management. ECS Fargate (and similar solutions) free you up to focus on your core product while handing over the infrastructure scaling and management largely to the cloud provider.

A winning infrastructure: lessons for every stage of your journey

Our technical journey, from Netlify to EC2 to Fargate, taught us that there’s no one-size-fits-all solution. It’s all about choosing what fits your stage:

• Prototype: You’re moving fast, shipping ideas quickly, and focusing on user feedback. Choose a hands free server architecture.
• Maturity: You need deeper control and cost management. Owning your infrastructure starts making sense.
• Scaling: Operational headaches push you to look for serverless solutions that automate the nitty-gritty.

Our story might look different from yours, but the lessons are universal. Begin where you are, recognize the limits when you hit them, and pivot your infrastructure strategy as your product and audience grow. Trust me, there’s power in starting simple and a real payoff in evolving when the time is right.

If you had to make similar choices for your ventures and side-projects, let's compare notes. Drop me a DM or write on the letsroll feed!