When Serverless Is the Wrong First Choice

Serverless is often marketed as no infrastructure to manage, infinite scalability and lower costs. For an early-stage product, that promise can hide friction in local development, testing, observability and cost. In this post we cover where serverless breaks down, when it fits and a better iterative architecture.

Why Founders Struggle With Serverless Early On

Imagine you run a logistics company and want to productize a novel route optimization algorithm. You've seen the marketing, where 'serverless' means no infrastructure to manage, infinite scalability, and lower costs. So you start thinking about building your product entirely with Lambda functions, API Gateway, and a collection of managed services. On paper, it sounds ideal for focusing purely on your core logic.

The naive solution is to jump in, carving every API endpoint into a separate function, orchestrating complex workflows with step functions, and assuming the platform handles all the 'undifferentiated heavy lifting.' The promise of hands-off infrastructure is compelling, especially when your core expertise is in logistics, not highly distributed systems engineering.

What Breaks When You Go All In on Serverless

In practice, this approach often breaks down for early-stage products in several ways. First, local development becomes a nightmare. Replicating the full serverless environment on a developer's machine to debug a sequence of functions, data transformations, and event triggers is an arduous task. You spend more time configuring local emulators and debugging deployment issues than iterating on your core business logic.

Testing complex interactions between dozens of small, independently deployed functions introduces significant overhead. Unit testing individual functions is straightforward, but integration testing the entire flow – especially across different managed services – requires a level of orchestration that often exceeds the capabilities of a small, focused team aiming to validate a market hypothesis.

Observability, while powerful in serverless environments, comes with a steep learning curve. Aggregating logs, traces, and metrics across hundreds of distinct invocations and services creates a firehose of information that requires sophisticated tooling and expertise to manage, interpret, and act upon. For a new product team, this often means diverting precious resources from feature development to infrastructure plumbing.

Cost visibility can also become a problem. While individual serverless invocations are cheap, the cumulative cost of millions of executions, data transfer, and associated managed services can quickly outpace simpler, more predictable compute models, especially as you navigate usage patterns on a new product that hasn't found its footing.

Building an early-stage product with a full serverless architecture is like assembling a highly optimized, custom race engine when you're still learning to drive and are unsure if the car even fits the track.

Finally, vendor lock-in becomes a real concern. While some serverless principles are portable, the specific implementations of functions, event subscriptions, API gateways, and storage solutions are deeply tied to a single cloud provider. Decoupling from this ecosystem later, if necessary, can be a monumental task.

When Serverless Becomes a Poor Choice for New Workflows

Serverless excels when workloads are truly event-driven, sporadic, and highly parallelizable. Think image processing, document conversions, or responding to discrete data changes. For most early-stage products, especially those building a bespoke workflow or a web application with complex user interactions and state management, serverless introduces more friction than it removes.

If your core workflow involves long-running processes, stateful interactions across multiple requests, or requires fine-grained control over the underlying operating system or networking, serverless functions become an impedance mismatch. You end up bending the serverless model in unnatural ways, adding layers of indirection and complexity to achieve what a more traditional server (or container) could do with less effort and clearer reasoning.

For productizing a novel workflow, your primary goal is rapid iteration and learning. You need to change your schema, business rules, and API contracts frequently based on user feedback. A service with a few well-defined endpoints and a clear deployment pipeline, often running within a container or on a small VM, allows for faster cycles of code-deploy-learn. The overhead of deploying and coordinating changes across dozens or hundreds of tiny functions slows this process down significantly.

A Better Iterative Approach to Product Architecture

A better way to approach this iteratively is to start with a simpler, more cohesive architecture that allows for rapid development and clear reasoning. This often means a monolithic application, perhaps containerized, with a clear internal structure. You can deploy it to a single compute instance or a few containers in a managed service like AWS Fargate or Google Cloud Run.

