Our own company running on automation.

Situation

A small team has one advantage and one weakness. The advantage is no procedures that serve nobody. The weakness is nobody to handle the boring, repetitive things, because everyone is busy with the urgent ones.

For us it showed up like this: the code was in the repository, but deploying changes was done by hand. Client inquiries sat in the inbox, and who should pick them up was settled in chat. It worked until there were several projects at once.

What we built

Instead of one big system we put up several small bridges between the tools we already use. All of them run on one server and all have their code in the repository, so no change is lost just because someone fixed something on production.

• a bot that posts every merge request as a card on Discord, together with an AI review and approve, merge and deploy-to-test buttons,
• a flow that reads the contact inbox, recognizes a client inquiry and creates a contact and a sales opportunity in the CRM,
• a bridge between the helpdesk and the task system that assigns a ticket to the right project based on its content,
• nightly backups of databases and configuration with a Discord notification when something fails,
• a proposal generator that assembles the document from ready-made blocks instead of rewriting the previous proposal.

How it works day to day

A developer pushes a branch and opens a merge request. Within a minute a card appears in the project channel with a description of the changes and an AI review comment pointing to the places worth a look. Approving and deploying to the test environment are buttons under that card, so nobody needs an open console.

On the other side of the company the same happens with clients. An e-mail from the form goes into the CRM as a contact with a note, and a support ticket creates a task in the project it belongs to. A person adds the decision, not the data entry.

Results

What changed most was response time. A client inquiry doesn't wait for someone to check the inbox, because it's immediately visible where we're already looking. Deploying a fix to the test environment is one click, so the client sees the change the same day, not after the weekend.

The second change is less visible but more important. Since every bot has its code in the repository, fixes survive a server restart and can be rolled back.

What we learned

Automation pays off where something repeats every week and has a clear input and output. Everything else is better left to a person, because the cost of maintaining the automation outweighs the gain.

Second lesson: an automation that quietly stops working is worse than none at all. That's why every one of our flows reports a failure where someone will see it. We set the same requirement in client projects.