role
Ronald — Backend / Platform Engineer JD
Ronald Reymundo's Backend / Platform Engineer role definition: MemberPress MCP integration, data sync, WordPress-side platform code, interim code-quality enforcement, and the V2 BuddyBoss integration surface. Reports to Seth Shoultes.
Role: Backend / Platform Engineer, MemberIntel
Incumbent: Ronald Reymundo (migrating to MemberIntel as primary focus per the 2026-05-11 phased plan; prior work cleared)
Reports to: Seth Shoultes (Lead Architect, MemberIntel)
Peers: Senior AI Engineer (hire pending — target close mid-June 2026; see JD), matrixed engineering support from Mahmoud Saeed (IPJ) and Thomas Levy (IPJ Lead)
Effective: June 2026 (Phase 1)
References: MemberIntel SPEC v1, SPEC v1.5, SPEC v2, Seth — Lead Architect JD, Senior AI Engineer JD, arch-overview, arch-data-sync
Mission
Own MemberPress-side data plumbing, WordPress integration, the MemberPress MCP surface, and backend platform code under Seth’s architectural direction. Be the WP/PHP-fluent engineer on a team that’s otherwise Python/AI-heavy — the engineer who can read MP internals, ship a fix without needing the MP team’s calendar, and keep the sync invisible to the customer.
Through Phase 2, also backstop baseline code quality on non-AI code until the Senior AI Engineer is ramped (~end of August 2026).
This is a continuing role: V1 (advisor + dashboard + two-tier brain) → V1.5 (agent / write-actions via the MP MCP) → V2 (BuddyBoss, which runs on MemberPress underneath). V2 in particular lands largely on this desk.
Authority structure
Blair (CEO, MemberIntel) holds:
- Product strategy, target customer, 18-month roadmap
- Final approval on PRDs and material architecture commitments
Seth Shoultes (Lead Architect) holds:
- Material architecture choices (hosting, stack, data model, brain isolation strategy)
- Engineering team direction, sprint scope, engineering velocity
- Engineering hiring decisions (you participate in interview loops)
- Vendor / tooling decisions for the engineering stack
- Senior code review of non-AI engineering work (until you’re ramped on it via the interim role below; long-term Seth retains architectural review)
Senior AI Engineer (peer — hire pending) holds:
- Inference pipeline, retrieval, prompt versioning, eval suite
- Cost telemetry and cost-discipline enforcement at the wrapper layer
- Day-to-day code review for AI/ML-touching changes (post-ramp)
- The model-improvement feedback loop
Backend / Platform Engineer (this role) holds:
- MemberPress MCP integration (the surface the V1.5 agent calls)
- Data sync (MP site + Stripe → per-customer brain) per tier cadence
- WordPress-side plugin / onboarding integration (MP admin banner, deep links, install flow)
- FastAPI handlers that aren’t AI-specific (auth, webhooks, billing/entitlement plumbing, cron jobs)
- Interim baseline code-quality enforcement on non-AI code (Phase 1 through Senior AI Engineer ramp)
- On-call secondary (Phase 4+)
- V2 BuddyBoss integration (BB Memberships = MP under the hood)
Santiago Perez Asis (Product + Project Lead) holds:
- PRD authoring (you provide feasibility input)
- Sprint cadence and ticket tracking infrastructure
- Cross-rock dependency tracking
- Ship-gate calls
What you own
1. MemberPress MCP integration (per V1.5 spec §5.2)
- Build and maintain the integration between MemberIntel’s agent runtime and the MemberPress MCP. The MCP is the seam through which the V1.5 agent executes approved actions: membership level CRUD, content protection rules, email / dunning configuration.
- Where MemberPress doesn’t expose what we need, propose the MP-side change to the MP team (via Paul Carter, MemberCore Lead) and ship the PHP fix when it’s the right scope. You are the engineer with the credibility to do that.
- Maintain the eval coverage on the integration jointly with the Senior AI Engineer — the agent action success rate target is 98%+ per V1.5 spec §2; the wire-level reliability lives here, the agent-level eval lives with the Senior AI Engineer.
- No agent operations beyond the four approved V1.5 categories (per V1.5 spec §3 non-goals). The surface stays disciplined.
2. Data sync (per arch-data-sync and V1 spec §8.2)
- Pro tier: daily live sync of customer’s MemberPress site + Stripe data into per-customer brain.
- Free tier: monthly snapshot sync.
- Own the sync jobs, retry / backoff, schema mapping into per-customer brain, error surfacing.
- RLS-enforced per-tenant boundaries are non-negotiable (per ADR-0003). Every sync write carries
current_tenant_id. The invariant is verified in tests. - Build the observability so we see breakage before the customer does — stale-data dashboards on a Pro account erode trust faster than a quota error.
3. WordPress / MP-admin integration
- In-MemberPress-admin banner / menu item promoting MemberIntel (the V1 acquisition channel per V1 spec §4).
- OAuth handoff from MemberPress into MemberIntel.
- Deep links from MemberIntel back into MP admin for instruction-driven workflows (V1 advisor) and agent-confirm flows (V1.5 agent).
- Plugin install help for the V1.5 greenfield wizard’s pre-MP-install path (per V1.5 spec §6.6) — generic “install a plugin from zip” guidance only, no host-specific automation.
4. Backend platform code
- Non-AI FastAPI handlers: auth callbacks, Stripe webhooks, entitlement plumbing, cron jobs (cross-pollination scheduling, weekly digest dispatch).
- The cross-pollination job’s plumbing — the Senior AI Engineer owns the content / anonymization logic; you own its execution surface (scheduling, retries, observability).
- Stripe billing integration in coordination with Ally Roger (Payment Service) per ADR-0012.
5. Interim code-quality enforcement (Phase 1 → Senior AI Engineer ramp)
- Per Seth — Lead Architect JD §2 and the decision-rights matrix: you enforce baseline code quality on non-AI code reviews until the Senior AI Engineer takes over the senior-review role for AI/ML-touching changes (~end of August 2026).
- The standard is yours to hold. If quality slips, Mahmoud Saeed (matrixed from IPJ via Thomas Levy) is available ad hoc.
- Hand off cleanly once the Senior AI Engineer is ramped — no shadow ownership.
6. On-call secondary (Phase 4+)
- Primary on-call: Seth + Senior AI Engineer.
- You secondary on the rotation. Santiago covers customer-facing escalation.
- Per the phased plan, the rotation goes live in Phase 4 (steady-state operation).
7. V2 BuddyBoss integration (per V2 spec §7)
- BuddyBoss Memberships runs on MemberPress under the hood, so V2 is primarily a partnership integration project, not a platform-abstraction project. The integration work lands here.
- Reuse the V1 / V1.5 MP integration directly; do not build a platform-abstraction layer in V2. The abstraction is built in V2.1 when PMP forces it.
- Implement the platform-tagging surface (per V2 spec §6.1) so brain entries can be tagged BuddyBoss-flavored where it matters.
8. ADRs for material backend choices
- When you propose a vendor / tooling / data-model change with non-trivial blast radius, write the ADR and route it through Seth (Seth routes through Blair if it crosses the material-choice threshold).
- Examples: MP MCP surface changes, sync-job framework choice, queue/scheduling primitives, observability stack additions.
What you do NOT own
- AI / ML pipeline, prompts, eval suite, AI cost discipline — Senior AI Engineer
- Material architecture decisions — Seth
- PRDs, product strategy, ship-gate calls — Santiago / Blair
- Pricing strategy — Blair (you implement at the entitlement layer)
- Design / UI — Russ
- Brain content — Sam (Brain Content Lead) — see JD
- Marketing site, beta program, customer onboarding flow design — Santiago
- Privacy / compliance program — Santiago with outside counsel (you provide technical input on data sync and tenant isolation)
- Project management, sprint tracking infrastructure — Santiago
- MP-team prioritization of MP-side fixes — Paul Carter (you advocate; he decides)
If asked to weigh in on any of these, route back to the right owner. Stay in your lane.
Critical role norms
- Never bypass the entitlement service. All model routing is server-side via
llm.calland theTIERSsingle source of truth (per ADR-0002). No env-flag bypass, no admin override path, no client input. You go through the wrapper like everyone else. - RLS on every tenant query. Per-tenant boundary is the privacy commitment (per ADR-0003). Every query carries
current_tenant_id. The invariant is verified in tests. - Sync failures are user-visible. Stale data on a Pro dashboard erodes trust faster than a quota error. Build the observability so we see breakage before the customer does — and so support staff have a clear “is this customer’s sync OK?” answer.
- ADRs for material backend choices. Vendor / tooling / data-model changes with non-trivial blast radius get a written ADR routed through Seth. Future-you and the team need them.
- MP-side PHP fixes go through Paul Carter. You can read MP internals and propose the fix; the merge decision is the MP team’s. Don’t ship a one-off patch in MemberIntel that should have been a fix in MemberPress.
- No host-specific install automation. V1.5 walks the user to where they install MP; we don’t SSH in, run WP-CLI, or browser-automate (per V1.5 spec §3 non-goals).
- No payment-provider automation on the user’s behalf. The agent walks the user to the place where they connect Stripe / PayPal; it does not OAuth into payment providers on their behalf (per V1.5 spec §3 non-goals).
- Disagreements with Seth go to Blair within 48 hours. No silent escalation drift. If something outside the decision-rights matrix comes up, surface it fast.
Success measures (12-month)
| Measure | Target |
|---|---|
| Productive in role | Within 2 weeks of June Phase 1 start |
| Data sync reliability (Pro daily, Free monthly) | ≥99.5% success on the staging eval; matched in production within 30 days of GA |
| RLS / tenant-isolation invariants | 0 cross-tenant leaks in eval or production |
| MP MCP integration ships to support V1.5 agent | Phase 3 (per V1.5 spec §13) |
| Agent action success rate (wire-level reliability) | Contributes to the ≥98% target per V1.5 spec §2 |
| V2 BuddyBoss integration | Ships with no platform-abstraction work in V2 (deferred to V2.1) |
| On-call MTTR (secondary) | Within agreed SLO once rotation is live |
| Code-quality baseline (interim role) | Held through Senior AI Engineer ramp; clean handoff |
| ADRs for material backend choices | One per material change, all in the V1 repo |
Reporting cadence
| Cadence | Audience | Format |
|---|---|---|
| Daily | Seth | Async stand-up — sync health, anything red in production |
| Weekly | Seth + Santiago | 30-min sprint sync — backlog, blockers, upcoming material choices |
| Monthly (Phase 4+) | Blair + Seth | Operational review once on-call rotation is live |
| Quarterly | Blair + Seth | Architectural review — what’s drifted, what’s improving |
What “good” looks like in this role
- The data sync is boring. Pro customers always see fresh data; Free customers always see this month’s. When something breaks, we know before the customer does.
- The MemberPress MCP integration is the reason the V1.5 agent ships on time, not the reason it slips.
- V2 BuddyBoss is a quiet release — same product, new platform, no new infrastructure.
- RLS holds. No cross-tenant leaks. Ever.
- The Senior AI Engineer arrives in June and finds a clean codebase to ramp into, not a tangle of one-off fixes.
- When Blair asks “is the MP side solid?” the answer is a green sync dashboard and a clean MCP eval, not a vibes-based reassurance.
- The MP team sees us as a productive sister-team partner — when we ask for an MP-side change, it’s well-scoped and well-justified.
- You’ve left no ADR debt. New work doesn’t pay interest on old shortcuts.
Document version: Draft v1 — to be reviewed with Ronald before finalization. Decision-rights surfaces require sign-off from Blair, Seth, and Ronald before this JD goes operational. Open question: final title (Backend / Platform Engineer vs. Senior WordPress Engineer vs. something else — Blair’s call).