Servers first, features second: ProCat Solutions opens for business

One server running everything, with no backups. New versions pushed out by hand over SSH on a Friday afternoon. Over the past few years we have watched several projects work exactly like that, right up to their first serious load or their first security incident. 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, as do hundreds of other firms in the city. The difference is the order of work: we start from the infrastructure the system will actually run on in production, and the feature list comes after.

When the foundations run out

Those projects started fast and looked impressive. The failures were always the same:

• 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.

None of these is an exotic mistake. Each follows from building a system that “works when I press the button”. Nobody designed it to keep working when a thousand people press the button at once and a disk dies in the middle.

We start at the other end. First we settle 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 sit on top of that. It does not mean every project gets over-engineered. It means the decisions are made deliberately and in advance, before circumstances force them.

Four principles

We apply the same ones to every project.

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

A secure API structure. Every API is designed as if it were public: authentication, authorisation, input validation, rate limiting. It pays off the day an internal API suddenly becomes one exposed to partners.

High availability. Not every project needs multi-zone redundancy. Every project does need 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. We have nothing against cloud providers; this is a deliberate choice. Most of our clients need predictable costs and full control. A bill that scales in minutes but is hard to reason about serves them less well.

A narrow stack

Our stack is narrow on purpose. 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.

Fashion had nothing to do with it. We have known the failure modes of these tools for years. We put a technology into a production system only when 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 telecoms (SIP, VoIP, PSTN integration) and we follow developments in blockchain and machine learning. We will write about those once there is real experience behind it.

What goes here

No product announcements, no press releases. We will write about what we learn on the job:

• 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 readers we have in mind are developers doing similar work, and decision-makers who want to understand what is going on under the hood of their system. If a solution did not work for us, we will say so.

Coming up

First up are designing high-load REST APIs and multi-tenant SaaS architectures, because that is where most of our work is right now. Anyone who wants to weigh in, or is working on a similar problem, can reach us at hello@procats.hu.

The next post will have code and configuration in it.