The demo never shows this part. A vibe coding tool generates a slick “Connect your Google Calendar” button in one prompt, and it looks finished. What the demo skips is everything between clicking that button and the calendar actually syncing: a developer application registered in a provider console, OAuth credentials configured, redirect URIs set, and in some cases a domain verification step that has nothing to do with your app’s logic and everything to do with proving you own the domain you’re building on.
This is the part of vibe coding that has no prompt. You can’t describe your way past it, because the provider (Google, Slack, Stripe, whoever) requires the same registration steps from a solo builder that it requires from an engineering team.
What “connect your calendar” actually requires
For an integration like Google Calendar, there’s no API key you can just paste into a settings field. The generated code needs a real, registered identity with the provider before it can ask anyone to authorize anything. In practice that means:
- Create a developer application in the provider’s console (Google Cloud Console, Slack’s app dashboard, the Stripe developer portal).
- Configure OAuth credentials for that application: a client ID and secret that identify your app to the provider.
- Set redirect URIs that match exactly where the provider should send the user back after they authorize, down to the protocol and trailing slash.
- Clear domain verification, where the provider requires proof you control the domain the app runs on before it will hand out production-level access.
- Select and request scopes, the specific permissions the app is asking for, which get reviewed (sometimes by the provider, sometimes just by whoever is building the app in a hurry).
None of this is app logic. It’s account administration on someone else’s platform, and it has to be done correctly before a single calendar event can show up in the generated UI.
Two ways to get scopes wrong, both bad
Scopes are where this stops being merely tedious and starts being risky. Get them wrong in either direction and the failure looks completely different.
Too many scopes is the security failure. Requesting full Drive access when the feature only needed read-only Calendar events isn’t a shortcut, it’s a standing liability: every file in that account is now reachable through a credential the app didn’t need to touch. It sits there quietly until the day a token leaks or a session gets compromised, at which point the blast radius is the full scope grant, not the feature that was actually built. This is the same shape of problem as the 45% of AI-generated code carrying OWASP-class vulnerabilities: the code runs fine and demos perfectly while the exposure sits underneath, invisible until something goes wrong.
Too few scopes is the silent-failure mode. Miss a single required scope and the integration doesn’t throw a clear error; it just stops working in a way that’s hard to diagnose. A calendar sync that returns nothing, a Slack notification that never sends, a Stripe webhook that fires but the handler can’t read the field it needs. A non-technical builder staring at a blank result has no way to know whether the bug is in the generated code, the scope configuration, or the provider’s side, and the AI can’t inspect the OAuth grant to tell them.
Getting the scope list exactly right, and re-checking it every time the feature set changes, is a specific, narrow skill. It isn’t covered by “describe what you want” prompting, because the AI generating the integration code doesn’t control what the provider’s console will actually authorize.
Where the credentials end up living
Once the OAuth dance works, the client ID, secret, and any resulting access tokens have to live somewhere. That “somewhere” is a real architectural decision, not a detail. Testing the integration locally means the app needs environment variables pointing at real credentials, and non-technical builders who don’t know how to manage .env files properly routinely hardcode those values directly into the code instead. Hardcoded secrets get pushed to a public GitHub repository by accident often enough that it’s a documented, named failure mode of the whole category, not a rare mistake. Once a secret is in a public repo’s history, rotating it and confirming nothing exploited the window is its own cleanup job on top of the integration you were trying to ship.
Plumbing, not product
This is worth naming for what it is: infrastructure work, not the feature you were trying to build. Nobody wakes up wanting to configure a redirect URI. The business need was “show the client’s upcoming meetings” or “notify the team in Slack when a deal closes.” The OAuth console, the scope list, and the credential storage are the unavoidable cost of getting there on a platform where every integration is built from scratch, and they scale with the number of third-party services the app touches, not with how polished the feature looks.
This is exactly the lane where a platform like Softr is the right tool for the job rather than a workaround. Its native connectors for Google Calendar, HubSpot, Stripe, and similar business tools are pre-verified, already-approved OAuth applications: a builder authorizes their account in a login flow, and the scopes and credential storage are handled server-side, off the client entirely, because Softr already did the console registration once for everyone. But for a client portal or internal tool whose job is mostly “sync a calendar and post to Slack,” the integration tax is the kind of plumbing that’s cheaper to buy as platform infrastructure than to reinvent per project.
That trade stops making sense the moment the integration itself is the product. If you’re wiring up a provider nobody has a connector for, or you need control over the token refresh and error handling, you want to own the OAuth flow rather than inherit someone else’s. That’s developer work, and it belongs in developer tools: Cursor inside a real codebase where you can read what the credentials actually do, or Replit where the environment variables and secrets management are first-class rather than something you bolt on after the fact. Neither removes the console registration, because nothing does. They just put you in a position to get the scopes right deliberately instead of discovering them by trial and error.
The fix loop makes this worse over time, not better. Every scope adjustment or new integration is another round of console configuration, another redirect URI to get exactly right, and another chance to over-grant or under-grant. It’s a cost that compounds with each feature added, which is precisely the shape of the Day Two problem: the app that demoed cleanly on day one keeps generating new plumbing work every time it grows.