DEV Community: Arvin Gopi

AI makes building internal tools easy. Leash gives everything your team builds a home: hosted, authenticated, discoverable, and governed. That's why we built https://leash.build

Arvin Gopi — Mon, 18 May 2026 20:07:55 +0000

Arvin Gopi

May 18

Your Company Is About to Build 10x More Internal Tools. Where Will They Live?

#ai #claudecode #cursor #chatgpt

Comments

3 min read

Leash - Deploy any app with built-in auth. One command. | Leash

Deploy apps in seconds with authentication, environment variables, and team sharing built in. Supports Next.js, Flask, Express, Go, Rails, Rust, Java. One command. Instant URL.

leash.build

Your Company Is About to Build 10x More Internal Tools. Where Will They Live?

Arvin Gopi — Mon, 18 May 2026 19:58:08 +0000

AI changed who can build software. Leash makes what they build usable by the company.

The internal tools backlog used to be a queue. A sales team needed a pipeline cleanup dashboard. Finance wanted a variance report. Support needed a triage view. Product wanted a customer research tracker. Everyone waited for engineering time.

AI coding tools changed that. Engineers are moving faster, but they are not the only builders anymore. PMs, designers, ops teams, analysts, and automation owners can now turn a workflow problem into working software in an afternoon.

That is a good thing. It also creates a new problem. The bottleneck is no longer only "can we build it?" The bottleneck is "can the company safely use it?"

The New Internal Tool Sprawl

The dashboard someone built is on a personal Vercel account. The renewal-risk tool is running from a laptop. The onboarding app lives on a free hosting tier. The AI workflow that summarizes customer calls is a notebook only one person knows how to run.

Links are scattered through Slack. Credentials are copied into DMs. Nobody knows which tools exist, who owns them, who can access them, or whether the thing the team started using last week is still running.

AI increases the amount of internal software your company can create. Without a delivery layer, it also increases the amount of internal software your company cannot see.

The Company Needs a Home for What Gets Built

Leash is the internal tool delivery layer for the AI era. It gives every app, workflow, and prototype a standard path from "works on my machine" to "the organization can use this."

Deploy from the CLI or an agent workflow
Get a real HTTPS URL for the tool
Use built-in organization auth and access controls
Show up in a shared catalog where teammates can find it
Resolve secrets, environment variables, identity, and integrations through the platform
Collect feedback where the app actually lives

Builders keep moving quickly. Leaders, platform teams, and IT get a governed surface area instead of a mess of personal accounts and mystery apps.

For Engineers

You built something useful. Leash removes the shipping tax. You do not need to stand up a hosting account, wire auth, ask for a subdomain, copy secrets into a new place, or explain to everyone how to run it locally.

Run leash deploy. The tool gets a URL, auth, access controls, env vars, and a place in the team dashboard.

For Heads of Engineering

Your company is going to create more software than your platform team can manually host, review, and support. The answer is not to block builders. The answer is to give them a paved road.

Leash turns internal-tool delivery into a standard workflow. Builders get autonomy. The organization gets consistency.

For PMs and Designers

You do not have to stop at a spec, a mockup, or a localhost demo. If you understand the workflow pain, you can help turn it into a real tool and put it in front of the people who need it.

Leash makes that tool shareable, authenticated, and easy to find, so the feedback loop happens around something the team can actually use.

For AI Ops and Automation Teams

Agents, scripts, and notebooks become much more valuable when they have a stable place to run and a clear surface for users. Leash turns internal AI workflows into deployed tools with identity, integrations, secrets, and access control handled by the platform.

For Internal Tools and IT Teams

AI-built apps are coming either way. Leash gives them a governed home. You can see what exists, keep access tied to the organization, standardize deployment, and reduce the number of unofficial apps living on personal infrastructure.

Internal tools teams become the platform for builders instead of the bottleneck every team has to wait on.

The Companies That Win Will Not Just Build More

AI makes internal software abundant. The winners will be the companies that make that software usable: easy to deploy, easy to discover, connected to the right systems, and governed by the organization.

That is what Leash is for. Everything your team builds gets a home.

Give every internal tool a home

curl -fsSL https://leash.build/install.sh | sh
leash login
leash deploy

Read the quickstart or explore the Claude Code plugin.

Your .env file should have one line

Arvin Gopi — Sun, 03 May 2026 05:05:18 +0000

Every AI app I've shipped recently rewrote the same plumbing. The OAuth dance for Slack. Encrypted storage for an API key. Refresh-token logic that finally fails on the 3rd call after an hour. Wiring up an MCP client to a server behind a bearer token someone pasted into a Notion page.

I'd write it, copy-paste it into the next app, watch it rot. Each new agent built by a different teammate, slightly differently, with slightly different bugs. We were a small team and the integration code became most of the code.

