
Platform architecture consulting
There comes a moment in the life of almost every platform when the team stops asking itself what to build and starts asking what is holding it back. Decisions have been piling up for years —a queue here, a permissions system that grew on its own, three different ways to deploy— and nobody has the complete map anymore. Every change costs more than the last.
That is when the temptation appears: the big rewrite. Months of budget to rebuild from scratch what works today, hoping that this time it turns out right. Sometimes it is the right answer. Many other times, it is the most expensive way to avoid looking at the problem.
This service exists for that moment: an expert review of the architecture decisions behind your platform, ending with a prioritized evolution plan.
What I review (and what I don't)
This is not a code audit. I am not here to run an expensive linter or to weigh in on test style. I sit down with the big decisions —the ones that cost money to undo— and check whether they hold up:
- Tenancy: is it still a product for one customer or already a platform for several? Logical isolation inside the application, multi-tenancy per deployment, or a mix of both?
- Identity: in-house passwords or delegated to OIDC with Keycloak? How do roles and permissions travel, and where are they actually enforced?
- Queues and workers: which work runs synchronously, which does not, and what happens when something fails at three in the morning.
- Data: the model, the search queries, the migrations nobody wants to touch.
- Deployment and operations: what is versioned, what is automated, how much it costs to spin up a new environment.
- AI: where it truly adds value in the product and where it is a token bill with no return.
The result is not a verdict: it is a decision map —what was decided, in what context, what consequences it has today— and, on top of that, a prioritized plan: what to keep, what to revert, in what order and at what cost. Including the option to not touch anything when that is the right one.
How I work
- Listen before reading. Sessions with technical leadership, product and the team that operates the system. Every decision had a context; judging it without knowing that context is easy and useless.
- Read the real system. Repositories, manifests, pipelines, infrastructure. Not the diagram from the slide deck: what actually runs.
- Map the decisions. Every big decision is recorded with its context, its current state and the options it opens or closes.
- Prioritize. The report orders the moves by impact and cost, and separates the urgent from what can wait —and from what should not be done—.
The review is discussed with the team before delivery: a plan the team does not buy into ends up in a drawer.
Where the judgment comes from
I do not speak from hearsay: I have made these decisions under my own name and lived with their consequences.
- At Konect I worked as a software and platform architect: a multi-customer product operated as SaaS with RBAC inside the application and multi-tenancy per deployment —each customer with its own configuration, its own Keycloak realm and isolated data—. Kubernetes, GitOps and a preview environment for every pull request.
- Zetesis Portal, our own platform, answers the same question differently: logical multi-tenancy validated on the server, agents as data in the CMS and a genuinely open source core. It is also an example of evolution without a rewrite: the identity server was extracted from the portal and lives on as an independent product —Zetesis-Auth, with its own image, its own chart and its own release cycle— without rebuilding the platform.
- El Portal de Antonio Escohotado proves the opposite of «Kubernetes for everything»: search, agent, paywall and bots running on a single 6 GB VPS, with well-organized Docker Compose. At that scale it was the right decision, and it still is.
Three projects, three different answers to similar questions. That is what an external review brings: not the fashionable recipe, but the judgment of having seen several options work —and some fail— in real systems.
When it makes sense
- You are weighing a big rewrite or migration and want a second opinion before signing off on the budget.
- Your product went from project for one customer to platform for several and the tenancy model is starting to creak.
- You have been on the same stack for years and no longer know what is intentional debt and what is an accident.
- You want to integrate AI into the product and prefer to know where it adds value before paying the bill.
And when it does not: if you are looking for extra hands to crank out code, or someone to sign a report without reading your system, I am not your consultant.
Related consulting services

IT governance: who gets in, who can deploy, and how you prove it

DevOps and infrastructure consulting

From standard to graph to project

One deployment per customer or one space per customer

Solving complex IT problems

Applied AI consulting for business
Let's talk
If your platform is approaching an expensive decision —a rewrite, a migration, the leap to SaaS, multi-tenancy— before spending the money we can look together at what holds up and what does not. Tell me about your case.