Why R10x needs Forward Deployed Engineers
R10x isn't shipped once — it's deployed into a different POS environment, a different store floor, and a different shopper context every time. The team that designs the architecture has to be the team that stands in the store and makes it work. That's the FDE model, and it's the only model that fits a lean, AI-native team with no separate professional-services layer.
Multiple POS vendors, multiple sets of quirks
MBS, LOC, and RMH are scoped as technical partners today, not a single integration — and the list will grow as the network does. Every TLog feed, every GS1 8112 implementation, has its own edge cases that only show up once you're inside it.
Per-store context, not per-product config
The Store LLM relies on per-store context injection. Getting that right requires someone who has actually watched how a specific store operates — not just read its data schema.
Every new retailer is a new deployment
Selectos is the first of ten PR retailers in the network model, before mainland markets. Each one needs an engineer who can own the on-site relationship, not a sales handoff to an engineer.
No professional services org — the bench is the org
The AI-native, minimal-overhead posture means there's no separate implementation team to hire. FDE capability has to be built into the core engineering bench, starting now.
Selectos MBS POS testing is the literal first assignment
MBS POS testing and approval is the non-negotiable gate blocking Selectos go-live — which makes it the highest-leverage, lowest-risk place to run the first FDE training cycle. Whoever is closest to that work right now is already, by necessity, doing FDE work. This program formalizes what's already starting to happen and gives it a repeatable shape.
Ten pillars of the FDE competency
This is the same framework for converting a current engineer and for onboarding a new one. It runs from platform knowledge, through the technical stack and applied AI, to the field- and collaboration-specific skills that are usually the real gap.
Platform & Data Model Mastery
Before an engineer can be trusted in a retailer's office or a CPG brand manager's inbox, they need a complete, granular command of the platform itself — not just the parts they personally built. That means fluency across all three sides of the R10x data model: how a retailer's stores, POS systems, and economics work; how a CPG's campaigns, redemption mechanics, and reporting expectations work; and how a shopper's identity, engagement, and redemption history work. The Data Hub's full entity model has to be second nature, not something looked up mid-conversation.
Workflow & Data-Flow Mapping
Every new retailer or CPG partner arrives with its own current-state reality — existing POS exports, legacy loyalty systems, manual spreadsheets, or homegrown tools nobody fully documented. Before integration work starts, someone has to map how data actually moves today: where it originates, what touches it, where it breaks, and where R10x needs to plug in. That mapping is also where bespoke development gets identified and scoped — the gap between today's workflow and what the platform needs becomes the engineering backlog.
Full-Stack Technical Fluency
Field work isn't just integration plumbing — FDEs need to be able to build and ship. That means real fluency across the stack the platform runs on: Node.js and TypeScript for services and tooling, Python for data and scripting work, React for any customer- or store-facing surface, and GCP for actually deploying what gets built rather than handing a finished feature to someone else to put live. An engineer who can only read code, or who can only work in one layer of the stack, hits a wall the first time a fix needs to touch the front end, back end, and infrastructure in the same sitting.
Systems & Integration Engineering
The technical backbone of every deployment: fluency in the POS protocols R10x connects to today, and the judgment to debug a live production data flow under real conditions — not a staging environment.
Applied AI & Agent Engineering
Cortex — the Store LLM — is the actual product moat, not a feature bolted on top of the platform, which makes this one of the most important pillars in the whole framework. An FDE has to be able to deploy Cortex per store, not just per product: tuning the context that gets injected for a specific store, and recognizing when a bad agent answer is a prompt problem, a context problem, or a data problem — each one calls for a completely different fix. It also means understanding enough of the context-graph layer underneath Cortex to reason about why an answer came out the way it did, not just that it did. And it covers the economics that make Cortex viable at scale: knowing why it runs on a nightly/weekly signal cadence instead of real-time calls, so a field "fix" doesn't quietly break the per-store margin it depends on. In a lean, AI-native team, this pillar also includes using AI coding tools in the FDE's own workflow — an engineer who builds faster with them is more field-effective, not just more efficient.
Collaborative Engineering Delivery
An FDE rarely builds alone. The model depends on working hand-in-hand with the broader engineering team — handing off a clean, well-scoped spec, pairing through development, and staying engaged through deployment and testing rather than throwing work over a wall. GitHub is the actual mechanism this runs on: branches, PRs, and code review are how a US engineer's scoped fix becomes something the India team can pick up, build out, and hand back without a meeting. With engineering distributed across the US and India, this pillar is also where the round-the-clock operating model lives or dies: the quality of the handoff is the quality of the next twelve hours of work.
Customer Discovery & Translation
Turning what a retailer's IT lead or store manager says into the actual scoped engineering task — usually two different things.
Rapid Prototyping Under Ambiguity
Shipping a working fix on-site, same day, with incomplete information — field timescales, not sprint timescales. This isn't just judgment, it's a concrete toolkit: quick UI scaffolding to show a retailer or CPG contact something real instead of a slide, feature-flagged rollouts to test a fix safely in one store without touching the rest of the network, AI-assisted coding to compress build time, and lightweight one-off scripts that solve today's specific problem without over-engineering for tomorrow's.
Ownership & Field Judgment
Patient and fair with frustrated store staff, decisive the moment a line needs to be drawn. Owns outcomes, not tickets.
Communication & Trust-Building
The connective tissue — without this, the other nine pillars never reach the customer, or the engineer on the other side of the handoff.
Skill matrix: the shared scorecard
One rubric, two uses — score a current engineer's conversion readiness, or score a new hire's onboarding progress. Use it at every phase gate in Tab 4.
| Pillar | Foundation | Developing | Proficient | Field-Ready |
|---|---|---|---|---|
| Platform & Data Model | Can name the three sides of the platform — retailer, CPG, shopper | Can explain the full data model for at least one side, unprompted | Can explain how all three sides connect through a single transaction event | Fields a granular data-model question live, from any side, without notes |
| Workflow & Data-Flow Mapping | Can read a current-state diagram someone else drew | Can draft a current-state workflow map from interviews, with review | Independently maps a new customer's systems and flags bespoke needs | The mapping becomes the scoping document engineering builds from directly |
| Full-Stack Fluency | Comfortable in one of Node.js / TypeScript / Python / React | Working competence across two of the four, plus basic GCP deployment | Ships end-to-end across the full stack independently, including deploying to GCP | Builds and ships a bespoke integration solo, front to back, infrastructure included |
| Systems & Integration | Can read a data flow diagram and explain it back | Can trace a single record through the pipeline with help | Debugs a live integration issue independently | Has shipped a fix inside a POS vendor's live environment, unsupervised |
| Applied AI & Agents | Can describe what Cortex does and why it runs on a nightly/weekly cadence | Can tune per-store context with guidance and explain the result | Debugs a bad agent output back to its root cause — prompt, context, or data — independently | Owns a full Cortex deployment for a new store, context tuning through cost/latency tradeoffs, unsupervised |
| Collaborative Delivery | Writes a ticket and hands it off | Opens a GitHub PR and pairs with an engineer through one full dev cycle with guidance | Runs the spec → PR → build → deploy → test cycle with a remote partner solo | Trusted as the connective tissue across timezones, without supervision |
| Discovery & Translation | Has observed a customer conversation | Can draft requirements from notes, with review | Runs a discovery conversation solo and scopes it correctly | Retailer contacts ask for them by name |
| Rapid Prototyping | Ships features on normal sprint cadence | Has shipped one same-day fix under supervision | Regularly ships same-day fixes solo, using scaffolding, flags, or AI-assisted coding as needed | Known for shipping the right-sized fix fast, not the perfect one slow |
| Ownership & Judgment | Escalates everything by default | Solves routine issues, escalates correctly on the rest | Makes good solve-vs-escalate calls under pressure | Trusted to own a retailer relationship end to end |
| Communication & Trust | Writes clear internal tickets | Writes a usable after-action report | Runs a calm customer call solo | Reports and cross-timezone handoffs become reference material for the team |
The phased program
Five phases, anchored to the real deployment calendar — not an abstract curriculum. Phase 1 starts the moment Selectos MBS POS testing is underway. Gate timing aligns with the QB System's existing 90-day performance-gate structure rather than running a second, parallel evaluation track.
1–2
Foundation
- Full Data Hub / architecture walkthrough with engineering leadership
- Platform & data model immersion across all three sides — retailer, CPG, shopper
- Tech-stack baseline check: Node.js, TypeScript, Python, React, GCP, and GitHub workflow fundamentals
- Cortex / Store LLM architecture deep-dive — per-store context model, agent-debugging basics, signal cadence economics
- Shadow one live POS vendor call (MBS)
- Domain crash course: GS1 8112, CPG promo mechanics, clearinghouse basics
3–6
Shadow Deployment — Selectos MBS testing
- Paired with senior engineering through MBS POS testing and approval
- Shadows a current-state workflow mapping session with a retailer or CPG contact
- Shadows one Cortex context-tuning or agent-output debugging session
- Shadows one full paired development cycle with the engineering team, start to finish
- Observes, takes structured notes, drafts first after-action report
- No independent customer contact yet
7–12
Guided Ownership
- Owns one scoped Selectos task (e.g. a single store's Cortex context injection, or one POS edge case) with daily check-in
- Owns one per-store Cortex context-tuning or agent-debug case independently, with review
- Maps the current-state workflow for one in-scope process and hands a scoped spec to engineering
- Runs one full spec → build → deploy → test cycle paired with the engineering team
- First direct — but supervised — contact with Selectos IT / store ops
4–6
Independent Field Ownership
- Leads onboarding of the next PR retailer end to end, including the current-state workflow mapping
- Owns the Cortex deployment for that retailer — context tuning, agent debugging, and cost/latency tradeoffs
- Owns the technical relationship with that retailer's contact directly
- Runs the full collaborative delivery loop with engineering solo — spec, build, deploy, test, sign-off
6+
Scale & Specialize
- Specializes: POS Integration Lead / Cortex Deployment Lead / Retailer Onboarding Lead
- Mentors the next FDE candidate through Phases 0–2
- Extends into mainland deployments as that track activates
US ↔ India: a follow-the-sun field model
One or two US-based Forward Deployed Engineers carry the field relationship. An India-based engineering team extends the build day into the hours the US side is offline. Together, the two groups get close to round-the-clock coverage without anyone working a 24-hour shift.
Why follow-the-sun fits this team
Retail operations run on local hours — issues surface on the store floor or in a retailer's inbox during the Puerto Rico business day. If the only people who can act on them are asleep for half of that day, the loop is slow no matter how good the platform is. Splitting field-facing US hours from build-heavy India hours closes that loop without forcing either side into a night shift, and it stays consistent with a lean, AI-native operating posture rather than building a large round-the-clock team in one place.
1–2 engineers, field-facing
- On-site / real-time presence with retailer IT, store ops, and CPG contacts
- Owns triage — same-day fix, scoped dev ticket, or escalation
- Runs discovery and current-state workflow mapping in person
- Hands off scoped work to the India team with a clear, written spec
- Reviews and signs off on what comes back before it goes live
Build-heavy, deployment & test
- Builds scoped specs into shipped code
- Owns deeper development, deployment, and structured testing
- Picks up the queue at the end of the US day, hands resolved work back by US morning
- Maintains full-stack and platform / data-model depth behind every deployment
Puerto Rico runs on Atlantic Time (UTC-4) year round; India runs on IST (UTC+5:30) — roughly a 9.5-hour gap. Exact shift hours should be finalized once the India team is staffed, but the natural overlap looks something like this:
| Region | Local day shift | Same hours, other region's clock |
|---|---|---|
| US / Puerto Rico (AST) | ~8:00am – 6:00pm | ~5:30pm – 3:30am IST |
| India (IST) | ~9:00am – 7:00pm | ~11:30pm – 9:30am AST |
That leaves a natural overlap window in the US morning (~8:00–9:30am AST / ~5:30–7:00pm IST) for live sync — and near-continuous coverage the rest of the day across both shifts.
Start with one or two US FDEs and an India engineering pod sized to current build volume. As the retailer count grows toward the full Puerto Rico network, scale the India side first — the US side stays small and field-facing by design, while the India side absorbs the build volume that comes with each new deployment.
This is the operating model the Collaborative Engineering Delivery pillar exists to support — it's the skill that makes a US engineer's handoff usable by someone nine and a half time zones away, and makes what comes back trustworthy enough to ship without redoing the work.
Two entry points, one framework
The same ten pillars and the same phase structure apply whether the engineer is already on the team or walking in the door for the first time. Only the starting point changes.
Converting existing engineers
The team's most platform-fluent engineers already carry deep platform, domain, and technical-stack context. The gap is almost never the foundational technical pillars — it's workflow mapping, cross-timezone collaborative delivery, field judgment, and Applied AI & Agent Engineering, which is new enough that tenure on the team doesn't guarantee it either.
- Compress Phase 0 to a few days — skip what's already known, focus on the field- and collaboration-specific gaps
- Move straight into Phase 1 on the live Selectos MBS classroom
- Score against the matrix before starting, to target the real gap instead of re-teaching the architecture
Onboarding new engineers
Full Phase 0–4 sequence, no shortcuts. Engineers already mid-evaluation are the natural first test cases.
- Run the complete program from Phase 0, including the full-stack and platform-mastery baseline
- Use the skill matrix as a shared input to their existing evaluation, not a parallel process
- New hires going forward are recruited and screened against all ten pillars — including the Node.js / TypeScript / Python / React / GCP / GitHub baseline and Applied AI & Agent Engineering — from the first interview
Weekly POS rotation — pair through MBS, LOC, and RMH in turn so no FDE is single-vendor dependent.
Paired delivery rotation — regular spec → build → deploy → test cycles run jointly with the India engineering team, to build the Collaborative Engineering Delivery pillar deliberately rather than incidentally.
Standardized after-action report — every field deployment and every cross-timezone handoff produces one; feeds directly into the Layer 0 knowledge system rather than living in someone's notes.
1:1 coaching cadence — senior engineering on technical judgment, founder leadership on field and customer judgment.
Field Playbook — a living internal document, updated after every deployment cycle; itself a natural next artifact for this program to produce.