Software for every team in the company

IT's job is to decide where a tool can live, who publishes, how it's backed up and how it's switched off. When Veodar builds for another department, IT is part of that decision from the scope, not in a “it's live now” email the day before.

The business team describes the process with a real case. IT says which system can be touched and which can't. Development happens inside that frame. If the order is reversed, the department opens a side corner and IT inherits it the day it fails, with no procedure and no owner.

The handover includes what IT needs to avoid adopting a mystery: repository, variables, how it's deployed and how it's rolled back. Without that, the project isn't delivered, even if the screen works on the laptop of whoever built it. The code stays in the company's name so IT can hand it to another team a year from now.

Security can't review what isn't written down. Every automation and every new access goes on a list: what data it sees, which credential it uses, who confirms, where the log is and how it's switched off. That list is the condition for switching the workflow on.

Passwords don't travel in project documents or in prompt examples. Permission is the minimum for the task. If the task grows, the permission is discussed again. Nobody takes advantage of already having the ERP key from the previous task.

When in doubt between going faster and being able to explain the workflow in an internal audit, we choose being able to explain it. A demo that can't be accounted for afterwards isn't a delivery. If the data is about people, the sentence “what the model never sees” is written before testing.

The close hurts where someone copies a number from one system to another and prays not to change a digit. The tool goes after that copy-and-paste: where the figure comes from, who can correct it and what gets locked when the period closes. Where the number comes from is the job. The chart is a consequence.

We don't build an executive dashboard if the number underneath is still manual. Before that, the dashboard is decoration on top of a fragile spreadsheet. When the figure is born in the process, the dashboard makes sense and can be discussed.

Seeing a margin, exporting a ledger or reopening a period aren't interface details. They're in the scope with role names. “Finance can access everything” isn't a permission: it's how a sales rep ends up seeing a cost on a screen nobody reviewed.

People teams lose the day to onboarding, missing documents and the same answer about vacation or equipment. That can be prepared: a list of what's missing, a draft, an alert to the manager. The difficult conversation isn't automated. The reminder that a document is missing is.

Personal data is the easiest to handle carelessly and the least forgiving. The workflow states what it sees, what it never sees and how long a draft is kept. If that can't be said, it isn't built. A model run on employee files “to see what comes out” is not an acceptable experiment.

The people team uses the tool, not some generic company inbox. The first release is one specific onboarding step or document, actually used. The map of every HR process is a slide deck.

From lead to renewal there are stages sales already names and the CRM doesn't force anyone to respect. The tool uses those words. When a deal skips a step, it leaves a trail: who skipped it and what data was missing. Without that trail, next week's forecast is argued with opinions.

Sales reps see their own accounts. They don't see the margin if their role doesn't allow it, not on mobile and not “because the screen was small and the control didn't fit”. The permission is the same in every format. Shrinking the interface is no excuse for showing too much.

We don't replace the CRM for sport. If the CRM already stores the deal, the tool enforces the step the CRM leaves open and writes back. If the CRM won't let us write that step, the scope says so and we don't promise a magic funnel.

Legal hurts when, months later, someone has to rebuild which version was sent and who said yes. Moving faster can't erase that trail. If the workflow can't be accounted for afterwards, it isn't delivered, even if the team saved an afternoon.

The job isn't a generic “legal portal”. It's the deadline, the version and the acceptance inside the tool the department is already going to use: the client portal, the document a workflow produces, the report someone signs on their phone. Legal says what has to be on record. It doesn't wait to find out once the dispute is already open.

That trail is the same one IT and security ask for, for another reason. A list of what was accepted, when and in which version serves both an audit and a disagreement. Building two parallel logs is how they end up contradicting each other.

Web, desktop, mobile or an AI automation aren't four ways of saying the same thing. The department arrives with the process. Veodar names the format: a portal if there are accounts and data another system reads tomorrow; desktop if the station, the file or the device doesn't fit in a tab; mobile if someone has to record work standing up; AI if the task already exists and a person or a rule can confirm.

Mixing them into one “transformation” scope is how nobody signs and the budget can't be discussed. You can start with a single team. One process actually used teaches more than a map of every department. Access and the production list are designed the same way from that first one, so the second doesn't open another side corner.