The problem it solves

Member platforms tend to fail in one of two directions. Either they do too little, and clubs end up running a scatter of separate tools — one for membership, one for handicaps, one for events — or they do too much, and every member faces a crowded screen of functions they never asked for. The software that suits the association secretary managing 2,000 records is rarely the software that suits a club secretary managing 60, or a member who wants to check their own handicap and nothing more.

myCroquet is built on a different premise: the platform itself is small, and everything else is a module.

The purpose it serves is the association's own ideals, applied to software. Keep it simple — outcomes over complexity, do less admin and play more croquet. Hit our aims — purposeful decisions, do things that advance croquet.


How it works

The permanent core of myCroquet is deliberately minimal — signing in, viewing and editing your own details, and that's it. Every other feature is an optional, self-contained module: membership administration, the photo gallery, approvals, committee decision voting, Come & Try management, and so on.

Each module declares three things about itself: what its purpose is, the myCroquet services it uses, and who is allowed to see it. From that single declaration, the platform works out everything else. If a module is switched on and you are among its intended audience, it appears in your menu and its pages open normally. If it is switched off, or you are not in its audience, it is absent — not greyed out, not present-but-broken, but absent, as though it had never existed.

A club membership officer sees the membership tools, with the features they need for their club. The association's membership officer sees the same tools, scaled to the whole state. Everyone else sees nothing to do with memberships. A club captain sees captain's tools; a committee member sees the decision register; an ordinary member sees none of these, but can update their details, check their handicap, and enter events. Where a module is useful to a handful of specific people — the newsletter editor, a document publisher, a grants assistant — it is shown to those people and nobody else.


Both large and small at once

The practical consequence is that myCroquet has no single size. To a member who wants only their own details, it is a small, quiet site: a login, a profile, perhaps the gallery. To the club person running Come & Try sessions, it is also a booking system. To the committee, it is also a voting register. Each person's myCroquet is exactly as large as their responsibilities, and no larger.

This resolves the usual trade-off between capability and simplicity. The same platform is capable for high-use people and easy for low-use people, at the same time, without compromise in either direction. It can keep gaining substantial features indefinitely without ever becoming more complicated for the people who don't use them, because a feature someone cannot see costs them no attention. That is what the modularity allows, and it is the reason the platform is built this way.

It also changes the economics of trying things. A new module can be built, installed on the live platform, and left invisible until it is ready — then shown first to a handful of people, then a wider group, then everyone, by widening its audience rather than by re-engineering anything. A feature that doesn't earn its keep is removed as cleanly as it arrived.


An open platform

Because a module's obligations are written down as a standard, other builders can create modules that plug straight in. The standard explains what a module must declare, which myCroquet services it may use, and what it takes to pass the go-live tests. Anything that meets the standard plugs in; anything that doesn't, doesn't run.

This matters most for assistant tools. CroquetClaude, the association's AI assistant, builds and maintains modules this way today — the committee decision register and the Come & Try management tools were both added as modules, switched on when ready, visible only to the people who use them. Other AI assistants, whether the association's own in future or ones brought by third parties, can contribute on exactly the same terms. Their work is plugged in when wanted and pulled out when not, and either way the platform around it is untouched.

The same openness extends to people: a member with software skills, a club with a particular need, or a third party with an existing product. An existing tool need not even be rewritten to join — the standard provides for presenting an outside application as a module, appearing within myCroquet and following the same audience rules as everything else. The contributor builds to the standard; the platform guarantees that their work appears only to the people it is meant for, cannot reach other clubs' data, and switches off as cleanly as any native feature.

Every module, whatever its origin, arrives switched off. Turning it on is a deliberate decision, made after review and testing, and only for its selected audience.


In short

myCroquet is not one application but a small, trusted core carrying a changing set of modules, each visible only to the people it serves. That is what allows it to be both hugely capable and genuinely simple at the same time, and to accept good work from anyone — human or AI — prepared to build to its standard. The core stays small and stable; everything else can come and go as the association's needs change. Simple now, and built to stay that way.

Keep it simple: every member does less admin, sees less clutter, and the platform never grows harder to use. Hit our aims: each module exists because it advances croquet — stronger administration, better-supported clubs, and room for new ideas to be tried safely and kept only if they are useful.