![\"\"](\"https://techcrunch.com/wp-content/uploads/2026/05/tc-lockup-hp.svg\")
\t\t\t\t\t\t![\"\"](\"https://techcrunch.com/wp-content/uploads/2024/09/tc-logo-mobile.svg\"){kind=logo}
\t\t\t\t\t\tWhile serverless is typically championed as a way to reduce costs and scale massively on demand, there is one extraordinarily compelling reason above all others to adopt a serverless-first approach: it is the best way to achieve maximum development velocity over time. It is not easy to implement correctly and is certainly not a cure-all, but, done right, it paves an extraordinary path to maximizing development velocity, and it is because of this that serverless is the most under-hyped, under-discussed tech movement amongst founders and investors\u00a0today.
\nThe case for serverless starts with a simple premise: if the fastest startup in a given market is going to win, then\u00a0the most important thing is to maintain or increase development velocity over time.\u00a0This may sound obvious, but very, very few startups state\u00a0maintaining or increasing development velocity\u00a0as an explicit goal.
\n\u201cDevelopment velocity,\u201d to be specific, means\u00a0the speed at which you can deliver an additional unit of value to a customer.\u00a0Of course, an additional unit of customer value can be delivered either by shipping more value to existing customers, or by shipping existing value\u2014that is, existing features\u2014to new customers.
\nFor many tech startups, particularly in the B2B space, both of these are gated by development throughput (the former for obvious reasons, and the latter because new customer onboarding is often limited by onboarding automation that must be built by engineers). What does serverless mean, exactly? It’s a bit of a misnomer. Just as\u00a0cloud computing\u00a0didn\u2019t mean that data centers disappeared into the ether — it meant that those data centers were being run by someone else, and servers could be provisioned on-demand and paid for by the hour —\u00a0serverless\u00a0doesn\u2019t mean that there aren\u2019t any servers.
\n\nThere always have to be servers somewhere. Broadly, serverless means that you aren\u2019t responsible for all of the configuration and management of those servers. A good definition of serverless is\u00a0pay-per-use computing where uptime is out of the developer\u2019s control. With zero usage, there is zero cost. And if the service goes down, you are not responsible for getting it back up. AWS started the serverless movement in 2014 with a \u201cserverless compute\u201d platform called\u00a0AWS Lambda.
\nWhereas a \u2018normal\u2019 cloud server like AWS\u2019s EC2 offering had to be provisioned in advance and was billed by the hour regardless of whether or not it was used, AWS Lambda was provisioned instantly, on demand, and was billed only\u00a0per request. Lambda is astonishingly cheap: $0.0000002 per request plus $0.00001667 per gigabyte-second of compute. And while users have to increase their server size if they hit a capacity constraint on EC2, Lambda will scale more or less infinitely to accommodate load — without any manual intervention. And, if an EC2 instance goes down, the developer is responsible for diagnosing the problem and getting it back online, whereas if a Lambda dies another Lambda can just take its place.
Although Lambda\u2014and equivalent services like\u00a0Azure Functions\u00a0or\u00a0Google Cloud Functions\u2014is incredibly attractive from a cost and capacity standpoint, the truth is that saving money and preparing for scale are very poor reasons for a startup to adopt a given technology. Few startups fail as a result of spending too much money on servers or from failing to scale to meet customer demand — in fact, optimizing for either of these things is a form of premature scaling, and premature scaling on one or many dimensions (hiring, marketing, sales, product features, and even hierarchy/titles) is the primary cause of death for the vast majority of startups. In other words, prematurely optimizing for cost, scale, or uptime is an anti-pattern.
\n\nWhen people talk about a serverless approach, they don\u2019t just mean taking the code that runs on servers and chopping it up into Lambda functions in order to achieve lower costs and easier scaling. A proper serverless architecture is a radically different way to build a modern software application — a method that has been termed a\u00a0serverless, service-full\u00a0approach.
\nIt starts with the aggressive adoption of off-the-shelf platforms\u2014that is,\u00a0managed services\u2014such as\u00a0AWS Cognito\u00a0or\u00a0Auth0\u00a0(user authentication\u2014sign up and sign in\u2014as-a-service),\u00a0AWS Step Functions\u00a0or\u00a0Azure Logic Apps\u00a0(workflow-orchestration-as-a-service),\u00a0AWS AppSync\u00a0(GraphQL backend-as-a-service), or even more familiar services like\u00a0Stripe.
\nWhereas Lambda-like offerings provide\u00a0functions\u00a0as a service, managed services provide\u00a0functionality\u00a0as a service. The distinction, in other words, is that\u00a0you\u00a0write and maintain the code (e.g., the functions) for serverless compute, whereas\u00a0the provider\u00a0writes and maintains the code for managed services. With managed services, the platform is providing both the functionality\u00a0and\u00a0managing the operational complexity behind it.
\nBy adopting managed services, the vast majority of an application\u2019s \u201ccommodity\u201d functionality\u2014authentication, file storage, API gateway, and more\u2014is handled by the cloud provider\u2019s various off-the-shelf platforms, which are stitched together with a thin layer of your own \u2018glue\u2019 code. The glue code — along with the remaining business logic that makes your application unique — runs on ultra-cheap, infinitely-scalable Lambda (or equivalent) infrastructure, thereby eliminating the need for servers altogether. Small engineering teams like ours are using it to build incredibly powerful, easily-maintainable applications in an architecture that yields an unprecedented, sustainable development velocity as the application gets more complex.
\nThere is a trade-off to adopting the serverless, service-full philosophy. Building a radically serverless application requires taking an enormous hit to short term development velocity, since it is often much, much quicker to build a \u201cservice\u201d than it is to use one of AWS\u2019s off-the-shelf. When developers are considering a service like Stripe, \u201cbuild vs buy\u201d isn\u2019t even a question\u2014it is unequivocally faster to use Stripe\u2019s payment service than it is to build a payment service yourself. More accurately, it is\u00a0faster to understand Stripe\u2019s model for payments than it is to understand and build a proprietary model for payments\u2014a testament both to the complexity of the payment space and to the intuitive service that Stripe has developed.
\nBut for developers dealing with something like authentication (Cognito or Auth0) or workflow orchestration (AWS Step Functions or Azure Logic Apps), it is generally\u00a0slower\u00a0to understand and implement the provider\u2019s model for a service than it is to implement the functionality within the application\u2019s codebase (either by writing it from scratch or by using an open source library). By choosing to use a managed service, developers are deliberately choosing to go slower in the short term\u2014a tough pill for a startup to swallow. Many, understandably, choose to go fast now and roll their own.
\n\nThe problem with this approach comes back to an old axiom in software development: \u201ccode isn\u2019t an asset\u2014code is debt.\u201d Code requires an entry on both sides of the accounting equation. It is an asset that enables companies to deliver value to the customer, but it also requires maintenance that has to be accounted for and distributed over time. All things equal, startups want the smallest codebase possible (provided, of course, that developers aren\u2019t taking this too far and writing clever but unreadable code). Less code means less surface area to maintain, and also means less surface area for new engineers to grasp during ramp-up.
\nHerein lies the magic of using managed services. Startups get the beneficial use of the provider\u2019s code as an asset without holding that code debt on their \u201ctechnical balance sheet.\u201d Instead, the code sits on\u00a0the provider\u2019s\u00a0balance sheet, and the provider\u2019s engineers are tasked with maintaining, improving, and documenting that code. In other words, startups get code that is\u00a0self-maintaining, self-improving,\u00a0and\u00a0self-documenting\u2014the equivalent of hiring a first-rate engineering team dedicated to a non-core part of the codebase\u2014for free. Or, more accurately, at a predictable per-use cost. Contrast this with using a managed service like Cognito or Auth0. On day one, perhaps it doesn\u2019t have all of the features on a startup\u2019s wish list. The difference is that the provider has a team of engineers and product managers whose sole task is to ship improvements to this service day in and day out.\u00a0Their exciting core product is another company’s would-be redheaded stepchild.
\nIf there is a single unifying principle amongst a startup\u2019s engineering team, it should be to write as little code\u2014and be responsible for as few non-core services\u2014as humanly possible. By adopting this philosophy, a startup can build a platform that can process billions of transactions at an extremely predictable, purely-variable cost with nearly zero devops oversight.
\nBeing this lazy takes a surprising amount of discipline. Getting good at managing a serverless codebase and serverless infrastructure is nontrivial. It means building extensive practices around testing and automation, which means an even larger upfront time investment. Integrating with a managed service can be unbelievably painful, with days spent trying to understand all of the gaps, gotchas, and edge cases. The temptation to implement a proprietary solution can be incredible, especially when it means a story can be done in a matter of minutes or hours instead of days or longer.
\nIt means writing wonky workarounds when a service only accommodates 80% of a developer’s needs. And as the missing 20% of functionality is released, it means refactoring code to remove the workaround, even when it is working just fine and there is no near-term benefit to changing it. The substantial early time investment means that a serverless/managed-service-first approach is not right for every startup. The most important question to ask is,\u00a0over what time scale do we need to be fast?\u00a0If the answer is days or weeks, as is the case for many very early-stage startups, it is probably not the right approach.
\nBut if the timescale for velocity optimization has shifted from\u00a0days or weeks\u00a0to\u00a0months or years, it is worth taking a close look at going serverless.
\n\nRecruiting great engineers is extraordinarily hard\u2014and only getting harder. It is a tremendous competitive advantage to task those engineers with building differentiated business functionality while your competitors build services that do commoditized, undifferentiated heavy lifting, and then remain stuck with the maintenance of those services for years to come. Of course, there are certain cases where serverless just doesn\u2019t make sense, but those are disappearing at a rapid rate (for example, Lambda\u2019s 5-minute timeout was recently tripled to 15 minutes)\u2014and reasons such as lock-in or latency are\u00a0generally nonsense\u00a0or\u00a0a thing of the past.
\nUltimately, the job of a software startup\u2014and therefore the job of the founder\u2014is to deliver customer value above and beyond the capability of the competition. That job comes down to maximizing development velocity, which, in turn, comes down to mitigating complexity wherever possible. It may be that every codebase, and therefore every startup, is destined to become \u201ca big ball of mud\u201d\u2014the term coined in a\u00a01997 paper\u00a0to describe the \u201chaphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle\u201d that every software project seems eventually destined to become.
\nOne day, complexity will grow past a breaking point and development velocity will begin to decline irreversibly, and so the ultimate job of the founder is to push that day off as long as humanly possible. The best way to do that is to keep your ball of mud to the minimum possible size\u2014 serverless is the most powerful tool ever developed to do exactly that.
\n![\"Event](\"https://techcrunch.com/wp-content/uploads/2026/02/FoundersSummit-2026_Logos_founderSummit_logo_horiz_color-blk-01.png\"){kind=logo}
\n\t\t\t\t