AI Engineering & Automation
Most AI projects do not fail at the model. They fail at the engineering around it — reliability, evaluation, cost and the decision about where human judgement belongs.
We are brought in when technical problems become commercially important — a platform that cannot hold its traffic, a search estate that stopped performing, an AI project that will not ship. Three connected disciplines, and the engineering to fix the cause rather than describe the symptom.
Four connected disciplines rather than a service catalogue. Most engagements touch more than one, because the faults usually cross the boundaries.
Most AI projects do not fail at the model. They fail at the engineering around it — reliability, evaluation, cost and the decision about where human judgement belongs.
Technical SEO becomes an engineering problem at scale. We work on the layer below the content — how a site is served, crawled, rendered and indexed.
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.
A platform decision outlives the project that made it. We work on the systems content teams live inside — WordPress, XenForo, and the migrations and decoupled builds that move content between them.
Most visitors arrive with one of four problems. Each links to the capability that addresses it.
Impressions dropped and no amount of content work moves them. Usually a crawl, indexation or server-response problem sitting below the content layer.
Technical SEO →Failures at peak, and fine the rest of the time. Almost always average-load tuning meeting a real concurrency requirement.
High-traffic engineering →Core Web Vitals failing on field data while the lab score looks reasonable. The cost is real users on real connections, not a synthetic measurement.
Website performance →A working prototype nobody is confident enough to ship. The distance between demo and production is mostly engineering, and it is the larger part of the work.
AI engineering →Online communities · Spain · Since 2019 — ongoing
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.
Different problems and different scales — each written up with what was difficult, not only what worked.
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.
A sample of the organisations whose platforms we have engineered, maintained or recovered.
A short testimonial from a long-standing client, recorded rather than written. We keep it on the site because it is harder to write than a quote and easier to check than a claim.
John RomaineLinkedIn
Only three sectors are listed, because three have real engagements behind them. Sector knowledge is worth something only when it changes the engineering.
Financial platforms publish at news velocity, serve templated data pages by the hundred thousand, and operate under scrutiny that turns every technical fault into a commercial event.
A marketplace outage is not a lost session. It interrupts work in progress, on both sides of the market, at the same time — which makes reliability an existential property rather than a quality one.
Community platforms are unusually demanding engineering environments: a decade of accumulated front-end decisions, traffic concentrated in evening peaks, an audience that returns daily, and a security profile that attracts sustained attention.
A publisher's archive is permanent and its news desk is hourly. Those two estates have opposite discovery requirements, and most publisher search problems begin with someone treating them as one.
A SaaS business runs three sites on one domain: a marketing site judged on conversion, a documentation estate judged on accuracy, and an application that must not be crawlable at all. Most SaaS search problems are boundary problems between them.
An ecommerce catalogue generates more URLs than it intends to. Facets, variants, sorting and filters multiply a few thousand products into a URL space large enough to consume any crawl budget, and deciding which of them should exist is the central problem.
The sequence determines whether a fix holds or has to be repeated. The most common reason a problem has not been solved is that it was never correctly diagnosed.
What the system actually does, as distinct from what it is documented to do.
Finding the real constraint — usually two layers below the reported symptom, which is why treating the symptom rarely works.
A template defect is fixed in the template. An infrastructure defect in the infrastructure. Fixing in the wrong layer means repeating the work.
Measured before and after under matched conditions. Without a baseline captured in advance there is no evidence, only an assertion.
In performance and search especially, the natural direction of travel is backwards. Monitoring is what prevents that.
Not adjectives — the operating choices that determine what an engagement feels like.
There is no handover from a pre-sales team to a delivery team, and nothing between you and the people doing the work. That is also why we do not run a traditional sales process.
A recommendation your team cannot implement has limited value. Where the fix is in the application, the infrastructure or the template, we can make the change rather than describe it.
Our longest client relationships have run continuously since 2019 and 2021. Performance and reliability are properties to be maintained rather than projects to be completed, and we are set up for that.
We separate what changed in the system from the wider movement around it, so you can see which interventions produced a durable operational difference.
Describe what the system is doing rather than what you think the cause is. If we are not the right people for it we will tell you early, and where we can point you somewhere better, we will.