A community platform needs someone who applies the update before it becomes urgent, notices when an extension stops being maintained, and can say what changed last month. That is a cadence rather than a project, and it is what keeps an upgrade from becoming archaeology.
Nothing about a community platform fails loudly in advance. Extensions stop being maintained silently, template modifications drift from templates that change underneath them, permissions accumulate, and the version gap to a supported release widens a release at a time. Each of those is trivial when it is one month old and a project when it is three years old.
The forum matters and nobody is responsible for it between projects. You want that responsibility to exist before something fails.
There is accumulated customisation you do not fully understand and you need it maintained while you learn what it is.
You have been keeping it running and you need it to be somebody's actual job, with documentation, before you take a holiday.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
When a dependency stops receiving updates, it becomes a vulnerability on a schedule nobody controls. Unlike a defect, it does not surface on its own — it is found when it is exploited or when an upgrade refuses to proceed.
An incident is paid for in disruption to the community, emergency work at unsocial hours, and an improvised fix that becomes the next problem. The recurring cost of avoiding it is almost always lower.
When knowledge lives in one person's head, their absence is an incident. Documentation is not overhead, it is what makes the platform survivable.
On a community the audience is present daily and reports problems faster than most alerting. That is a live detection system, but it is not a substitute for one, and it means every failure has already been experienced by people who matter.
Each of these is work we carry out, not an area we advise on.
Before maintaining anything, establishing what exists: platform version, extensions and their maintained status, template modifications, where customisation sits relative to the platform, and whether the backups restore. The assumption is that we are inheriting a state rather than a setup.
Platform and extension updates applied on a defined schedule, tested against a replica where the platform's configuration warrants it, with a rollback for each change. The commitment is the process; the interval is agreed per engagement.
Knowing which extensions remain maintained and which have been abandoned, and identifying conflicts before they surface during an update rather than after.
Template modifications and bespoke functionality kept working as the platform moves — because a modification that is not maintained becomes the reason the next upgrade is deferred.
A defined route for defects and small changes, so work that falls below the threshold of a project still gets done. Prioritisation is agreed rather than implied: what is included, how it is ordered, and what falls outside the agreement.
Confirming that backups complete and that a restore works. On a forum the attachment store usually dominates backup size, which makes its retention a decision rather than a default.
A stated escalation path and covered hours, with no advertised response time we cannot staff.
A recurring written summary of what was updated, what was found and what needs attention, plus a change log. Maintenance that is invisible is the first thing cancelled in a difficult quarter.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
We do not maintain a platform we cannot describe. The inventory is the first deliverable and it frequently changes the scope — an abandoned extension or an unrestorable backup is a finding, not an onboarding step.
A tested restore is confirmed before routine changes begin, because until it exists every update carries avoidable risk. This is the least visible part of the work and the one that most justifies it.
A schedule rather than an intention, tested where the configuration warrants it, with a rollback available per change. Emergency updates happen and are always a signal that the cadence was interrupted.
Where functionality has drifted into the platform's own files, that is recorded and progressively corrected, because it is the single thing that makes every future update harder.
What is included, how requests are prioritised, what is excluded and how an out-of-scope request is handled. Most dissatisfaction with a maintenance arrangement comes from an unstated boundary rather than from the work itself.
A recurring summary and a change log, because the value of maintenance is invisible when it works and the failure mode is a quiet quarter in which somebody decides it was never needed.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
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 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.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
A staged upgrade path for a deferred installation.
XenForo installation and upgradeExtensions and templates built to survive future upgrades.
XenForo developmentInfrastructure, capacity and monitoring for a production community.
Managed XenForo hostingPerformance diagnosis against production-scale data.
XenForo performance optimisationA defined cadence of platform and extension updates, customisation upkeep, backup verification including restore testing, defect triage within an agreed boundary, incident response during covered hours, and reporting. What is not included is stated in writing alongside it, because a maintenance agreement is defined as much by its exclusions as by its scope and the exclusions are the part buyers tend to skip.
Small changes are, within a boundary agreed in writing. Larger development is scoped and priced separately, which is the honest arrangement for both sides — an agreement described as unlimited development is either mispriced or quietly limited. What matters is that you know which category a request falls into before you make it rather than after.
No. We do not offer lifetime support, and we will not describe an arrangement in those terms. What we do is state the maintenance position at delivery: what is covered, for how long, and what extending it would take. An add-on or customisation with an unclear maintenance position is one that quietly stops being maintained, and a clearly stated end is more useful than an implied permanence nobody can honour.
It is agreed rather than inferred: platform-breaking issues first, then anything affecting members' access, then defects, then improvements. Where several items compete within a band, priority follows impact on the community rather than on the requesting party. It is written into the agreement so the ordering is not renegotiated at the moment something urgent arrives.
It means members are the detection system, which works but is expensive in trust. Onboarding includes establishing what can be observed and routing it somewhere a human reads. On a community this usually means availability, response time, error rate and database health as a minimum — and the alerting goes to an address somebody actually monitors, because alerts nobody reads are indistinguishable from no alerts.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.