Companies used to buy their software. Now the people who work there are building it themselves.

With AI, people across every function are building real software, shaped to the exact job they need it for. But it’s landing on personal accounts and laptops, invisible to the company that depends on it. Every company is now deciding who owns and controls all of it, whether it means to or not.

0:00 / 0:00
A brief tour of Remy’s enterprise management systems.

Employees are now building the company’s software.

For most of its history, a company’s software came from outside. Packaged products and SaaS subscriptions: around fifty of them for a typical mid-market company, each one someone else’s software, licensed and administered by IT. That was what “the company’s software” meant: things it bought.

That’s changing fast. The people who do the work are building the tools they need themselves, by describing them to an AI agent and getting a working application back. The software a company runs on is shifting from what it licenses to what it creates.

Built in-house217apps
  • FinanceMonth-end reconciliation
  • OpsAsset tracker
  • HROnboarding portal
  • SalesPipeline CRM
  • SupportEscalation tracker
  • LegalContract intake
  • ProcurementVendor queue
  • DataKPI dashboard
  • and 209 more

This software lives outside the company’s control.

Look at where the built software actually lives right now. A weekend project no one quite finished. A database whose schema was designed by someone learning SQL as they went. A script that only runs on one laptop, on the day the report is due. Each piece tied to whoever happened to build it.

And none of the usual moves apply: the tools built to corral unsanctioned software assume a vendor on the other end. Here there’s no domain to block, no license to revoke, no vendor to call. It stays invisible until it breaks, and then no one knows where it runs or what it’s wired to.

Running software is harder than building it.

There’s a reason so much of it is half-finished. Building the tool is the easy part now. Everything after it is not.

Once the tool exists, it needs somewhere to run, and running it takes a different kind of work: unrelated to the problem the person set out to solve, and often unfamiliar to them entirely. That gap is where things stall, get abandoned, or end up pushed onto a personal account and held together with tape. Someone still has to do that work. Increasingly, it falls to people who never signed up for it, which is how a whole workforce has quietly been drafted into IT.

Build the MVPmain@3f9a1c · deployed

All this software needs a foundation the company owns.

Software a company depends on has to run on something the company controls. That was always true. It’s just that the something used to come from a vendor, or from an engineering team building on infrastructure IT already ran. The workforce-built world has neither. It needs a layer of its own, the same way vendor software and engineering builds already have one.

The shape of that layer is simple to state: a single foundation every built application runs on, owned and governed from its first line of code. Not a review step someone has to pass before shipping, since those get skipped or slow the work down. The app is on the company’s infrastructure because that’s where it was built. There’s no separate step where it moves from somewhere else to somewhere owned.

A shared foundation removes setup work and adds visibility.

For the person building

Sign-in, databases, hosting, domains, storage, email, and the services other tools need to talk to are already handled. The work is describing the app; the foundation runs it.

For the organization

That same setup is what makes every app arrive already accounted for: identity and access, audit and compliance, isolation and backups, in place from the first line of code. None of it configured by hand, and none of it depending on whoever built the app to have thought about any of it.

Setup, handled
for the person building
Sign-in
Databases
Hosting & CDN
Domains & TLS
File storage
Email delivery
1,000+ integrations
Everything accounted for
for the organization
Identity & Access
Directory SSO / SAMLSAML 2.0
Scoped API keys
Role-based access
Per-person model access
Monthly spend limits
Isolation & Data
Per-tenant isolation
Encryption at rest
Data residencyUS · EU · CA · AU
Encrypted backups
Audit & Compliance
Immutable audit trailOCSF
Security assessment
Pre-filled CAIQ
SOC 2Type 1 & 2
GDPR
Observability
Live logs
Error tracking
Performance metrics
Instant rollback
One foundation · owned from the first line of code

The result is a software estate the company owns.

Put every app on one foundation, each with a spec describing what it does and why, and the scatter becomes something the company can hold. A landfill of half-known projects turns into an estate it can see across at the level of intent: what each tool is for, who built it, what it touches, without anyone reading the code. Apps improve across the whole portfolio at once. And the valuable ones outlive whoever made them: when that person moves on, the tool keeps running, and someone else picks it up from the spec.

And this applies to what already exists, too. An application exported from a coding agent, a site built on Replit, a folder of files running off one laptop: none of it needs a migration project to join the estate. It just needs a real place to run, a sign-in through the company directory, an audit trail, and a spec describing what it does. The estate isn’t just what gets built from here forward. It’s also everything already built, lifted out of the scatter and onto something the company owns.

Independently audited

  • SOC 2 Type I & II
  • GDPR
  • CCPA
View our Trust Center