Capabilities

Engineering capability, not a service catalogue

Four connected disciplines for organisations where traffic, reliability, discoverability and performance carry material commercial consequences.

How they connect

Build → Scale → Optimize → Get Discovered

The disciplines are not a menu. They describe a lifecycle, and most engagements touch more than one stage.

  1. Build

    AI Engineering & Automation

    AI systems, automation and digital products — engineered to run in production rather than to demonstrate in a notebook.

  2. Build

    Platform & CMS Engineering

    The content platforms a business publishes through, and the migrations that move content between them — WordPress, XenForo and decoupled builds.

  3. Scale

    Web, Platform & Infrastructure Engineering

    High-traffic platforms, infrastructure, servers and distributed systems — sized for peak concurrency rather than average load.

  4. Optimize

    Web, Platform & Infrastructure Engineering

    Performance, technical architecture, security and front-end weight — fixed at the level the fault exists at, and budgeted so it stays fixed.

  5. Get Discovered

    Search Engineering & AI Visibility

    Crawlability, indexation, structured data and AI-search visibility — the engineering layer beneath search performance.

The disciplines

Where we actually work

Each cluster links to its capabilities, with relevant case studies showing how the work applies in practice.

Why this structure

Four disciplines rather than twenty services

The structure of the site reflects how the problems actually behave.

The disciplines diagnose each other

A search problem is frequently a reliability problem. A performance problem is frequently a front-end architecture problem. A platform that falls over cannot be crawled reliably, and no amount of content work resolves that. Organising by discipline rather than by service is what makes those connections visible.

Because the faults cross boundaries

The reason a large site's crawl rate collapsed is often a 5xx error, and the reason a 5xx error is recurring is often a database contention problem. A team that can only work in one layer will diagnose correctly and fix nothing.

Because senior engineers are the constraint

The people who scope the work deliver it. That is only possible with a small number of disciplines done properly, which is why this site has four clusters and not twenty service pages.

Selected work

What this looks like in practice

Detailed engagements rather than testimonials.

Online communities

Spain's largest forum

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.

Since 2019continuous engagement
Fintech & capital markets

Search engineering at stockbroking scale

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.

225Msitewide impressions
Online communities

Arrse.co.uk

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.

4%increase in organic clicks

All case studies →

Which of these applies to your problem?

If it is not obvious, that is normal — working out which discipline applies is part of the diagnosis.