What the pilot actually buys
The early direction is guided pilots first: AlexAI is configured for a specific community
instead of shipped as a generic self-serve bot. That keeps setup simpler for the server
owner, protects quality, and avoids pretending memory, voice, safety, and token costs are
solved by one install button.
Separate Alex
A separately configured AlexAI build for the pilot server, with isolated memory and
server-specific operating rules.
Server culture pass
We map channels, tone, inside jokes, useful utilities, taboo zones, and what Alex
should absolutely not learn the hard way.
Memory and voice policy
Clear decisions around what can be remembered, where voice is allowed, and how
members know when AI features are active.
Admin controls
Owner/admin review for usage limits, dashboard access, feature access, public output,
generated media, and support expectations.
Who the pilot is for
AlexAI works best in adult Discord communities that already have active moderators, a clear
sense of server culture, and a reason to use a memory-rich bot beyond novelty. Adult gaming
clans, creative servers, roleplay groups, private leagues, and long-running friend
communities are the strongest early candidates.
Strong fit
- Adult gaming clan, creator community, roleplay group, private league, or
long-running friend server.
- Owner or admin team can approve memory, voice, and public-facing behavior.
- There is a real use case: events, creative media, lore, moderation support,
utility commands, recaps, or voice presence.
Not a fit yet
- Servers aimed at children or teen safety-sensitive audiences.
- Communities that need instant install, self-serve billing, or enterprise SLAs.
- Spaces where members cannot be told when memory or voice features are active.
The setup flow
The first setup should feel like a guided walkthrough, not a consulting labyrinth. Early
pilots will still be hands-on, but the path should stay simple enough that it can later
become a web or Discord-based onboarding flow.
1. Server map
Purpose, member count, active channels, moderation style, age posture,
and where Alex should show up first.
2. Feature scope
Pick the first useful bundle: chat, memory, utility commands, recaps,
generated media, voice, or admin pages.
3. Voice and memory
Decide what is on, off, opt-in, excluded, deletable, retained, and
visible to members.
4. Personality pass
Build a server-specific Alex prompt that fits the community without
cloning eR33t's private jokes onto someone else's couch.
5. Quiet launch
Start in selected channels or a test space, review behavior, tune
limits, then widen only when the server is ready.
Pilot pricing
Early pilots may be free, discounted, or handled case-by-case while the product shape is still
being validated. The likely long-term model is a paid guided plan with usage-aware pricing,
because token spend, media generation, voice, hosting, support time, and the occasional "why
did Alex say that" investigation are all real costs.
Operating fee
A baseline monthly charge for keeping that server's Alex configured, monitored,
updated, and supported.
Usage costs
Token, media, and voice costs should be covered with a fair markup or allowance so
heavy use does not quietly eat the business.
Pilot discounts
Early friendly communities can help shape the service, so flexible pricing makes
sense while the launch model is still being proven.
Optional keys later
Bring-your-own-key may become an advanced option, but the default pilot should avoid
that friction unless a server specifically needs it.
The first real pricing target is not "maximize extraction." It is "cover costs, create a
sane margin, and learn what communities actually value before pretending the spreadsheet
is scripture."
Boundaries that are decided up front
AlexAI is intentionally not installed as a silent observer. The pilot should make these
choices visible to the server before launch.
Memory
What gets remembered, what gets excluded, who can ask for deletion, and how long
pilot records are retained.
Voice
When AlexAI may join voice, whether voice memory is enabled, and how members know a
bot is present.
Public-facing pages
Whether logs, generated media, blog-like content, or status receipts can be made
public, and what is redacted first.
Admin access
Who can view admin pages, adjust bot behavior, inspect memory, or request
operational changes.
Expected timeline
Pilots are currently manual and selective. The goal is to learn from real communities without
rushing a tenancy model that affects memory, privacy, voice, cost, and server identity.
1. Intake
Submit the request with the community context and boundaries that
matter.
2. Fit review
We review use case, moderation maturity, privacy posture, and technical
readiness.
3. Configuration
If selected, we configure Alex, access, channels, memory
behavior, usage limits, and public-facing notices.
4. Pilot review
We evaluate usefulness, friction, safety events, and what must change
before broader rollout.
Request a pilot
The fastest path is the pilot request form on the homepage. Include community size, your
role, likely use cases, which features you want first, and any safety, privacy, voice,
moderation, or budget boundaries. If this is for a free or friendly pilot, say that plainly;
the early phase is meant to be honest, useful, and only mildly haunted by spreadsheets.
A request is not approval, and pilot details may be handled under a
separate written agreement when needed.