Every major shift in how enterprises build software was first validated somewhere smaller. Kubernetes was Google’s internal container orchestration before it became the industry standard. GraphQL was Facebook’s solution to a mobile API problem before it became a pattern. AWS was Amazon’s internal infrastructure platform before it became the cloud. The companies doing the most interesting work today are rarely the largest ones. They are the ones with the tightest constraints — and those constraints are forcing clarity that the enterprise cannot afford to find on its own.
The builders working with no-code platforms, serverless functions, and GraphQL APIs are not building less. They are building differently, under a fundamentally different set of assumptions about what software should cost to create and operate. As a leader, I find these experiments more instructive than most conference talks. What a two-person startup chooses to build on tells you more about the next five years of software than what a large consultancy is recommending today.
But the most durable change I have watched arrive in this period is not a tool at all. It is a discipline — one that finally named something the industry had been struggling to articulate for years. Before we examine the new tools, we need to start there.
The Purpose of SRE Is Not to Keep the System Up. It Is to Monitor Value.
Site Reliability Engineering emerged from Google as a principled answer to a question the industry had been answering badly: who is responsible for what happens to software after it ships? The traditional answer was “Operations” or “DevOps” — a team that kept servers running, responded to alerts, and managed deployments. The problem with this model was that it optimised for the wrong metric. A system can be up, stable, and performing well by every infrastructure measure while delivering zero business value. Alerts based on CPU utilisation and memory pressure do not tell you whether customers can complete a purchase, whether an order is being fulfilled, or whether a payment is processing.
SRE reoriented the discipline around Service Level Objectives — explicit, measurable commitments about the behaviour of a system from the user’s perspective. Not “the database has 99.9% uptime” but “99.5% of checkout requests complete successfully within two seconds.” Not “no alerts are firing” but “the business function this system supports is working at the level we committed to.” This is a different thing entirely, and the difference matters enormously.
The SRE model also introduced the concept of the error budget — the calculated amount of allowable unreliability, derived from the SLO, that a team can spend on risk. If your SLO is 99.9% availability, your error budget is 0.1% of time — approximately 8.7 hours per year. This budget belongs to the team. They can spend it on aggressive releases, on experiments, on migrations. When the budget runs low, the team slows down until it recovers. This transforms reliability from an operations constraint into a shared engineering resource. It eliminates the permanent adversarial tension between the team that wants to ship fast and the team that wants to keep things stable — because they are now the same team, managing the same budget.
SRE bridges development and operations not by merging the teams, but by giving them a shared language rooted in business outcomes. That is a leadership achievement, not a technical one.
Most Software Was CRUD With Business Rules. No-Code Made That Visible.
The honest and uncomfortable truth about a significant portion of enterprise software development is that it was, at its core, a set of forms connected to a database, with business rules applied to the data as it moved between them. Creating a record, reading a record, updating a record, deleting a record — with validations, permissions, and notifications layered on top. This work occupied thousands of engineers for decades. It was not glamorous. Most engineers who did it knew it was not the interesting part of the job.
No-code platforms — Webflow for frontend, Airtable for structured data, Zapier for integration, Bubble for application logic — made this tacit knowledge explicit. They demonstrated that the schema definition, the form design, the workflow configuration, and the permission model could all be expressed through a visual interface by someone without programming expertise, and the result was deployable, maintainable software. Not for every problem. Not for systems at scale. Not for anything requiring custom algorithmic logic. But for a surprisingly large percentage of the software that organisations were spending developer time on.
This is a leadership insight as much as a technical one. If a significant portion of what your engineers are building could be built faster and cheaper by a business analyst with a no-code tool, then the question becomes: what should your engineers be doing with the time this frees up? The organisations that answered this question well redirected engineering capacity toward the genuinely differentiated problems — the custom logic, the performance-critical paths, the integrations that no platform supports, the data models that require real design thinking. The ones that did not answer it well simply used no-code to reduce headcount, which is a much less interesting outcome.
Most of What DevOps Was Managing Was Undifferentiated Heavy Lifting.
Serverless computing — AWS Lambda, Google Cloud Functions, Cloudflare Workers — is built on a deceptively simple premise: you write a function, you deploy it, you pay only for the time it executes. You do not provision servers. You do not manage scaling. You do not configure load balancers. You do not maintain a Kubernetes cluster. The infrastructure exists, but you do not see it, manage it, or pay for it when it is not in use.
For small teams and new startups, serverless eliminated an entire category of work that had no bearing on the quality of the product. Managing infrastructure is not a competitive differentiator for a company whose differentiation is a novel algorithm, a better user experience, or a more efficient business model. The engineering time spent on infrastructure management was a tax on the real work. Serverless is the clearest expression of what the cloud promised but took a decade to fully deliver: compute as a utility, billed like electricity, with zero operational overhead.
The leadership implication is significant. Serverless works best when the architecture matches it — small, single-purpose functions, event-driven invocation, stateless execution. This is not always the right architecture. For long-running computations, high-throughput workloads, or systems requiring persistent connections, serverless has real limitations. The mature position is not “serverless for everything” but “what infrastructure overhead am I carrying that is not contributing to my product, and can serverless eliminate it?” That question is worth asking regularly. Most teams that ask it honestly find the answer is more than they expected.
REST Was Serving the Server’s Mental Model. GraphQL Asked What the Client Actually Needed.
REST APIs, at their most principled, model the server’s resource structure. You have endpoints that represent nouns — /users, /orders, /products — and the client fetches what it needs by calling the appropriate endpoints. In practice, this creates two persistent problems. Over-fetching: the client receives far more data than it needs, because the endpoint returns the full resource regardless of which fields the client will use. Under-fetching: a single screen or component requires data from multiple endpoints, forcing multiple round trips that compound on mobile networks.
Facebook built GraphQL in 2012 to solve a specific version of this problem: the mobile News Feed required data from dozens of different backend systems, and the existing REST APIs were making the app slow and brittle on 3G connections. GraphQL inverted the model. Instead of the server defining what data is available, the client specifies exactly what data it needs in a single declarative query. The server resolves the query against whatever backing data sources it needs. The client gets precisely what it asked for, in a single round trip, regardless of how many underlying systems were involved.
The broader insight is about API design philosophy. REST organises APIs around the server’s data model. GraphQL organises them around the client’s data needs. For applications with diverse clients — a web frontend, a mobile app, a third-party integration, an internal tool — this distinction matters greatly. The same GraphQL endpoint serves all of them without over-fetching or under-fetching, and without the endpoint proliferation that REST-based BFF (Backend for Frontend) patterns require.
GraphQL has real costs: caching becomes more complex, query depth requires careful limiting, and the shift from endpoint-level monitoring to operation-level monitoring requires investment. It is not universally the right choice. But the question it forced the industry to ask — “who should this API be designed for?” — is one that every API team should answer consciously, regardless of which protocol they ultimately choose.
"Constraints don’t limit what you build. They reveal what you were building unnecessarily."
What the New Builders Are Actually Doing
The pattern across SRE, no-code, serverless, and GraphQL is consistent, once you step back far enough to see it. Each of these practices or tools emerged as a response to a specific, well-articulated frustration with existing approaches. Each one forced a question that existing practices had been answering by default, without examination.
SRE asked: what are we actually trying to keep working, and how would we know if it stopped? The answer revealed that most monitoring was measuring infrastructure behaviour, not business outcomes.
No-code asked: does this problem require code to solve it? The answer revealed that a meaningful portion of software development was applying programming skills to problems that did not require them.
Serverless asked: which parts of our infrastructure are genuinely differentiating, and which are a tax on our time? The answer revealed that most teams were managing significant operational overhead that delivered no competitive advantage.
GraphQL asked: whose needs should this API optimise for? The answer revealed that API design had defaulted to the server’s convenience rather than the client’s requirements.
These are not questions that large enterprises typically have the bandwidth or the incentive to ask. The systems are too established, the teams too large, the legacy too deep. The questions get asked by small teams with no legacy to protect, building products from scratch with tight time and resource constraints. They choose the tools that let them move fastest with the fewest people. When those choices converge — when multiple teams independently make the same unusual decision — it is a signal worth paying attention to.
Watch the Experiments at the Edge. That Is Where the Next Five Years Are Being Written.
The most useful thing a technical leader can do with the patterns described in this article is not to adopt them wholesale. It is to use them as a diagnostic tool. SRE asks: are you monitoring business value or infrastructure health? No-code asks: what percentage of your engineering time is spent on problems that do not require engineering? Serverless asks: what infrastructure are you maintaining that could be managed by a platform? GraphQL asks: are your APIs designed for the people calling them?
None of these questions have universal answers. They have answers that are specific to your context, your team, your product, and your stage. But the questions themselves are worth asking, and the new builders — the small startups running experiments with tight constraints and fresh eyes — are the people who forced the industry to ask them.
Pay attention to what the best small teams are choosing to build on. Not because you should copy their decisions, but because their constraints reveal what is genuinely necessary in yours.
Four Questions Worth Asking This Quarter
Are your SLOs tracking business outcomes or system metrics? If your on-call team is woken up by a CPU alert but not by a 20% increase in checkout abandonment, your monitoring is optimising for the wrong thing. The shift to business-outcome SLOs is not a technical change — it is a decision about what the engineering team is accountable for. Make that decision explicitly.
What in your backlog is genuinely a programming problem? Walk through your team’s upcoming work and ask honestly: which of these items require code because the problem is complex, and which require code because code is the only tool available? For the latter category, is there a no-code or low-code alternative that would free engineering time for the former?
Where is your team managing infrastructure that could be managed by a platform? This is not a question about wholesale serverless adoption. It is a question about marginal overhead. Every hour spent maintaining infrastructure that AWS, Google Cloud, or Cloudflare would manage for a fraction of the cost is an hour not spent on your product. Find the line.
Who are your APIs designed for? Not in a GraphQL-versus-REST sense — in a consumer experience sense. Have the teams consuming your APIs told you what frustrates them about the interface? Do they over-fetch regularly? Do they make multiple calls for data that conceptually belongs together? These are API design signals, not protocol signals. The protocol you choose matters less than whether you have genuinely listened to the people who depend on what you build.