Skip to content

Process & Organisation

The hardest open item in the whole brief, and one that will not resolve: there is no concrete definition of the alpha's scope, and none is coming from BSR — not on this timeline and not by asking again. Neosframe defines it from its own judgment, anchored on BSR's actual original ask, then corrects from real usage.

Every timing statement on this page is provisional

The six-week window and the assumption that Templates work would pause are no longer confirmed (Home → Target deadline). The decisions below hold regardless of exactly how much time there turns out to be; the pacing does not.

The alpha's scope is undefined, and will stay that way

Neosframe will not get alpha acceptance criteria from BSR. Every BSR example used throughout this design is still the same four anecdotes from the original incident, and asking BSR for a spec will not produce one, whether or not BSR themselves fully know what they want. The one concrete anchor: BSR's actual original ask — can they add a layer — is the closest thing to a real, load-bearing acceptance criterion this effort has, and the most defensible starting point for scoping the alpha.

There is no external signal on scope to wait for, at any point — not before the alpha ships, and not after. The plan is to guess from Neosframe's own judgment, ship against that guess, and find out how wrong it was from real usage. That feedback is the only correction mechanism this effort has.

The strategy: iterate on a solid foundation

Rather than choosing between an upfront spec and open-ended discovery with BSR: ship an alpha, let BSR use it, adjust from real feedback — but treat the alpha itself as a foundation release. The underlying architecture needs to be solid before that iteration starts, even if the exact feature surface isn't fully specced.

Named risk, not a hypothetical

If BSR's real needs turn out to differ materially from what's designed here, the foundation built for the alpha may not fit — given how much of this design is scoped around four illustrative examples rather than a validated requirements list.

No plan yet to observe real usage

The strategy above rests entirely on learning from how BSR uses Composer. Nothing in this brief defines how that learning happens. There is no usage telemetry planned: no tracking of which exposed fields BSR touches, which permission-tier boundary they run into and how often, which Change types get exercised versus never used, or what breaks and how. "Real usage" only teaches Neosframe anything if it's observed, and right now nothing observes it. This is a gap the strategy itself creates.

Haley's plan is still pending

A separate, high-level plan is coming from Haley, from a product and business vantage point. She hasn't seen this brief, which is deliberately technical. Once her plan exists, this brief needs to be reconciled with it, not treated as independently authoritative until then. The Target Deadline's status note is unreconciled for the same reason.

Staffing, rollout, and cutover

  • Staffing is ad hoc by default, not a fixed roster — whoever's available, changing week to week, consistent with a startup's normal rate of change. Not a gap to close before starting; the operating condition Delivery Sequencing has to plan around.
  • Go/no-go ownership for the alpha checkpoint sits with Blair, as CTO — and extends to code-level rollback of either engine (Testing, Preview & Incident Response).

Decided: BSR stays on the current system, uninterrupted, until the alpha is ready

No dual-running period and no per-org toggle switching Composer on mid-build. Worth being plain about what that preserves: BSR's real usage of the current system is already low, precisely because it can't do what they need — which is the whole reason this effort exists. Continuity here means no new interruption, not a smooth experience being carefully protected.

Decided: existing live campaigns get manually rebuilt by Neosframe's own engineers

Not migrated automatically and not left for BSR to redo. The rebuild leans on a combination of existing Assisted Imports tooling and Claude-assisted engineering work, not a from-scratch rebuild of every asset by hand. Distinct from the deferred PSD import (Editing UI & Canvas), which is about arbitrary external files; this is Retail Studio's own already-known template and campaign rows moving into Composer's schema. The old campaigns are eventually deprecated rather than migrated in place.

Rollout beyond BSR is comparatively low-risk since BSR is currently Retail Studio's only client — there is no other org's workflow to protect. Commercial/pricing framing is out of scope for this brief; it belongs to the broader Retail Studio commercial package.

Risks

  • The foundation may not fit BSR's real needs (above).
  • How much the ad hoc staffing model actually constrains delivery won't be visible until the work is underway.

Open questions

  • How the team decides when to stop hardening the foundation and cut over to iterating on the guess, without an external signal to trigger that call. Not whether a concrete bar for "solid enough" can be set before shipping — it won't be.
  • What Haley's plan changes once it exists, and how much of this brief survives contact with it.
  • Who owns building real-usage instrumentation, and whether it needs to exist inside the alpha window or can follow shortly after — it doesn't gate the alpha's architecture the way the Foundations do, but it gates whether the alpha's stated strategy actually works.
  • What usage instrumentation already exists elsewhere in Retail Studio that this could reuse.