How and why we built our own vibe coding app platform for Method employees

Here is a scene from the life of an Engineer.

Engineer: *Working hard on important improvements to the Method product*

Someone smart in marketing: “Hey, Mustafa… quick question.”

Engineer: “What’s up?”

Marketing person: “I have this idea for an internal tool I wonder if you could help build.”

The internal tool is probably very useful. Internal tools often are. But if anyone on the engineering team says yes to the internal tool request, that’s time they are not spending on making the Method product better. In the past, internal tool requests like this at Method often got de-prioritized for that very reason. Sometimes they never got made.

The good news is that there is now a ton of AI technology that can help people (like our marketing team) spin up useful apps without having to loop in engineering. The bad news is that the Engineer can’t just tell everyone to run wild with Claude Code. This is for a couple of reasons.

1. Security is the big one. We can’t have someone hardcoding API keys or sensitive customer data into some ad hoc vibe coded dashboard. Any app we build at Method (even internal) needs to meet the same security and data access standards as our production systems.

2. Context and access. Lots of internal tools are only useful because they have context on what Method is and have access to all sorts of different systems from which they can pull data or take action. A blank slate in an AI tool does not have that.

Our goal was to unlock anyone at Method to build real, useful apps that run inside our infrastructure with the same security protocols as everything else we would deploy. 

So we built Vibe: it’s an AI-powered internal app platform that turns a chat conversation into a useful, production-deployed, secure application.

How people at Method use Vibe

The main way people interface with Vibe is by going to chat.methodfi.dev and describing what you want. Just like you’d do with other AI tools. Someone in sales might ask for a demo app for a really important meeting with a potential customer. Vibe would respond by asking some follow-up questions about branding, functionality, and so on to make sure it had the full context before diving in.

Once criteria are set, Vibe spins up and deploys an app that runs within our own app infrastructure and follows all of our security protocols (more on this in the next section). It usually is as easy as that.

But what if the person isn’t quite happy with what Vibe creates? People can edit their apps in one of two ways. One option is to click on any element in the preview and describe the change (e.g. “make this bigger” or “change this color”). Or they can describe the change they want in the chat. This makes it easy for people to make both aesthetic and functionality changes, even without a technical background.

It’s still early, but people at Method are already building all sorts of real and useful things with Vibe. Demos are one example: Talib, Solutions & Strategy Lead at Method, recently built a polished co-branded demo for a meeting he had in 48 hours. Talib built the entire thing without any engineering support and got it done with plenty of time to spare. As a result, we brought this function in-house, cut vendor spend, and have since produced dozens of demos.

People are also using Vibe for internal automations. Two weeks ago we spun up a snack app that allows team members to select the office snacks that are out of stock for our team to order; the kind of thing that makes life better at Method but would not have been built before.

Mandi Lornson, Executive Assistant: "Building office management tools with Claude has been exciting, but as someone who's not very technical, figuring out where to actually put them so my team could use them was the hard part. Luckily we built Vibe — now I just upload my app on vibe and launch."

Vibe has also built dashboards, prototypes, and more—all things that used to take days or weeks of engineering time in order to create. That was time taken away from important work on the product. Now the people who need them just ask Vibe and go from there.

How Vibe works, and why it’s different than other vibe coding tools

One risk with Method employees building tools on third-party vibe coding platforms, or directly with products like Claude and ChatGPT, is that there are basically no standards for anything. No security standards, no infrastructure standards, nothing. This was a big problem for us.

To fix it, each app Vibe creates lives in its own directory and follows the same security standard:

• Runs as a non-root user

• Has a read-only root filesystem

• Drops all Linux capabilities

• Network-isolated (egress is limited to DNS and external HTTPS only)

• Scanned for critical vulnerabilities (both dependencies and the built container image) 

• If a critical vulnerability is found, deployment is blocked

These controls aren't Vibe-specific — they're Method's existing security posture, applied uniformly across everything we deploy. Critically, AI-generated apps are subject to the same access controls and data handling restrictions as any other internal service: no broad access to sensitive customer data, no shortcuts on secrets management, and no exceptions. The AI can generate code, but our infrastructure and permissioning determine what that code is allowed to access.

Secrets follow the same pattern. Config declares the secret names, but values live in a dedicated secret manager and sync to the cluster automatically. Nothing sensitive ever touches git. Secret scanning also runs on every commit to catch accidental exposure as an additional layer of defense.

Beyond that, every PR gets an automated AI code review that flags issues, followed by manual human approval before anything reaches production. So there are three layers of review before any app goes live: (1) automated scanning, (2) AI-assisted code review, and (3) human sign-off.

As for the infra:

Side note: for approval, every frontend app gets an automatic preview deployment on a temporary subdomain behind our private network when a pull request is open. This lets reviewers see the actual running app before approving. When the PR closes, the preview is automatically cleaned up.

The AI was the easy part

One thing we learned quickly was that the AI was the easy part. I mean, we’re not building foundation models here; hooking up Claude to the workflow is about as simple as calling the API. The real problem to solve here was everything else: deploy pipeline, security, DNS automation.

It was also important to allow previewing before commit. In early iterations, people were committing code directly and only realizing they needed to make changes after the fact. We also learned that good defaults matter more than flexibility for non-technical people. Simplicity lets folks focus on their specific goals for their app and not get caught up in distractions.

The other big piece was to treat the AI as untrusted. When you build internal tools by hand, there’s a tendency to treat the code as trusted because someone on your team wrote them. This can work (and can also cause issues). In AI’s case, well, it’s definitely not a trusted team member. We enforce the same security protocols across all Vibe apps regardless of what the AI generates.

Vibe has already been quite a success at Method. People have built real things. Next, we’d like to:

• Expand language support beyond Node.js/TypeScript

• Add built-in observability (structured logging, metrics dashboards)

• Build controlled app-to-app communication for more complex workflows

• Create deeper integrations with existing internal tooling

We had a ton of fun building this. And we continue to have fun as we add more features. And perhaps more importantly, the people who have been using Vibe have not only had a ton of fun but have generated actual value for Method. Which, ultimately, is the goal.

If you’d like to join the engineering team at Method to build fun things, look at our careers page here or reach out directly.