A finance lead builds an invoice-matching tool. Operations connects a form to the CRM. A sales manager creates an account-research workflow. Each one saves hours, so colleagues begin to depend on it.
Then the builder leaves, a credential expires, or a vendor changes an API. Nobody knows which process stopped, what data it touched, or who should fix it. Cheap creation has quietly produced an expensive operating problem.
Executive summary
- Tines launched 3B on July 28 to build, run, and govern employee-created apps, agents, and automations in one environment. It calls unmanaged proliferation "wild code."
- The business bottleneck is moving from creation to operation: ownership, access, reliability, cost, support, and retirement.
- Do not force every experiment through enterprise delivery. Classify software by blast radius, then increase controls as usage and business dependency grow.
- Every shared tool needs a discoverable record, accountable owner, controlled runtime identity, cost visibility, and a fallback.
- The opportunity is a safer path from employee idea to dependable internal product—not a ban on employee building.
What changed: software supply expanded inside the business
Workflow company Tines introduced Tines 3B as a secure environment for apps, agents, and automations created across an organization. The product promises authorized connectors, protected credentials, isolated execution, full logging, and one place to see what is running.
Tines says its own employees put more than 500 builds live in three weeks. Treat that as a vendor-reported example, not an industry benchmark. The important signal is the shape of the problem: the number of people who can create working software is growing faster than the team traditionally responsible for operating it.
This is not entirely new. Low-code platforms have faced the same lifecycle problem for years. Microsoft's Power Platform governance guidance tells organizations to inventory apps and flows, assign valid owners, quarantine non-compliant resources, and clean up abandoned ones. Easier generation increases the volume and speed; it does not remove those responsibilities.
Why founders should care
Internal software often begins outside the roadmap because the business problem is real and the central team is busy. That can be healthy. The person closest to the work can test a solution before the company funds a larger build.
Risk appears when an experiment becomes infrastructure without a deliberate decision. An invoice workflow can gain payment access. A customer tool can retain personal data. A sales automation can send messages under a shared identity. A small script can become the only path through a daily operation.
NIST's guidance on software asset management is blunt about the underlying risk: unmanaged or unauthorized software gives attackers another platform inside the network. Founders should add a second concern—unknown software also creates unknown operational dependency.
Govern by blast radius, not by who built it
A personal prototype and a workflow that approves refunds should not face the same process. Use three levels:
- Experiment. One builder, test data, no production actions, and a short expiry date. Optimize for learning.
- Team tool. Several users, approved data, controlled connectors, a named owner, basic monitoring, and a monthly cost limit.
- Business-critical product. Customer, financial, regulated, or core operational impact. Require a co-owner, least-privilege service identity, testing, change review, incident alerts, recovery steps, and an engineering support decision.
Promotion between levels is the control point. When usage, data sensitivity, or business dependency grows, the software must graduate—or stop. This keeps governance proportional while making hidden criticality visible.
Give every shared build an operating record
Before an internal tool is shared, capture a minimum record that a business leader can understand:
- Purpose: the outcome it produces and the manual process it replaces.
- Ownership: one accountable owner and, for critical tools, a second owner.
- Reach: users, systems, data, and actions it can take.
- Runtime: where it runs, which service identity it uses, and where logs and alerts go.
- Economics: monthly platform, model, API, and support cost compared with hours or errors removed.
- Continuity: last review date, manual fallback, and conditions for promotion or retirement.
Never run a shared process on the maker's personal password. A dedicated runtime identity makes access review, offboarding, and incident containment possible. If the platform cannot separate builder access from runtime access, it is not ready for a critical workflow.
A practical 30-day control plan
- Discover. Ask teams what they have built, then compare the answers with automation platforms, integrations, service accounts, API usage, and recurring software spend.
- Classify. Score each item by data sensitivity, action authority, number of users, financial impact, and recoverability.
- Stabilize. Fix the highest-risk gaps first: personal credentials, absent owners, unlimited spend, missing logs, and no manual fallback.
- Create a paved path. Offer approved connectors, secret storage, templates, logging, and a lightweight review so employees have a faster safe option.
- Review outcomes. Track hours saved, cycle time, errors avoided, active users, cost per run, incidents, orphaned tools, and retired duplication.
Start with the highest business dependency, not the largest tool count. Ten forgotten experiments matter less than one unowned workflow that moves money.
The two failure modes
The first is unrestricted creation. It produces duplicated tools, hidden data flows, surprise bills, and software nobody can repair.
The second is a central approval queue for every idea. Employees route around it because the business problem still exists. Governance becomes theatre while the real work moves further out of view.
A better model combines freedom to experiment with explicit graduation. Let teams prove value cheaply. Increase engineering, security, and operational controls when the tool earns wider reach or greater authority.
The opportunity: turn useful experiments into internal products
A visible portfolio shows where employees repeatedly compensate for broken processes. Several similar tools may signal that the company needs one dependable internal product. High adoption can reveal where custom software creates a real operating advantage.
That is the strategic upside of governance. It does more than reduce risk. It gives founders evidence about which workflows deserve automation, which should be redesigned, and which employee-built prototype is ready for product engineering.
Make ownership scale with creation
Tines' launch gives a new name to an old operating truth: software does not become safe because it was easy to make.
Inventory what runs, govern it by blast radius, separate runtime access from the builder, and give critical workflows accountable owners and fallbacks. The goal is not to stop teams from building. It is to ensure the best experiments can become dependable parts of the business.