AI’s impact on COMMpla’s internal processes

In a tech company, most of the energy in the room goes towards clients. Solutions to build, projects to deliver, deadlines to hit. And rightly so, because that is the business, and it is the business we are good at.
But every so often, someone on the team says something like: wouldn’t it be great if we had a tool that did this internally? A dashboard that gave us a clearer picture. A checker that caught the small things before they became bigger ones. Something that would make our own working life easier, save an hour ahere, catch a mistake there. The idea is usually good. The answer, almost always, is the same: yes, but we do not have the bandwidth right now.

It is not a bad answer. It is a realistic one. Client work comes first, and for a long time internal tooling was held to the same standard as anything shipped externally: clean architecture, proper testing, long term maintainability, careful documentation. That is a great deal of overhead to justify for something only your own team will ever touch, and so those ideas tend to stay exactly where they started, as ideas.

Why internal tools do not need to play by the same rules

This is where AI has quietly changed the equation at COMMpla.

Internal tools simply do not need production grade polish. Nobody outside the company is ever going to review the codebase of a dashboard built to check hosting resource usage. What actually matters is the outcome: does it work, does it save time, does it show the team what it needs to see, when it needs to see it. Speed and usefulness win over elegance, and that has always been true, but it took AI assisted development to make it practical.

AI assisted development fits that brief almost perfectly. It lowers the cost of building something quick and slightly rough that still does its job well. There is no need to over engineer a tool whose only purpose is to make an internal process faster, clearer, or less manual. A script that automates a repetitive check does not need the same rigour as a client facing platform, and treating it as if it did was, in hindsight, one of the main reasons so many good ideas never left the drawing board.
That shift in mindset, more than any single tool or piece of software, is the real story here. Once the team accepted that good enough was, in fact, good enough for internal use, a lot of small projects that had been discussed for months suddenly became achievable in days.

In practice, most of this work has been what people are now calling vibe coding. Someone describes what they want in plain language, works with an AI assistant to sketch out a first version, tests it, nudges it in the right direction, and keeps going until it does the job. There is no upfront specification, no formal review process, and often very little planning beyond a rough sense of what the tool should show or automate. For a client project that approach would raise eyebrows, and rightly so. For an internal dashboard or checker, it is exactly the right amount of process, which is to say, barely any.
Vibe coding works so well for these internal projects precisely because the stakes are different. If the KPI dashboard has a rough edge or the accessibility checker misses an unusual edge case, the team notices, mentions it, and the tool gets nudged again in a follow up session. Nobody is waiting on a formal bug report or a release cycle. That fast, conversational way of building is also what makes it possible for people who are not full time developers to put together something useful on their own, simply by describing the problem and iterating on what the AI produces until it clicks.

What has come out of it so far

A number of ideas that had been floating around internally for a while finally got built once the barrier to entry dropped. None of them required a dedicated project plan or a sprint of their own. They were built around existing work, in the gaps, because building them had become fast enough to fit there. A few examples worth mentioning are as follows.

• A social media KPI monitoring dashboard, giving a clear, immediate view of how the pages the team manages are performing, without having to dig through separate platforms one by one, log in and out of different accounts, or manually compile numbers into a spreadsheet before every review.
• A hosting resources dashboard, tracking the health and load of the instances the team manages, so that potential issues surface early and can be addressed before they turn into problems the client actually notices.
• An accessibility checker for the websites the team develops, running quick automated checks that flag common accessibility issues at an early stage, rather than catching them much later in the process, when fixing them is slower and more expensive.

None of these are groundbreaking pieces of software, and they were never meant to be. That is rather the point. They are small, focused tools that solve a real and specific annoyance, built quickly, without ceremony, and they exist now largely because building them stopped being a luxury the team could not afford.

The real shift 

The most interesting change here is not technical, it is cultural. Ideas that used to live in the nice to have, one day pile are now realistic short term projects that someone can pick up between other tasks. Monitoring across the board is more accurate. Information moves between teams far more easily than it used to. Processes that once required manual checking, scattered spreadsheets, or someone simply remembering to look at something, now have a single, simple point of reference that anyone on the team can check.
None of this replaces the client facing work that keeps the business running, and it was never meant to. What it does mean is that the gap between wondering wouldn’t it be great if and actually saying we built it has become a great deal smaller. For a tech company, that is a genuinely useful place to be, and quite possibly one of the more understated benefits of adopting AI in day to day work.

Emanuel Marzini | Chief Information Officer