One Agend Pro · the pathway (v2)

The pathway

Seven steps, each one earning the next

Step 1 gates everything external. Steps 2–5 run as parallel tracks once the gate clears. Step 6 is a decision, not a build. Step 7 paces behind the billing engine. Effort figures come from the sizing docs, not optimism.

Harden the gateway

gatefindings filed

What: Distributed rate limiting and a database-level tenancy backstop (RLS) behind the API, plus three one-line fixes. Findings F1–F5, filed with evidence.
Why: Today tenant isolation relies on every route handler doing the right thing. Fine for our own apps; not fine once client developers hold keys, because a write bug corrupts data instead of leaking it.
Unlocks: external client keys, safelyevery later step

Ship the WordPress plugin

spec ready

What: A thin, freely-distributable WP plugin: settings page, widget loader, Elementor registration, SSO handoff. Contains zero proprietary logic by design — the IP stays on our infrastructure. Commerce needs no cart on WordPress at all: buy buttons deep-link into the new unified portal checkout via SSO, so this plugin and the cart programme's WordPress phase are one workstream.
Why: The widget library is built but nothing installs it. This is the missing half of "build on Agend", and the same plugin later serves every client type — it is the front door of the one build.
Unlocks: AHRI builds read-only tools nowone installer for all clientsno WooCommerce needed

Open the data model — objects

ADR-001 · sized

What: Custom objects behind one registry. First slice (~1 week): typed fields on relationship types. MVP (~4–6 weeks): clients define their own record types — a Mentorship, an Award — with API, scopes and webhooks generated automatically. The field engine already exists in production; this reuses it.
Why: Without this, "build anything" is only true for data we modelled. With it, clients model their own programs without us touching schema — the single biggest gap in the platform claim.
Unlocks: clients model their own conceptsPrograms (with step 5's workflows)AI-readable objects via the same registry

Make the bridge two-way

design complete

What: Write-back to Upbeat via a transactional outbox: a member's change confirms instantly on the platform and propagates to Dynamics seconds later, with echo prevention and a human-reviewed conflict queue. Phased: profiles → payments & renewals → joining. The new unified cart/checkout supplies the charging front half — one order ledger, one gateway layer — and for bridged clients this phase records each settled order back into Upbeat.
Why: Every transaction (join, renew, pay) still lives only in the proprietary plugins on client servers. Each write-back phase retires a slice of that code — this is how the encoding/IP-protection problem dissolves instead of being managed forever.
Still sync: Async is for records, not questions. Where Upbeat computes something in real time — like cart pricing, where a draft invoice returns the member's actual price — that stays a synchronous call, routed through the platform instead of the client's server. Same flow, safer home; and each pricing rule we mirror into the platform shrinks the dependency.
Unlocks: self-service via APIclick-to-pay via APIplugin retirement begins

Complete the import — all of Upbeat

14 domains mapped

What: Entitlements first (our own analysis ranks it highest value — it powers access gating platform-wide), then organisations, membership catalogue, CPD both directions. The long tail (loyalty, reference data) lands in custom objects via one generic, config-driven connector — configuration, not code, per entity.
Why: Everything Upbeat holds gets a proper home in the suite, visible to segments, workflows and reporting — not trapped in a CRM only our plugins can read.
Unlocks: every Upbeat domain, homednew feeds without new code

Decide events: sync or migrate

decisioncensus ready

What: Events is the hardest Upbeat integration — or a data migration into our own Events module, which already runs simple events end-to-end and needs three structural builds (sessions, packages, CPD linkage) for conferences. A one-hour census query against a client database tells us which shape their events actually are; five staff interviews cover the rest.
Why: The evidence cuts both ways: staff author events entirely in Dynamics (favours sync), but connector effort serves only Upbeat clients while native Events investment serves every client (favours migrate). Deciding on data avoids building the hardest thing by default.
Unlocks: the right events investmentpossibly deleting the hardest build

Converge the client base

parity map done

What: Migrate legacy AMS clients off Groundhogg into the suite — contacts, tags and companies port with existing transformers; automations rebuild in workflows; billing paces behind the billing engine. The consent/preference data must have a suite home before the first client moves (legal requirement, flagged).
Why: Groundhogg was our implementation choice, not the client's investment — so these clients migrate rather than bridge, and immediately get every write capability with no phases to wait for. Their WordPress front-end stays; only the engine changes.
Unlocks: both old product lines retireone build serves everyone

Sequencing honesty: 1 → (2 ∥ 3 ∥ 4 ∥ 5) → 6 informs the events row of 5 → 7 paces behind billing-engine milestones. Nothing waits on everything.

the record flows down · Upbeat feeds the hub (drivers), the hub answers back (outbox) and asks in real time (oracle) · source: diagrams/data-bridge.drawio.svg (draw.io-editable)

What compounds

The opportunities live between the steps

Each step is useful alone. The register below is what their combinations produce — the reason the sequence is worth more than its parts.

Programs — a sellable product, not a feature

A client defines a Mentorship object, then wires automations to it: on created, email both parties; after 30 days, send a check-in; on complete, award CPD. Mentoring, awards, SIGs — the things associations run in spreadsheets — become a no-code program builder.

steps 3 + workflows exposure

AI-ready by construction

The object registry can expose every record type — ours and the client's — as REST, as a widget, and as an AI-agent tool from one catalogue. Member-facing assistants ("when's my membership due?") become a configuration, not a project.

step 3 · registry design constraint, near-zero cost now

Config, not code

One generic connector maps any Upbeat endpoint into a custom object. Future data feeds — committees, qualifications, whatever comes next — stop being engineering projects and become an afternoon of configuration.

steps 3 + 5

The commercial layer

API metering and entitlements are already wired, so platform pricing tiers and an agency-partner channel need packaging decisions, not code. Every association's web agency becomes distribution for the one build.

unlocked by step 1 · needs a pricing session, not engineering

The big picture

One Agend Pro. Agnostic at the top. Independent underneath.

The endgame is a single "Agend Pro" build — one WordPress plugin, one widget library, one documented API — sitting on a CRM-agnostic platform. Independence from Upbeat in technology: the suite is the system of engagement and, for most clients, the system of record; Upbeat becomes one pluggable source, not a foundation. Independence in business: no proprietary code on client servers, no product line hostage to one CRM relationship, and clients — or their agencies — extend their own environments with objects, workflows, widgets and keys we meter and price. We replicate Upbeat's coverage, not its product: a succession strategy with a coexistence mode.

three client configurations, one front door · source: diagrams/client-configs.drawio.svg (draw.io-editable)

Bridged

Upbeat clients. Nightly feeds down, transactional write-back up. Their Dynamics investment keeps working — better than before.

Migrated

Legacy AMS clients. One-off move off Groundhogg; the suite becomes their CRM. Full write capability from day one — no phases.

Native

New clients. Straight onto the platform. Every improvement we ship lands for all three configurations at once.

Three calls that are yours, not engineering's

The Upbeat position — partner we enrich or incumbent we succeed. One internal paragraph, needed before the first client asks "why are we paying for both?"
AHRI plugin ownership — check the services agreement before offering their bespoke plugin as source.
Run the events census — one hour against a client database; it settles the biggest open build decision with data.

Two builds.
One pathway.
Any CRM.

The platform is further along than the product story

Running in production

In the way

Already decided, on paper