This approach keeps your business logic together, simplifies local development and debugging, and eases deployments. As your product evolves and specific bottlenecks emerge, you can then selectively introduce serverless components where they genuinely make sense. For example, extracting an image resizing service or a nightly data aggregation job into a serverless function. This gradual evolution allows you to benefit from serverless where its strengths align with your needs, without the initial overhead.

Start with a clear boundary for your core service. Use a single backend application that handles most of your logic and exposes an API. Deploy it simply. Use a managed database. Spend your time on the user experience and the core problem you're solving, not on orchestrating a distributed system you don't yet need. The Founder's Playbook emphasizes this focus on core value early on. For the same argument applied to services, see when to choose a monolith over microservices for your startup and how to structure your codebase so it survives scaling.

How to Decide If Serverless Fits Your First Product

Before committing to a serverless-first strategy for your product's initial version, use this framework to guide your decision:

1. Is your core workload truly stateless and event-driven? If your application logic primarily reacts to discrete events, processes data, and then completes, without maintaining complex session state across requests, serverless might be a good fit. If it's a typical CRUD web application with user sessions, complex transactions, and long-running processes, start elsewhere.
2. Do you have dedicated DevOps or experienced cloud engineers on your early team? Full serverless adoption requires a deep understanding of managed services, instrumentation, and distributed system debugging. If your initial team is product-focused with limited infrastructure expertise, the operational burden will be high.
3. Is your traffic pattern highly unpredictable and sporadic, with long idle periods? If you anticipate bursts of traffic followed by hours of inactivity, serverless's pay-per-execution model can be cost-effective. For consistent, predictable baseline traffic, a persistent server often has lower total cost of ownership and fewer operational quirks.
4. Are you building an API gateway for existing backend services, not a new application? Serverless functions, especially combined with API Gateway, are excellent for choreographing calls to existing services or creating light wrappers. For a completely new product with new business logic, this benefit is less pronounced.
5. Is local development and comprehensive integration testing a low priority for your early feedback loop? If you can iterate and debug effectively primarily in cloud environments, the local development challenges of serverless might be acceptable. Most early teams need fast local feedback.
6. Do you have a clear plan for observability (logging, tracing, metrics) across dozens of micro-services from day one? If you don't, you will be blind to failures and performance issues in production. This takes significant upfront effort and tooling.

The vast majority of new products building interactive web applications or complex internal workflows will benefit from a more traditional, cohesive application architecture initially. Save serverless for specific problems that genuinely align with its strengths, and introduce it incrementally as your product matures and grows. Engineering Principles often advocates starting simple and evolving.

If you're building a product and want to avoid the expensive mistakes, talk to Better Software. We help founders scope and build version one without the rework.

Frequently Asked Questions

What Is the Main Benefit of Avoiding Serverless for an MVP?

We find that avoiding serverless for an MVP simplifies local development, debugging and deployment. That allows faster iteration on core features and business logic, without the overhead of managing a highly distributed, complex system while the market hypothesis is still being tested.

Can Serverless Be Added Later to a Product?

Yes, we introduce serverless components incrementally as a product matures. Once specific bottlenecks or clear event-driven, stateless use cases emerge, such as an image resizing service or a nightly data aggregation job, we extract those parts into functions without the initial architectural commitment.

Does Serverless Always Reduce Infrastructure Costs?

We find the answer is not always yes for early products. Individual invocations are cheap and idle costs disappear, yet the cumulative cost of millions of executions, data transfer and managed services can be unpredictable and higher than a single, predictably sized server without careful cost management.

When Is Serverless a Good Fit?

We see it excel when workloads are truly event-driven, sporadic and highly parallelizable, such as image processing, document conversions or reacting to discrete data changes. It also helps when traffic arrives in bursts with long idle periods, or when wrapping existing backend services.

What Should an Early Product Run On Instead?

We start with a simpler, cohesive architecture, often a containerized monolith with a clear internal structure. It can run on a single instance or a few containers in a managed service such as AWS Fargate or Google Cloud Run, with a managed database, so effort goes into the user experience.