Skip to content
onagero

Building internal tools without developers: what it really takes

Onagero, editorial team · published on · 6 min read

In short

Specialists can now build internal tools without writing code: with low-code kits, or by describing to AI agents what they need. Building is rarely the problem. The hard parts are data access, permissions and running the tool afterwards. Settle those three first and you get tools that last instead of new shadow IT.

What an internal tool means

An internal tool is a small application for one process in your own company: a list with status, a form with approval, a KPI cockpit, an information page for sales support. Few people use it, but often, and it fits exactly one process that no standard software covers that way. Today that process usually lives in Excel, emails and shouted questions.

Three routes without your own developers

  • Low-code kits such as Retool or Power Apps: screens by clicking, logic in small formulas. Data connections and anything unusual still need technically skilled people. See Onagero or Retool.
  • An agency or a freelancer builds to a brief. Every later change is a new order, and the knowledge about the tool sits outside the company.
  • AI agents that build from a description: the specialist describes in their own words what they need and checks the result. How good it gets depends on access to the right data and on the checks before it goes live.

Why such tools fail

  • Data: access is missing, or nobody knows what a field means. Is “delivery date” the requested one or the confirmed one?
  • Permissions: who may see what? Personal data should be masked before development, see Data masking for AI.
  • Operations: when the ERP changes, the connection breaks. Without an owner, the tool stays broken.
  • Sprawl: many tools without owners are just a new form of spreadsheet chaos.

Rules to set before the first tool

  1. Every tool has a responsible person.
  2. Building happens on a copy, with personal data masked.
  3. Only what a person approves goes live.
  4. Reading is the default. Writing to source systems happens only deliberately and after approval.
  5. Every figure has a traceable origin.
  6. What happens in operation is logged.

How Onagero puts these rules into practice is on the security page.

How to start

With a process that repeats regularly and whose effort you can measure. The pilot check tells you in two minutes whether the conditions are in place. The article Setting up an AI pilot shows what scope, metric and acceptance look like.

This article gives orientation and is not legal or tax advice.

Questions on this topic

Do we still need IT?

Yes, for access, servers and roles. But no longer for every change to a tool.

Does the works council have a say?

In Germany, if a tool is suitable for monitoring the behaviour or performance of employees, the works council has a right of co-determination under § 87(1) no. 6 BetrVG. That applies no matter who builds the tool.

How is a tool different from a chat with ChatGPT?

A chat answers a question once. A tool keeps running: with fixed rules, for several people, on your real data.

Which problem would
your team solve first?

Show us a real process. We will show you how it could look with Onagero.

Book a demo →

Check first whether a pilot fits: fit check in 2 minutes →