PaLoMa was born from a client who asked us for a chatbot and led us to build a product.

KitPusher was born the opposite way: there was no client asking for it. There were us, inside FITEC, losing days every month installing technical software on the PCs of our fleet. At a certain point we decided it was worth building the solution we needed using our own software development skills.

This is the story.

The problem: two hours per user, multiplied by too many users

FITEC’s PC fleet is the fleet of a company that does serious technical consulting. We’re not talking about Office and a browser — we’re talking about complex CAD software (NX, Catia), PLM suites like Teamcenter, simulation tools, client-specific development packages. Heavy software, configured with precision, that requires specific steps to be installed correctly.

The flow we used before KitPusher was this: for every installation we contacted the user, scheduled a remote desktop session, interrupted their work, ran the install, verified it, and gave them back their machine. Average time per single user: about two hours — including coordination, waiting, the actual install and verification.

Two hours per user, on a fleet of technical consultants, multiplied by periodic installations, meant heavy hidden costs. Costs measurable in our person-hours and in users’ burned productivity, forced to stop.

It was a mechanical activity. The kind of mechanical activity that, if you’re still doing it manually in 2024, something’s off.

What was NOT an option

The obvious route would have been adopting one of the enterprise MDM tools out there — Microsoft Intune, SCCM, third-party solutions. Three problems.

The first is trivial: for FITEC itself, internally, we had neither the budget nor the approvals to adopt those solutions. Not because they aren’t good at what they do — because they were oversized for our specific case.

The second is architectural: practically every enterprise software-distribution solution requires installing an agent on the clients. A small service always running that receives commands from the central server. That means opening a compliance analysis, evaluating the attack surface, maintaining a client-side stack, managing the versions of the agent itself. For anyone who knows enterprise ICT: it means work we didn’t have.

The third was recognising what we had in-house. FITEC has deep software development competencies and solid ICT skills. Building was practical — actually, it was our trade.

Hence the decision: agentless from day one. Nothing to install on the clients. Everything orchestrated from a central node that speaks to the PCs with protocols Windows already knows — SMB3, RPC, PsExec — without asking for anything exotic.

The first version: scripts

As often happens, KitPusher’s first version wasn’t a product. It was a collection of scripts. PowerShell, batch, artisan things, accumulated over time by different people at FITEC, each optimised for the specific case in front of them.

They worked. But they lived in a state of constant friction:

  • Hard to maintain. Each script had an original author, an implicit knowledge of how it should be used, edge cases written in comments — when we were lucky.
  • Hard to deploy. Every rollout was a small epic of copying, configuring, testing, “did you update to the right version?”.
  • Technologies that slowed the system down. Some steps were solved with tools that worked but cost performance on the clients during execution. Too many side effects.
  • Approximate audit. When someone asked you “what was installed last month on so-and-so’s PC?”, the answer was approximate and based on scattered logs.

This phase taught us a great deal — not about successes, but about mistakes. Almost everything KitPusher solves as a product today is a problem we lived through first in the script version.

The operational turning point: the Teamcenter + CAD upgrade

The moment that turned KitPusher from “we’re working on a tool” to “this thing is actually needed” was a Teamcenter upgrade with the attached CADs.

It had to be done on every client. It included installing new versions, running configuration scripts, applying environment-specific patches. With the traditional method — user-by-user coordination, remote session by remote session — it would have taken weeks. Not so much for the technical execution, but for the logistics: scheduling, coordinating, contacting again, replanning.

With KitPusher the same thing was managed in a radically different way. Parallel task queue, orchestrated execution, tracking of each step, structured error handling. Weeks became hours. And every operation was logged, verifiable, traceable.

That rollout was the moment we stopped treating KitPusher as “our internal tool” and started thinking of it as a product to offer to third parties.

The audit: the value we didn’t know we’d built

There’s one thing KitPusher does that we hadn’t originally imagined as a killer feature, and that turned out to be the strong point we try to show others.

KitPusher logs everything: who installed what, on which machine for whom, when, with what outcome. Successes, failures, return codes, process outputs. It’s a structured, queryable, complete log.

What use is it to us? Two things, discovered progressively.

Verifying our work to internal management. When someone asks “why did we spend X hours this month on a rollout?”, the answer isn’t an opinion: it’s a table. What was installed, where, when, by whom. No smoke.

Verifying to the client when the rollout is for them. Part of our work is installing and maintaining technical environments on the PCs of the clients we serve. When the rollout ends, we can hand over to the client not just “done” — we can hand over the exhaustive proof of what was done, on which machines, with what outcome. This completely changes the nature of the delivery: the report speaks clearly.

For anyone running ICT in a serious company, this is the point at which an exhaustive audit trail stops being bureaucratic overhead and becomes the product.

From scripts to product: the rewrite

What KitPusher is today is not a polished version of the old scripts. It’s a complete rewrite, the result of years of mistakes and problems lived through first-hand.

The technical choices were driven by what had hurt us:

No agent on the clients, for the reasons of compliance, attack surface and maintenance mentioned above.

Serious encryption for credentials in transit and at rest — AES-256-GCM, key derivation with PBKDF2 at 600,000 iterations — because a tool that handles credentials to install software in privileged mode on dozens of machines cannot afford approximate encryption.

Structured audit log from day one, not as a feature added late on top of something else.

Native parallel push, because sequential execution on a consulting fleet means losing the main advantage before you even start.

On-premise as the default, because the clients we have in mind — industrial, manufacturing, technical companies — often have internal networks where cloud connectivity is limited, managed, or absent by choice.

What we learned

The lesson we’ll carry with us into any future product is just one: building from your own need, lived, repeated, is the surest way to build something useful.

KitPusher is not the result of a product brainstorm in a meeting room. It’s the result of hundreds of remote desktop sessions that gave us headaches. First when we did it manually. Then when we did it with scripts. Then when we realised the problem wasn’t to automate further — it was to change paradigm.

For anyone running ICT in a company and finding themselves in our same situation (technical PC fleet, heavy software, audit requirements, no budget for enterprise MDM), the advice is simple: start from the flow that costs you the most time. Time it. Understand whether the problem is tooling or process. If it’s tooling — and often it is — building a dedicated tool pays for itself quickly. Especially if you have to justify your work to someone who wants to see proof, not stories.

KitPusher exists because we were losing too much time. And because we were in the fortunate position of being able to build the solution we needed. Now we offer it to others too.