## The pattern under all of it

Strip away the providers and the AI-specific bits, and every app needed the same four things from the platform:

Env vars — a database URL, a Stripe key, the boring stuff. Not in a .env file in a Docker image. Not in a CI secret. Somewhere the app can ask for at runtime.
Pre-built integrations — Gmail, Calendar, Drive. The user logs in once on the platform; every app gets typed access on their behalf.
Custom OAuth — the providers no platform pre-builds. Slack, Notion, the company's SSO. The customer holds the client_id/secret; their app shouldn't.
Custom MCP — internal MCP servers, third-party MCPs. The customer holds the URL and the bearer token; their app shouldn't.

That's the spine of the SDK we ended up shipping. Four primitives, every app uses some of them, none of them require integration code in the app.

## Register once at the org level

The flip is registration. The org owner registers their things one time on the dashboard:

Drop a Slack client_id + client_secret into the "Custom OAuth providers" card. Encrypted with the org's KMS key. The app never sees it.
Drop the URL of an internal MCP server + a bearer token into the "Custom MCP servers" card. Same treatment.
Connect Doppler / 1Password / GCP Secret Manager as a secret source — or just type secrets into the dashboard.

Now every app you deploy in that org gets typed access through four SDK calls.

## The four calls

  import { LeashIntegrations } from '@leash/sdk/integrations'                                                                                                                                                                                             

  const client = new LeashIntegrations({ apiKey: process.env.LEASH_API_KEY })                                                                                                                                                                             

  // 1. Env var (resolves through your configured secret source)                                                                                                                                                                                          
  const dbUrl = await client.getEnv('DATABASE_URL')                                                                                                                                                                                                       

  // 2. Pre-built integration                                                                                                                                                                                                                             
  const messages = await client.gmail.listMessages({ maxResults: 5 })                                                                                                                                                                                     

  // 3. Custom OAuth — fresh access token for any provider you've registered                                                                                                                                                                              
  const slackToken = await client.getAccessToken('slack')

  // 4. Custom MCP — { url, headers } including bearer Authorization                                                                                                                                                                                    
  const mcp = await client.getCustomMcpConfig('acme-tools')

Same shape across TypeScript, Python, Go, Ruby, Rust, and Java. No client_secret in the app code. No refresh-token handler. No MCP boilerplate.

## Your .env collapses to one line

The thing we noticed only after living with it: once you're using this, the only secret your app's .env actually needs is the platform API key.

  # .env  (yes, this is the whole thing)                                                                                                                                                                                                                  
  LEASH_API_KEY=lsk_live_...

That's it. No more .env.example drift. No more "did we set DATABASE_URL in staging?" debugging at 11pm. Rotation happens at the source — no rebuild, no redeploy.

## What it deliberately doesn't do

A few decisions that came up that I'll defend:

Doesn't proxy MCP traffic. We hand the app {url, headers} (with bearer Authorization already attached) and the app calls the MCP directly. Leash isn't in the request path. Tool calls are on the LLM's critical path; an extra hop hurts. We also
didn't want to reimplement every MCP transport (streamable HTTP, SSE, stdio) with our own bugs.

Doesn't force you to use the platform for secrets. If you'd rather hold them in Doppler or 1Password, point the platform at your existing source. getEnv resolves through whichever the org configured.

Doesn't pretend to be multi-cloud. Single-region GCP today. If you're betting on us, you're betting on a small surface area — not a multi-cloud promise.

## The why behind the shape

Customer apps can't hold credentials safely. Their AI agent runs on someone's laptop, in CI, on a Cloud Run revision someone's about to redeploy. Putting client_secret in the app means rotating it everywhere whenever it leaks. So we put the

credential in one place and gave the app a thin retrieval call instead.

Same logic for MCP. The bearer token for a customer's internal tool server isn't something we want their AI app to know. The app gets a config dictionary right before it calls the MCP. That's as long as the credential lives anywhere near user code.

The four-primitive surface area is small on purpose. Anything else (token caching, retries, pagination on Gmail, etc.) lives in the SDK or in the customer's code, not in the platform contract. We'd rather grow the SDK than the API.

## Try it

  curl -fsSL https://leash.build/install.sh | sh                                                                                                                                                                                                        
  leash login                                                                                                                                                                                                                                             
  leash deploy

Or just sign up at leash.build, register a Slack app or an internal MCP, and call the SDK from any project. Custom OAuth + custom MCP are gated to the Growth plan; built-in integrations work on every plan including free.

Curious what others have done for this. Especially the proxy-vs-config-handoff call for MCP — I made the bet, but it's the architecture choice I'd most welcome a counterargument on.