A community platform is judged in public and cannot be taken offline to be improved. We work on forum platforms that are already carrying an audience, where the constraint is not building the feature but shipping it without an upgrade becoming a project of its own.
A forum that has been running for years has almost always been adapted by several people across several platform versions. Each change was reasonable when it was made. The problem is that the boundary between the platform's own code and the customisations layered on top of it has stopped being visible, and nobody can predict what an upgrade will break until it breaks it. On a community, that upgrade happens in front of an audience that notices immediately.
Your platform has grown past what a general agency or a part-time developer can maintain, and the upgrades have started to feel risky.
You know what the community needs and you need an engineer who understands that disrupting it for a day has a cost beyond the development time.
You have taken on a platform with years of accumulated customisation and no documentation, and you need to know what you are actually running.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Each version skipped makes the next jump larger and the accumulated customisation further from the platform's own moving target. What would have been routine maintenance becomes a rebuild with a deadline set by an end-of-support date.
When customisations are tangled into the core, every template change and every extension has to be re-validated by hand against the whole. Development slows to a rate set by uncertainty rather than by the work.
Search, attachment storage and thread rendering behave differently at ten million posts than at one million. An architecture that was fine when the community was smaller does not degrade gracefully — it degrades abruptly, usually under peak load.
Members are the platform's real asset and they are sensitive to disruption. An outage, a lost post or a broken feature has a cost that does not appear on any invoice — it appears as declining participation.
Each of these is work we carry out, not an area we advise on.
Establishing what is actually running, how far it has fallen behind currently supported releases, what the upgrade path looks like, and which customisations each step will affect. This is the inventory that decides everything downstream.
Building functionality as a properly structured extension rather than as an edit to the platform, so the feature survives version upgrades and can be disabled without taking the forum down.
Theme and template development through the platform's supported mechanisms, with the parent templates left intact where possible so future upgrades remain tractable.
Keeping the boundary between platform and customisation explicit and documented, so the next upgrade is engineering work rather than archaeology. This is a design constraint applied from the start of any piece of work, not a cleanup afterwards.
Database, caching and serving-path work calibrated to how a forum's load actually behaves — a captive audience, predictable peaks, large searches backfilling through long histories, and attachment stores that only grow.
Connecting the platform to surrounding systems — membership, payments, email delivery, analytics, single sign-on — with the failure modes of each understood rather than discovered.
A cadence covering updates, customisation upkeep, performance review and incremental improvement, so the platform moves forward continuously instead of in disruptive jumps.
Taking responsibility for the platform's infrastructure and availability where that is part of the engagement, rather than something the forum owner carries.
Managed XenForo hostingThe sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Versions, extensions, template modifications, integrations and customisations, and which of them are actually in use. On a forum, the list of customisations and the list of things anyone remembers building rarely match, and the difference is where the risk lives.
Long-deferred platforms usually cannot be brought current in one step. Version steps are staged, tested on a replica of the real community, and applied in an order that keeps the forum open as much as possible.
Customisation goes into extensions and child templates rather than into the platform itself. The constraint costs a little more at the start and is what makes the next upgrade ordinary rather than risky — and on a platform with an audience, ordinary is the goal.
A forum behaves differently on a copy of the production database than on a fresh install. Replica testing is where query plans, search behaviour and template cost actually show up, so it is where changes are validated.
Where a change can be staged, tested behind a flag and released gradually, it is. Downtime on a community is not just an availability metric — it is a visible disruption to an audience that is there for each other, not for us.
Every engagement produces a written record of what was built, why, and how to undo it. A platform that only one person understands is one resignation away from being unmaintainable, and that is true whoever built it.
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.
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.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Custom functionality built as an extension is a different job from modifying the platform itself.
Custom XenForo add-on developmentIf the question is who runs it rather than who builds on it, that is a different engagement.
Managed XenForo hostingSource-schema conversion is its own discipline, and the compatibility position matters.
vBulletin to XenForo migrationForum content is unusual in search and the indexation patterns differ from ordinary sites.
Crawl and indexation diagnosisUsually yes, but rarely in a single step. Bringing a badly deferred installation current is staged: each version jump is applied and tested on a replica of the real community before it touches production, and the customisations each step affects are identified in advance. The first thing we produce is the upgrade path as a sequence, so you can see how many steps there are before committing to any of them.
Some of them, most likely, and the assessment will say which. That is why the work starts with an inventory of what is actually in use rather than what appears in a directory — a modification nothing depends on is not worth preserving, and finding that out before an upgrade is considerably cheaper than afterwards. Where a customisation matters, the fix is to re-establish it on a supported mechanism so the next upgrade does not repeat the problem.
That is most of the work, and it is the situation the page is written for. We start by reading what exists rather than by proposing a rewrite. A rewrite is occasionally the right answer; far more often the platform is sound and needs two things corrected, a documented boundary, and an owner.
We will confirm that for your installation rather than publishing a range here. Platform support windows move, and a version list on a marketing page ages into being wrong without anyone noticing. What we will tell you is what your specific installation needs and whether the upgrade path to a supported release is straightforward — and if it is not, that is the first thing you should know rather than the last.
Yes, and it is one of the more common starting points. It begins as an inventory rather than as development: what is running, what has been changed, what depends on what. That document is usually the most valuable deliverable of the whole engagement, because it is the thing that has been missing.
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.