Getting started: why we founded an infrastructure-first software company

This is the first post on the blog of ProCat Solutions Kft. We are a micro-company in Budapest, a team of a few people, and we build software. That is hardly remarkable in itself: there are hundreds of similar companies in the city. Where we want to differ is in the approach: we do not start from a feature list, we start from the infrastructure the system will actually run on in production.

Why not “feature-first”?

Over the past few years we have watched several projects up close that started fast and looked impressive, and then, at the first serious load or the first security incident, turned out to have no foundations. The symptoms are familiar:

• a single server running everything, with no backups,
• API keys in the source code, with no authorisation layer,
• a database nobody indexed, because it was fast enough on the developer’s laptop,
• deployment by hand over SSH, on a Friday afternoon.

These are not exotic mistakes. They follow from building a system that “works when I press the button” instead of one that “works when a thousand people press the button at once and a disk dies in the middle”.

We think about it the other way round. First we clarify where the system will run, what load it has to survive, what happens when something fails, how a new version gets deployed, and who has access to the data. Features are built on top of that. This does not mean we over-engineer every project; it means we make those decisions deliberately, rather than later, under pressure.

What do we mean by infrastructure-first development?

A few concrete principles we follow in every project:

Production-ready architecture from day one. The development environment runs in Docker exactly like production. The same Nginx configuration, the same environment variables, the same PostgreSQL version. That way “works on my machine” never gets a chance to happen.

A secure API structure. We design every API as if it were public: authentication, authorisation, input validation, rate limiting. That saves the work later, when an internal API suddenly becomes an API exposed to partners.

High availability. Not every project needs multi-zone redundancy, but every project needs automatic backups, health checks, restart on failure, and a documented recovery procedure.

Infrastructure we run ourselves. We work on VPS instances and dedicated servers, on Linux, Docker and Nginx. This is not a rejection of cloud providers, it is a deliberate choice: most of our clients need predictable costs and full control, not a bill that scales in minutes but is hard to reason about.

Which technologies do we work with?

Our stack is deliberately narrow. On the backend, Node.js (NestJS and Express) and Laravel, PostgreSQL as the database, Redis for caching and queueing. Docker for containerisation, Nginx as a reverse proxy, Linux underneath. On the frontend and mobile side, React, Angular and React Native.

We did not pick these technologies because they are fashionable, but because we have known their failure modes for years. We can responsibly put a technology into a production system only if we know how it behaves under memory pressure, what it does when the database connection drops, and how to upgrade it safely.

We are also interested in the telecom world (SIP, VoIP, PSTN integration), and we keep an eye on what is happening in blockchain and machine learning, but we will write about those once we have real experience behind them.

What will this blog be about?

Not product announcements and not press releases. We want to write about what we learn along the way:

• concrete architectural decisions and their consequences,
• mistakes we made, and that others should not have to,
• operational experience: monitoring, backups, load testing,
• new areas we move into, where we document the first steps.

The audience is developers like us, and decision-makers who want to understand what is going on under the hood of their system. We will try to be specific: if a solution did not work out for us, we will write that down too.

What comes next?

In the first few months we plan to write about designing high-load REST APIs and about multi-tenant SaaS architectures, because those are the areas where most of our work is right now. If you want to weigh in on any of these topics, or you are working on a similar problem, you can reach us at info@procats.hu.

Thanks for reading the first post. The next one will already have code and configuration in it.