Performance and reliability are engineering properties with measurable causes. We diagnose the cause, fix it at the level it exists at, and instrument it so it stays fixed.
The failure mode is remarkably consistent. A platform is built and tuned against its current load, grows, and then fails at a peak. Every decision was correct at the time. The problem is that average-load tuning produces a system that is comfortable most of the time and unavailable at exactly the moments that matter most — which for a community, a marketplace or a publisher is precisely the wrong trade.
Each links to the full capability page — the problem it addresses, how we work, and the evidence behind it.
Front-end weight is a performance decision, a search decision and a conversion decision at the same time. We build and remediate web platforms so the browser is not doing work nobody asked for.
Traffic is only a problem when the architecture was sized for average load. We engineer and remediate platforms for sustained concurrency and unpredictable peaks — the conditions under which most failures actually occur.
Performance is the one engineering property every visitor experiences directly. We work from field data rather than synthetic scores, fix the dominant cost rather than the textbook one, and enforce a budget so the gains survive the next release.
The layer that decides whether everything above it works. We design, provision, tune and then operate the infrastructure a platform runs on — including the ongoing management that keeps a tuned system tuned.
Capacity planning keeps a platform up. It does not tell you what happens at 03:00 when something fails anyway. Reliability is the engineering of detection, diagnosis and recovery — and of making an intermittent fault reproducible.
A failing system is a diagnosis problem before it is anything else. Restarting the server is a decision about the last ten minutes. Finding out why it failed at 03:00 four nights running is a decision about the next six months.
A compromise is not only a security incident. It is a visibility one: a safety flag, a malware warning or a suspension removes a site from search far more completely than any code change could. The two have to be engineered together.
A security assessment is a measurement taken on one day. What keeps a platform out of trouble is what happens on the other three hundred and sixty-four — the patch that was applied before it was exploited, and the component that was replaced before it was abandoned.
A compromised site is two problems with two clocks. One is the intrusion, which has to be contained before anything else. The other is the flag that has already removed you from search, which clears on other people's schedules. We work both, in that order.
The warning is applied by somebody else and removed by somebody else. What you control is whether the cause is actually gone — and that is the part that determines whether the warning comes back.
Somebody has to own the server. If it is nobody in particular, it is owned by whoever notices a problem last. We take responsibility for agreed operations — patching, backups, monitoring and escalation — with the boundary of that responsibility written down before the first change.
A server migration is a data-consistency problem wearing an infrastructure costume. The move itself is routine; what goes wrong is the delta written after the copy and the dependency nobody remembered. We rehearse the cutover before we perform it.
Work where this cluster was the substance of the engagement.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
A large marketplace platform in the United States was experiencing critical downtime from compounding traffic and application faults. Soludome analysed requests through the web application firewall, identified and blocked the DDoS patterns, and repaired a third-party payment flow that allowed links to be generated repeatedly without authentication. Server load fell and platform performance improved after the work.
Since 2021, Soludome has managed infrastructure, site performance and technical SEO across GuzziTech and RideMalibu as a connected web estate. The engagement includes dedicated infrastructure and continuing operational ownership.
A platform that had previously ranked well had declined through a combination of technical and on-page problems: nearly ninety percent of the site failed Google's Core Web Vitals assessment, server response times were high, and metadata and content signals needed work. The engagement addressed those constraints together.
The disciplines support each other. A platform that cannot stay up cannot be crawled reliably, and a search problem frequently turns out to be an infrastructure problem.
Building AI into systems that have to work in production.
Making complex sites crawlable, indexable and citable.
Building and running the systems editorial teams actually publish on.
Describe what the system is doing. Working out which discipline applies is part of the diagnosis, not something you should have to guess.