AI automation for IT companies instead of another internal project
You could build every one of these integrations yourselves, and you would probably build them better. That is not the problem. Every hour your team spends on internal tooling is an hour nobody invoices. What you buy from us is somebody else's working week and a tested skeleton, not knowledge you are missing.
- 14 daysto the first working automation, counted from the end of the workshop
- EUR 3,500 netper week of workshop, a published price you can hold against your own hourly rate
- 5.55 pointshow much margin rose year over year in our founders' own agency after the AI agent went in. The caveats on that number are further down this page
The problem
Why does a company that automates for others not automate for itself?
Not for lack of skill. An internal tool has no client chasing a deadline, so it always loses to work somebody ordered and will pay for. An hour of a senior developer spent on your own timesheet script costs exactly what you bill that hour for, it simply never shows up in the accounts as a loss.
The damage lands in places nobody planned for. Tickets arrive through five channels at once: email, a direct message on the client's Slack, Jira, a phone call and a form on your site. The Slack ticket exists in no report, so when the budget overrun conversation happens there is nothing to defend it with.
Month end adds the rest. Hours have to be collected out of Jira, ClickUp and a spreadsheet, turned into invoice lines per client and per type of work, and for a client in Germany or the UK you add the exchange rate and the reverse charge. Structured e-invoicing is being rolled out across the European Union, so that path has to be machine readable rather than a spreadsheet somebody keeps up to date.
- A ticket from a direct message on the client's Slack reaches no report
- The hours and overrun report per project is stitched together by hand after the month closes
- A new developer asks for context from people who are on their own deadline
- An internal tool has one author and no owner once that author leaves
Why now
What changed, so this is worth taking off your own team?
Not the interfaces. Jira, GitHub, Slack and billing systems had APIs long before anyone called this automation, and you know that better than we do. The layer above them changed: a language model reads project documentation, ticket history and task system data at once, and answers in a sentence with the source attached. A rule will not do that, because a rule moves values around and does not read context.
The second change is cost. The skeleton of a rollout like this, meaning the ticket queue, the classification, the data access layer and the supervision over what the agent does without a person, is already written and already running in production. You do not start from an empty repository, you start from something that works and add your own knowledge of your stack. Collection runs through n8n, Make or a direct API call, and the numbers land in BigQuery or in a database you already run.
The third is arithmetic. At the rates you bill an hour at, a week of internal work has a price you know to the last euro. The workshop costs EUR 3,500 net per week, so the comparison takes a minute and does not require believing any promise.
What changes
What stops eating your team's hours?
One queue instead of five channels
Tickets from email, the client's Slack, Jira, the form and the phone land in one place. Classification and priority are set on arrival, from the content of the ticket and from the contract with that client.
Priority set the moment a ticket arrives, not at the morning stand-up
The agent answers from project documentation
Questions about architecture, technical decisions and ticket history get an answer in 5 to 10 seconds. Every answer carries a pointer to the document or the ticket it came from.
An answer with its source, so it can be checked in 30 seconds
Hours and overruns are visible while the work runs
Logged hours against the estimate and the project budget are counted every day. An overrun shows up mid sprint, while there is still something to discuss with the client.
A daily figure instead of a report assembled after the month closes
Invoice data ready on the day the sprint closes
Hours from the task system turn into lines per client, project and type of work, with the exchange rate for currency billing. Accounting gets a finished set rather than an invitation to go and collect data.
The invoice basis on the day the sprint closes, not after three days of collecting
A new hire ramps up without blocking the team
A developer joining a project asks the agent for context instead of catching people between tasks. Knowledge of architectural decisions stops walking out of the company together with a contract.
Project context available at ten in the evening, with no waiting for a free slot
Repeat tickets surface on their own
The system groups similar tickets and shows which ones come back often enough to be worth writing up once. The knowledge base stops being the task nobody ever sits down to.
A list of topics to write up, with the number of occurrences on each
Proof
Do you use this yourselves?
Yes, and it is the only proof we can show without asking a client for permission to publish their numbers. We show the one closest to your own work: an AI agent in production at our founders' agency, which runs its own development team. Launched in March 2026, built with the method described above. Below is half a year of measurement, together with what those numbers do NOT prove.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency of around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
The agent is wired into Google Ads, Meta, the CRM, the task system, the SEO tool, Analytics, Search Console and the data warehouse. First commit 1 March 2026, 23 people use it today.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- In the twelve months before launch the agency ran on a margin of minus 4.42 percent. Across a twenty month window there was not a single run of three positive months.
- After
- May, June and July 2026 were three positive months in a row, the first such run in the whole window. Revenue barely moved, so the change sits on the cost of delivery, not on sales.
Margin up 5.55 percentage points year over year, on revenue up 1.5 percent
Operations run by the agency agent in consecutive months of 2026, from the first commit in March. From 83 operations in March to almost 63,000 in August, with users growing from 4 to 23. This curve is here because a rollout nobody uses looks exactly like a successful one in a report.
Measurement: Agent invocation log in the data warehouse, March to August 2026, counted at the level of a single tool call.
Of 64,903 operations run in the last thirty days, 29,854 went through with no person involved: monitoring client sites, feeding the warehouse, reviewing ad accounts, catching enquiries from forms. The rest is work somebody asked for and accepted. We give both numbers, because autonomy without supervision is a risk, not a feature.
Measurement: Agent audit log, the 30 days before 2 September 2026, split by whether an invocation had a human session attached.
And in your company
We could build this ourselves, so why you?
Four sentences come up in software houses more often than any others. The first one is the hardest, so we answer it the way we would answer it in the room.
We have a team that will build this itself.
It will, and it knows your stack better than we do. The question is whether you want to give a week of senior time to it, when that week could have gone on a client project. What you buy from us is somebody else's working week and a tested skeleton, not secret knowledge. If you have spare capacity and the process written down, you will do it cheaper yourselves and we will say so plainly.
Some of this is already covered by our internal scripts.
Then we start with an inventory rather than with writing from scratch. Usually one piece of glue is missing: a shared ticket queue, or a layer that reads data from three systems at once. We add the missing part and leave your scripts where they already work.
The client has their own Jira and their own Slack, we cannot give you access.
We do not need access to the client's systems to start. We work on your side: a ticket that lands in your inbox or on your channel goes into your queue. The scope of access is agreed in the workshop and written down before the start.
Our project code and documentation are under NDA.
We work on your infrastructure or on a cloud you nominate, and the scope of data is agreed before the first connection. The agent can read documentation and tickets with no sight of the repository, if that is what you decide. Every invocation leaves a trace in the log, so an audit has something to work with.
- Project management
- Jira, ClickUp, Asana, Linear, Azure DevOps
- Code and deployments
- GitHub, GitLab, CI/CD pipelines, production monitoring
- Tickets and communication
- Slack, Microsoft Teams, shared inbox, website form
- Documentation and teamwork
- Confluence, Notion, Google Workspace, Microsoft 365
- Sales and billing
- HubSpot, Pipedrive, Toggl, Harvest, Xero, e-invoicing systems
- Data and automation layer
- BigQuery, SQL databases, Google Sheets, n8n, Make, custom API integrations
What exactly we take off a software house team
A typical split of administrative work in an IT company before a rollout and after it.
| Area | Today | After the rollout |
|---|---|---|
| Client tickets | email, the client's Slack, Jira, phone, form | one queue with classification and priority |
| Questions about project status | a developer stops work and writes back | the agent answers from the task system and ticket history |
| Hours per project | timesheet filled in on Friday from memory | hours collected from the tools, overruns visible while the work runs |
| Invoice data | collected from three tools after the month closes | ready on the day the sprint closes, with the exchange rate |
| Onboarding a developer | questions to people who have their own deadline | the agent answers from documentation, with the source |
| Knowledge base | written when somebody happens to find the time | a list of repeat tickets with the number of occurrences |
| Client report | the PM assembles it by hand before the meeting | generated from project data, the PM only comments |
The scope of the first rollout is agreed in the workshop. We take the three lines with the highest return, counted in team hours, not all of them at once.
How we work
Five steps from an internal backlog to a working process
Every step ends with something you can judge by code or by a number before you decide on the next one.
Workshop
One week. We walk a ticket from arrival, through the estimate and the team's work, to a line on the invoice. We come out with a map and a list of the places where the same information gets produced twice.
Picking three automations
From the map we pick the three with the highest return and count them in team hours, not in percentages. Before the start we write down what those activities cost you today, so that after thirty days there is something to compare against.
Building the first one
Fourteen days to a working solution. In IT companies we usually start with the single ticket queue, because that is what stops pulling developers out of their work fastest.
Handover to your team
Workflows, integrations and documentation land in your repository. Your team changes them without coming back to us, and with a client who writes software themselves that is the whole difference.
Measurement and the next one
After thirty and ninety days we check the indicators agreed in the workshop. Only then do we decide whether we take another area or you carry on with it alone.
Before and after
How the week of a team and a PM changes
Before
- A ticket from a direct message drops out of the process and out of the billing
- Friday goes on filling in timesheets from memory
- A project budget overrun becomes visible after the month closes
- A new hire takes a week to get going, because the context sits in other people's heads
After
- Every ticket has a number, a priority and an owner, whatever channel it arrived through
- Hours collect themselves from the tools, and Friday goes back to project work
- An overrun shows up mid sprint, so there is still something to discuss with the client
- A new hire asks the agent and gets an answer with the source attached
What your team can do does not change. What changes is how many of its hours go on work nobody will ever invoice.
For the owner and the CTO
What the person signing this off gets
The first thing is arithmetic, which is why it is easy to defend. A week of senior time spent on an internal tool has a price you know to the last euro, because you sell that same hour to a client at that rate. The workshop costs EUR 3,500 net per week, and that is the whole return conversation, with no slides.
The second is quieter, and it matters more in front of an investor or in an audit at an enterprise client. Project profitability after three sprints stops being one PM's knowledge and becomes a number in a system, one you can show and defend.
- Team hours stay on client projects instead of on your own backlog
- The rollout is run by somebody outside, so it does not compete with client deadlines
- Workflows and documentation stay with you, with the right to change them without asking us
- Profitability per project and per sprint as a number, not as a PM's impression
What it costs
The workshop price is published, the rollout price comes after it
The workshop costs EUR 3,500 net per week and we publish it before any call, because a company that sells its own hours wants to compare it against its own rate straight away. We quote the rollout after the workshop, once we know how many systems we connect to and what state they are in.
Language model and tool cost, meaning n8n, Make or the cloud, goes to the vendor directly. When everything runs on your own infrastructure you do not pay for it at all. The model cost sits in the range of EUR 0.005 to 0.07 per query depending on the model. No commission from us in either case.
Process workshop
EUR 3,500 net
per week, in a software house usually one to two
A self-contained piece of work. It ends with a process map and a 30 day plan your team can execute without us.
- A week of work inside your processes and your tools
- A map of a ticket from arrival to a line on the invoice
- Three automations with the highest return, counted in team hours
- The indicators to measure after 30 and 90 days
- Most popular
Workshop and first rollout
Quoted after the workshop
scope follows from the number of systems and the state of the data
For a company that would rather buy somebody else's working week than pull a senior off a client project.
- Everything in the workshop
- The first automation running within 14 days
- Connections to the task system, the repository, Slack and billing
- Handover of workflows and documentation into your repository
- Measurement after 30 and 90 days
AI agent for a software house
Quoted after the workshop
for teams where project questions come up a dozen times a day
Everything in the rollout plus BOND, the company AI agent answering from project data in 5 to 10 seconds.
- Everything in the rollout
- An agent answering from project documentation and ticket history, with the source
- Alerts on hours and project budget overruns
- Detection of repeat tickets for the knowledge base
- Access for the team, the PMs and the board
If the workshop shows that you have spare capacity in the team and the process written down, we will say plainly that you will do it cheaper yourselves, and leave you the plan to do it with. The workshop ends with a document that stands up without us.
Frequently asked questions
Why would a software house hire an automation company when it sells automation itself?
Because what you are short of is not skill, it is a spare working week. An internal tool has no client chasing a deadline, so it always loses to work somebody will pay for. We add the time and a tested skeleton, your team adds knowledge of its own stack and maintains it afterwards without us.
When is it NOT worth hiring us?
When you have spare capacity in the team and the process written down. Then you will do it cheaper yourselves, because you are not paying for somebody else's working week and you would write the skeleton your own way anyway. We say this in the workshop, or already on the free consultation, rather than selling a rollout that has no way of paying for itself.
What is an AI agent for an IT company?
It is an agent that reads project documentation, ticket history and data from the task system, and answers questions in a plain sentence in 5 to 10 seconds, pointing at the source of every answer. Ours is called BOND, and a rollout of an agent like that takes around two months. It does not replace the task system, it removes the need to click through it to establish anything.
Do we have to change Jira or our task system?
No. We read the data through the interface and leave the tools where they are, ClickUp, Linear or Azure DevOps included, if some of your projects are tracked elsewhere. Migrating a task system is a quarter-long project, and the first automation is meant to exist fourteen days after the workshop ends.
Where does the agent get its answers and can they be checked?
From your data: documentation, tickets, the task system and billing. Every answer carries a pointer to the document or the ticket it used, so verification takes a few dozen seconds. Invocations stay in the audit log, so you can also see how much the agent did with no person involved.
What about access to code and documentation under NDA?
We work on your infrastructure or on a cloud you nominate, and the scope of data is agreed and written down before the first connection. The agent can work on documentation and tickets alone, with no sight of the repository, if that is what you decide. Every invocation leaves a trace in the log.
Does this help with e-invoicing and with tracking hours per project?
Yes, and that is usually the fastest return. Hours from the task system turn into invoice lines per client, project and type of work, with the exchange rate for billing in euro or pounds. Structured e-invoicing is being introduced across the European Union, so this flow has to be machine readable rather than a spreadsheet, whichever way you go about it.
How long from signing to the first effect?
A week of workshop and fourteen days to the first rollout, counted from the end of it. We measure the effect after thirty and ninety days, on indicators agreed before the start, so that nobody judges it on impressions. We run at most two rollouts at a time, so the start date can be a few weeks out.
Let us count this in your team's hours
The free consultation takes 30 minutes. We walk one of your processes, usually a ticket from arrival to a line on the invoice, and tell you how many team hours it eats today. If it turns out you will do it cheaper yourselves, we say so straight away. You write directly to Paweł, with no reception and no ticket in a system.
We run at most two rollouts at a time, so that someone is actually sitting on each of them.
Book a free consultationPS. If somebody at your company put a client task aside this week to add something to an internal script, that is exactly the cost. What you buy from us is not knowledge you are missing, it is a working week you do not have to take out of a project.