Build
Build an internal web app that runs the work your team repeats
Your team keeps a process alive by hand: one spreadsheet, three exports and a Monday morning of copying. Tell AgentCode what that process looks like in plain language, and the agent writes an internal web app that runs it for you.
You describe the work · the agent writes the code · your team reviews before anything goes live
In short
An internal web app is a small piece of software that only your company uses: a form, a queue, a dashboard or a checklist that replaces a shared spreadsheet. On AgentCode you get one by describing the job in a conversation. The agent asks what the current process looks like, writes the code, runs the tests and hands the result back for a person to approve. The app lives in your company workspace, the team signs in, and the code stays yours to read and change.
What the agent builds for you
- A form your team fills in instead of a shared spreadsheet
- A queue that shows what is waiting, who owns it and since when
- A dashboard with the numbers your managers ask for every week
- Rules that catch a missing field before the record is saved
- An import that reads the exports you already download from other systems
- A weekly export or email that lands where your process needs it
A process from Finance
The problem
The revenue report is stitched together every Monday from three exports, and once a month somebody pastes a column into the wrong row.
What the agent builds
The agent builds a web app where the three exports are uploaded, matched on invoice number and compared with the previous month. Rows that do not reconcile are flagged before anything is published.
What you end up with
Finance opens the app, uploads three files and reads a report that is already checked. The code sits in your repository, so the next change is another conversation.
From one sentence to a working app
The starting point is a sentence a person from the department can write: the revenue report takes a morning every Monday and the numbers come from three exports. Nothing more technical than that is needed to begin.
- The agent asks what the current process looks like, which files arrive and who signs off.
- It writes a short plan in plain language: the screens, the fields, the rules and what stays out of scope.
- You correct the plan in the same conversation, because a first plan is never quite right.
- The agent writes the code, runs the tests and shows you exactly what changed.
- A person approves the change, and the app is live in your workspace for the team to use.
Every later change follows the same path, and the second request is usually smaller: a column added, a rule loosened, a report sent on Friday instead of Monday. The whole loop is described on how it works.
Where the apps live and who uses them
An app built this way is not a file sitting on one laptop. It lands in your company workspace, and the team signs in with a code sent to a work address, opens the app from a list and uses it like any other tool.
- The code is yours: it sits in your repository, readable and open to review by anyone you trust.
- Your data stays on your side, in the systems and the files you already control.
- No change reaches the app until a person approves it. The agent proposes, a human decides.
- Access follows your sign in, so a departing colleague loses the app together with the mailbox.
That matters more with the fifth app than with the first. A department that builds one app usually builds several, and a pile of tools nobody can read becomes a problem of its own. Here each one is plain code with a plain history, and any of them can be changed in the next conversation. Plans and limits are on the pricing page.
Is a web app the right road for this
A web app fits a process that has records, states and people who look at them. If the work already lives in a spreadsheet that several colleagues edit at once, that is the strongest signal of all.
- Pick a web app when the work has a queue, a form, an approval or a report.
- Pick an internal tool when the job is a small helper for one team rather than a process end to end.
- Pick a system integration when both sides already exist and only the copying between them hurts.
- Pick workflow automation when nobody needs a screen and the steps should simply run.
These roads are not walls. Most departments start with one web app, add a connection to the system that feeds it, then a report that goes out on its own. You describe the next piece, the agent builds it, and every piece keeps the same shape.
Questions teams ask
Do we need a developer on the team?
No. The person who knows the process writes the description, and the agent handles the code. A developer is welcome to read what gets written, and many finance and operations teams ask an IT colleague to look over the first app. After that the review usually becomes a formality, because the code follows the same patterns every time.
Who owns the code the agent writes?
You do. The agent works in your repository on GitHub or GitLab, so every file, every change and every test belongs to your company. If you stop paying us, the apps keep running and any developer can pick the code up, because it is ordinary code with tests rather than a locked format.
Can the app read data from the systems we already use?
Yes, through the exports and the interfaces those systems offer. Most teams begin with the files they already download every week, because that path needs nobody else to grant anything first. Where a system offers an interface for reading data, the agent uses it, and the app keeps the same shape either way.
What happens when the process changes?
You open the same conversation and describe the change: a new field, a different approver, another report. The agent reads the existing code, proposes the change, runs the tests and waits for a person to approve it. Old records stay where they are. Changing an app you already use is the normal case here.
More the agent builds
Describe the process, get the app
Start with the spreadsheet that costs your department the most time every week.