Vibe coding a real app: Sites, Azure, and the production gap
Decide what must be managed, recoverable, observable, and portable before a fast prototype becomes a public service.
The interface is only one layer.
Compare the operating promise, not just the speed of the first build. “Azure” here means a managed stack selected for the application—commonly Container Apps, Azure SQL, Blob Storage, Service Bus, managed identity, and Azure Monitor.
Managed build, save, deploy, domains, and access in one workflow.
Provision the application, data, identity, networking, monitoring, and delivery workflow.
Start on Sites when learning speed is the primary constraint.
Public-beta, plan-specific limits apply across Sites and can change.
Choose resources, scaling rules, quotas, and load-test targets.
Use Azure or hybrid when distribution needs a capacity plan.
D1 for structured records and R2 for files through managed bindings.
Azure SQL, Blob Storage, and other stores with explicit configuration.
Sites fits when documented storage behavior matches the consequence of loss.
Saved versions cover the application. Published docs do not describe user-controlled D1 point-in-time restore.
Azure SQL provides automated backups and point-in-time recovery within configured retention.
Move consequential records when a tested restore is a launch requirement.
Published Sites guidance does not offer data-residency selection.
Choose supported regions and configure redundancy appropriate to the workload.
Azure is the stronger fit for contractual location or failover requirements.
Some background services and hosting patterns may not be supported.
Service Bus, Functions, and Container Apps Jobs support queues and workers.
Use an external backend for durable retries, fan-out, and dead-letter handling.
Built-in traffic analytics show visitors and page views.
Application Insights and Azure Monitor can provide logs, metrics, traces, and alerts.
Operational support needs application telemetry, not traffic totals alone.
Low infrastructure overhead; fewer exposed controls.
Greater control, cost, configuration, security, and incident responsibility.
Do not buy cloud complexity without a named requirement and owner.
This is an operating-model comparison, not a blanket platform ranking. Capabilities and account availability change; verify material requirements in the linked official documentation.
A working screen is not yet an operating system
Vibe coding can compress the path from idea to useful software. It does not remove the work of deciding who owns data, what happens during failure, how access is enforced, how incidents are noticed, or how the product is recovered.
The prompt should specify operational requirements alongside routes and interactions. Name expected traffic, sensitive data, retention, deletion, support ownership, recovery objectives, integrations, and the consequences of downtime.
A form app can accept a submission in a demo while still lacking tenant isolation, duplicate protection, delivery retries, data export, a tested restore path, and an owner for failed notifications.
Treating a successful click-through or attractive preview as evidence that the application is ready for wide distribution.
Classify each component by consequence
Separate presentation, identity, transactions, systems of record, background work, files, analytics, and administration. They do not all need the same host or reliability model.
Ask what happens if each component is unavailable, duplicated, corrupted, exposed, or deleted. The most consequential answer—not the fastest component to build—should drive the architecture.
A public guide may live entirely on Sites. A subscription product can keep its public and administrative interfaces on Sites while placing customer records, billing state, APIs, queues, and backups in Azure.
Choosing one platform for every component only because the first version was convenient to create there.
Understand what Sites manages—and what it does not promise
Current official documentation describes managed production deployments, saved versions, access settings, hosted environment values, D1 relational data, R2 file storage, custom domains, and basic traffic analytics. This removes a great deal of setup work.
Sites is also in public beta. OpenAI says plan-specific limits apply across all Sites and can change; reaching a limit can affect storage or whether a high-usage Site remains public. The published documentation does not state a user-controlled D1 backup, point-in-time restore, regional failover, data-residency option, throughput commitment, or Sites-specific availability SLA. A saved application version is not a database backup.
A campaign site, interactive explainer, internal tracker, or early product can be an excellent Sites fit when its data consequence and operating expectations match the documented product.
Assuming that globally reachable pages prove that the database is active-active across regions, or that version history can restore deleted customer records.
Understand the Azure trade
An Azure application can combine Container Apps for the API, Azure SQL for relational data, Blob Storage for exports and files, Service Bus for durable background work, managed identity for service access, and Azure Monitor or Application Insights for operations.
These services provide explicit controls and documented recovery features, but Azure does not operate the product for you. Your team still owns configuration, permissions, network boundaries, cost controls, database design, deployment safety, alerts, incident response, retention, and restore testing. More control creates more obligations.
A hybrid form product can serve its interface from Sites, call a Container Apps API, store authoritative submissions in Azure SQL, queue email and webhooks in Service Bus, and retain recovery exports in Blob Storage.
Listing cloud services in a diagram without defining recovery objectives, access boundaries, retry behavior, alerts, or a person who responds when they fail.
Choose Sites, Azure, or hybrid by the failure you can accept
Choose Sites-first when speed, managed publishing, and conversational iteration matter most and the application can operate within beta limits and documented capabilities. Choose Azure-first when customer data, contractual expectations, regional control, private networking, recovery, or operational telemetry are central requirements.
A hybrid is often the strongest transition: Sites preserves interface velocity while a stable API boundary moves consequential state to infrastructure with explicit controls. Keep the domain under independent ownership so either side can change later.
Use Sites for a public knowledge product. Use Azure for a regulated or high-consequence workflow. Use a hybrid for a customer-facing SaaS product whose interface is evolving quickly but whose accounts and records must be recoverable.
Moving a simple publication into a complex cloud stack before it has demand—or keeping a growing system of record in a beta host because migration feels inconvenient.
Design the exit before it is needed
Keep stable account and record identifiers, version the API contract, record schema migrations, provide authenticated export, and make writes idempotent. Put secrets on the server. Own the domain and keep third-party integrations replaceable.
Source-code access is not data portability. A portable application also needs recoverable data, documented configuration, a dependency inventory, a repeatable deployment, and a tested way to move traffic.
A Sites interface calls a runtime through one configurable server URL. Moving the runtime changes configuration instead of every page, while an export-and-import rehearsal proves that records can move too.
Waiting for an outage, platform limit, acquisition review, or compliance request before discovering that data cannot be exported or restored cleanly.
Launch with evidence, not optimism
Test the peak write path, authentication and tenant isolation, repeated requests, third-party retries, timeouts, failed background jobs, alert delivery, backup restoration, privacy deletion, and administrator recovery. Load testing should resemble the real transaction, not only repeated homepage views.
Document the operating model in language a future supporter can use: what is monitored, what wakes someone up, how to roll back code, how to restore data, how to disable a compromised integration, and how to communicate with customers.
A production rehearsal submits at ten times expected peak, repeats the same payment webhook, pauses the email worker, restores yesterday’s database into a clean environment, and verifies that one customer cannot read another customer’s records.
Calling the product production-ready because the build passes, the homepage is fast, and the happy path worked once.