Skip to content
Jan HřebíčekEnaro
← Case studies

Digital ecosystem

Young Lions Czechia: From manual registrations to a system the organisers run themselves

The collaboration began as technical maintenance of an existing WordPress site. Step by step it grew into automated registrations, applications and onboarding into the Circle community. Over the years that automation spread across four separate plugins, so the second step followed: a rewrite into one modular system in which the organisers set up a whole competition year themselves, without a developer. The end result was cut over live, with no downtime, and documented so that a new maintainer can take it over.

4 → 1
plugins in one modular system
No developer
organisers set up each year
RoleMaintenance, development, architecture & automationStackPHP 8.3 · MariaDB · REST API

Starting point

The technical solution had grown over time and carried plenty of historical changes. The biggest problem, though, was the large amount of manual work around registrations, applications and user management. The organisers had to handle:

  • manual processing of registrations
  • managing applications and documents
  • communicating with participants
  • managing user access
  • working with several separate systems
  • operational issues with the site

Platform stabilisation and infrastructure migration

I spent the first year mainly on technical maintenance and stabilising the whole solution:

  • taking over technical maintenance of WordPress
  • resolving operational issues
  • ongoing system maintenance
  • managing hosting, DNS and SSL certificates
  • technical support for the organising team

A major part was a complete infrastructure migration to a new host, including transferring domains, DNS configurations and email services — with no downtime. The result was a stable environment ready for further development.

Automating registrations and integrating Circle

After stabilisation I focused on registrations and applications, which contained many manual steps. I built multi-step forms with automatic data validation, attachment handling, confirmation emails and a clear application admin. The Roger Hatchuel Student Academy programme got its own registration system, and I extended the same approach to competition submissions.

The second part was connecting the site with the Circle community platform. A registration automatically creates a community account, syncs the data, assigns access rights and places the user in the right programmes. Participants reach the community almost instantly, without an administrator's involvement.

Why a rewrite

The automation worked, but it grew piece by piece. Applications, submissions, the RHSA academy and payments became four separate plugins, each with its own queue, emails and connection to Dropbox and Circle. That had its limits:

  • every new competition year meant editing constants in code and a developer's involvement
  • a configuration mistake only surfaced when the first team signed up
  • Stripe payments were invoiced in Fakturoid without checking that the invoice was actually created

So I moved all four into a single modular plugin that the organisers control themselves.

The competition year lives in the admin, not in code

The whole year is configured in the admin: dates, categories, the form, Circle tags and groups, Dropbox folders, emails and the academy. A new year starts as a copy of the previous one.

  • A pre-launch check verifies against live Circle and Dropbox that the tags, groups and folders really exist. For every problem it says what to do and links straight to the setting.
  • A dry run shows where a test application would land, can write it for real into test copies, and then cleans everything up.

Cutting over with no downtime

The old and new systems ran side by side. The new plugin took over each part — accounts, applications, submissions, the academy, Circle sync and payments — separately, with a single switch in the admin.

  • Every switch had preconditions and refused to take over until they were met.
  • Until the old system was finally switched off, every step could be reverted with one click, without a deployment.
  • For Circle sync and payments the new system first only observed and compared its results with the old one. It took over for real only once they matched.

Payments: Stripe → Fakturoid

  • An invoice is created only for a payment that actually went through.
  • Separate test and live lanes. A test payment never issues a live invoice.
  • A daily check reconciles Stripe with the invoices and flags any that are missing.
  • A payments overview with a chart, a “needs your attention” queue and an integration readiness check.

Reliability and security

  • One shared job queue for emails, Dropbox uploads, Circle sync and invoices: with priorities, retries and protection against sending twice.
  • Failures are never silent. Every failed job shows up in the admin with an explanation and a retry button.
  • Email verification before joining the community.
  • Login rate limits that don't lock out a whole school behind a single IP address.
  • Form protection against cross-site requests and a hidden user list.
  • Every part went through an independent security review before deployment.

How it was built

I led the rewrite as architect and decision owner. The implementation was done in phases by AI agents (Claude Code) following plans I approved, and each phase was then independently reviewed by another agent. Every change had to pass more than 3,500 automated tests on two PHP versions and against a real database before it reached production.

Operations and handover

Around key dates — opening registrations and programmes — I provided technical support for the team, monitoring and incident resolution. The rewrite also covered the handover: in-admin help with more than 30 short articles, a “How to fix” link on every error, documentation and an operations runbook. A new maintainer can take the system over.

Conclusion

Manual registrations and scattered systems became one system the organisers run themselves. They set up a competition year without a developer, configuration mistakes show up before launch rather than with the first team, and payments are invoiced automatically and reconciled every day. Every part is documented so a new maintainer can pick it up.

Tech used

  • PHP 8.3/8.4
  • MariaDB
  • WordPress
  • REST API
  • Circle Admin API & SSO (OAuth)
  • Dropbox API
  • Stripe
  • Fakturoid API
  • GitHub Actions (CI/CD)
  • PHPUnit
  • PHPStan
  • Claude Code

Outcomes

  • a stabilised environment and an infrastructure migration with no downtime
  • automated registrations, applications and the RHSA programme
  • automatic onboarding into the Circle community
  • four plugins unified into one modular system
  • a new competition year without a developer
  • pre-launch configuration checks against live systems
  • a live cutover with no downtime and one-click rollback
  • automatic, daily-reconciled invoicing
  • a security package and independent reviews
  • documentation and help for handing over to the next maintainer