Software intelligence

Technology is not a creed

It is a choice of tools. And that should fit the problem better than the developer’s favourite opinion.

We don’t choose technologies by what sounds good at conferences at the moment, but by what can be built cleanly for a task, operated and developed further later.

California / Human-computer interaction

Douglas Engelbart

„SRI Douglas Engelbart 1968“ by SRI International, 1968

Source: Wikimedia Commons · Licence: CC BY-SA 3.0 · Image credits

Editing: Changes: cut out, enlarged. The edited version is under the same licence, CC BY-SA 3.0. Edited by Today is Life.

Douglas Engelbart wasn’t interested in simply making computers faster. His question was bigger: how can computers help people think better and work together? In 1968, in a legendary presentation, he showed things that then seemed almost like science fiction: mouse control, hypertext, windows, shared document editing and video conferencing. For Engelbart, the decisive thing was never the individual tool. What mattered was whether technology extends people’s abilities. A pretty good rule for AI: the most impressive tool doesn’t win. The one that people actually work better with does.

Douglas Engelbart (1925–2013) US computer scientist, inventor and computing pioneer

The stack is not the message

You can get astonishingly religious about technologies.

Then a programming language becomes an identity, a framework a worldview and every architecture decision almost a question of character. I consider that unhelpful.

In the end, companies don’t buy an ideology. They need software that does its job, withstands their processes and doesn’t fall apart as soon as the first new requirement appears.

That is exactly why we choose technology pragmatically. Not arbitrarily. But pragmatically.

We are interested in what lets us solve a problem cleanly. What a team can master well. What will still be maintainable in three years. What fits existing systems. And what stays sensible when a nice idea eventually becomes a real product with real users, real data and real consequences.

That is usually less glamorous than tech debates on the internet. In projects, though, it is almost always the better choice.

Backend

The backend is often where it is decided whether a system only looks pretty or really runs in operation. Data comes together there, and so do business logic, permissions, integrations and the parts of the system that nobody sees later but everybody feels.

Here we deliberately work with technologies that have proven themselves in real projects. They are not new, but reliable, easy to understand and sensible to use in practice. Depending on the task, we turn to classic web stacks, to more API-driven architectures or to Python where data, automation or AI really belong.

Backend technologies

PHP

Still a very sensible choice for many web applications: mature, widely applicable and, in good hands, much better than its reputation.

Laravel

Our preferred PHP framework for applications where productivity, clarity and maintainability should come together.

Symfony

Strong when projects demand more structure, more individuality or very specific architecture decisions.

Yii2

Still makes sense for certain existing and performance projects, especially when speed and clear structures are called for.

Python

Makes sense where data processing, automation, AI or analytical logic move more into the centre.

Node.js

Practical for event-driven services, integrations and applications where JavaScript or TypeScript also makes sense on the server side.

Rust

Interesting for services where performance, security and clean control over resources are especially important.

Frontend

In the frontend, software becomes directly tangible. That is where you quickly notice whether a system works with people or against them.

That is why we are interested here not only in what looks modern but in what makes interaction clearer, what connects cleanly to the backend and what can be maintained in the long term. Not every application needs the same complexity. Sometimes a reactive framework is right, sometimes a lighter tool is perfectly enough. Here too: the tool follows the task.

Frontend technologies

Vue.js

For us often a good middle path between clarity, speed and pleasant development in productive frontends.

React

A good choice when projects need more freedom or existing ecosystems and teams are already strongly oriented towards it.

HTMX

Helpful when interactivity can sensibly be solved straight from the HTML and you deliberately want less JavaScript complexity.

Alpine.js

Helpful for lighter interactions in server-rendered applications when a large frontend framework would simply be too much.

Tailwind CSS

Practical when you want to build interfaces systematically and consistently without getting lost in growing CSS chaos.