Thirty Minutes, Five Roles, Live: What a Real Build on GCP Actually Teaches
The abstract for this talk promises a live build from zero to deployed in thirty minutes: a feedback app spanning five roles and the full software lifecycle, built with Claude on Google Cloud, using subagents, MCP servers, and custom skills, with the finished app available to test at the end of the session. I want to take that framing further, because the value of a talk like this is not the app. The app is a vehicle. The real lesson is the assembly pattern.
I have done builds in this shape, not on a stage and not in thirty minutes, but the same architecture, the same Claude as orchestrator, the same subagent breakdown, the same MCP-driven cloud integration. The reason these talks are worth watching is that they compress months of trial and error into a sequence you can see and copy. The reason they are worth writing about is that the lessons generalize to any non-trivial app you want to build, on any cloud.
Three things to take away
- The work that lets a thirty-minute build succeed happens before the timer starts. The CLAUDE.md, the skills, the MCP servers, and the architecture decisions are not improvised on stage.
- Subagents are the difference between Claude as a coder and Claude as a team. Five roles need five contexts, not one.
- MCP is the layer that turns "Claude plus a cloud" from a slide deck into a workflow. The cloud-specific integration code shrinks dramatically once MCP carries the connection.
The work before the timer
Live builds make for good demos because the audience feels the pressure. They are also misleading if you treat the live part as the work. Thirty minutes is not the build. Thirty minutes is the execution of a build that was designed in advance.
The presenter arrives with a CLAUDE.md that names the project, sets the constraints, and points to the conventions. They arrive with a set of skills already written: one for scaffolding a service, one for setting up the database, one for wiring up the deploy. They arrive with MCP servers configured for the GCP services they are going to use. They arrive with a plan that breaks the app into roles and assigns each role to a subagent. They have rehearsed the path.
This is not cheating. It is the same preparation any serious engineer does before a focused work session. The talk's value is in seeing what that preparation looks like, because the live part is the part you can already imagine. What you cannot easily imagine, until you see it, is which decisions are made upstream of the timer.
When you watch, pay close attention to the first two minutes. The presenter will reveal more about the setup than they probably realize. The shape of the CLAUDE.md. The names of the skills. The list of MCP servers. The way the plan is structured. Those are the artifacts to copy, not the prompts that follow.
Five roles, five contexts
A feedback app spanning five roles is a feedback app with at least five distinct slices of work: a data model, an authentication and authorization layer, a backend API, a frontend, and the integrations to whatever notification or persistence services it touches. Five roles can also mean five user personas in the app itself, with different views and permissions, which adds another layer of work.
You could build that in one Claude session. You can also try to write a novel in one breath. Both are physically possible and neither is a good idea.
The right architecture is subagents. One subagent handles the data model, with its own context focused on schemas and constraints. One handles the API, focused on endpoints and validation. One handles the UI, focused on components and flows. One handles the integrations, focused on the cloud services and external APIs. One handles deployment, focused on the build pipeline and runtime config.
Each subagent has its own context, which means it does not get polluted by the others' details. Each one has its own permissions, which means it cannot accidentally write outside its lane. Each one is summoned by the orchestrator, given a scope, and returns a result. The orchestrator stitches the results.
This is the closest a single developer gets to having a team. It is also the architectural pattern that makes the thirty-minute build feasible. You do not type faster. You parallelize.
MCP as the cloud integration layer
The other piece of the architecture that earns its place is MCP. Before MCP, integrating Claude with a cloud platform meant writing client libraries and gluing them into your app. You wrote the code that talked to Cloud Run, the code that talked to Firestore, the code that talked to IAM. Each integration was a small project.
With MCP, the integration is configuration, not code. You point Claude at a GCP MCP server. Claude can then talk to GCP services through the server, without you writing the glue. The deploy command becomes a tool call. The database query becomes a tool call. The IAM update becomes a tool call. The integration code that used to live in your app lives in the MCP server, maintained by someone else.
The effect on a live build is dramatic. Most of the time that used to go into wiring up the cloud goes away. The talk likely demonstrates this by deploying something with a single prompt that, behind the scenes, calls a build, pushes an image, configures Cloud Run, and returns a URL. That whole flow used to be a chapter in a textbook. It is now a tool call.
For your own work, the question is which MCP servers exist for the platforms you use, which ones you have configured, and which integrations you are still doing by hand because you have not adopted the MCP server yet. If you build on GCP and you do not have the official MCP server configured, that is your first install. If you build on AWS or Azure, the equivalent question applies. The integrations you do by hand today will be MCP tool calls in a year.
The skills layer
The third piece is skills. A skill is a procedure encoded as a directory the model can find and use. For a build like this, skills compress the repeating parts of the work into one-line invocations.
The presenter probably has a skill for scaffolding a new service: it creates the directory layout, the package config, the linter, the test setup. They probably have a skill for adding a database: it picks the right managed service, creates the connection, sets up the migration tooling. They probably have a skill for deploying a service: it builds the image, pushes it, configures the runtime, returns the URL.
Each skill is something that, without the skill, would take a few minutes of prompting and a few opportunities for the model to drift. With the skill, it is one invocation. The model executes the procedure as written, with the consistency the skill enforces, and returns the result. The compression is not just time. It is reliability. The skill always does the procedure the same way.
The lesson here is that skills are how you institutionalize what you have already figured out. Anything you do more than twice in Claude Code should be a skill. The first time you do it, you are learning the procedure. The second time, you are noticing the procedure. The third time, you are wasting your own attention. Write the skill.
What thirty minutes does not include
The honest framing in any live build is what you do not get in thirty minutes. The presenter will probably acknowledge it, because the talk is more credible when they do.
Thirty minutes does not get you a security review. The auth flow runs, but it has not been audited. The permissions are configured, but they have not been red-teamed. The secrets are stored, but the rotation policy is missing. None of that fits in the timer.
Thirty minutes does not get you accessibility. The UI works, but it has not been screen-reader tested. The contrast is probably fine because the defaults are reasonable, but no one checked. The keyboard navigation may or may not work. That is a separate pass.
Thirty minutes does not get you load testing. The app works for one user. It probably works for ten. Whether it works for ten thousand is unknown, because no one tried.
Thirty minutes does not get you observability beyond the defaults. Logs go to Cloud Logging. Errors probably surface. But the alerting, the dashboards, the SLOs, the on-call playbooks, none of that is in scope.
Thirty minutes does not get you real user testing. The app is shippable, but it has not been validated against actual users with actual needs. The five roles in the app are personas in the presenter's head, not personas confirmed by research.
The honest framing is that thirty minutes gets you a working starting point. It does not get you a production-ready system. The gap between the two is the work that comes next, and the talk's value is in showing the starting point so the gap becomes a planning conversation instead of a guessing game.
The shape transfers
If you build on GCP, treat the talk as a reference. Copy the CLAUDE.md shape. Copy the skill list. Copy the MCP server choices. Use the architecture as a starting template for your own next build.
If you build on AWS or Azure, the shape transfers. Subagents, MCP servers, and skills are platform-agnostic. The specific GCP services have analogues in every cloud. The pattern is the lesson, not the vendor.
If you do not build infrastructure at all, the talk is still worth your time. Watching a multi-role application assembled live is the fastest way to update your intuition about what a small team can ship in an afternoon. That intuition is the input to every product decision you make for the rest of the year. Teams that have the right intuition ship more, try more, and learn faster than teams stuck on the old assumptions about how long things take.
That update is the real takeaway. The app is the demo. The shape is the lesson. The intuition is the product.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: Building with Claude on Google Cloud at Code with Claude London 2026. https://youtu.be/l8fxVYIP4HQ