What x70 Social Needed Before It Felt Like a Product
Dashboard polish was not the turning point for x70 Social. The product became coherent when guest access, realtime engagement, developer APIs, and AI moderation each received a precise boundary.
At the end of June I moved x70 Social from a collection of template-derived screens toward an actual social product.
The visible changes were a dashboard, a blog feed, chat, post detail pages, likes, account settings, and API-key management. The more important work was deciding what each kind of user and integration was allowed to do.
A social interface can look complete long before those boundaries are real.
Guests should see a product, not a broken account
An unauthenticated visitor needs enough access to understand the network without being invited to mutate state they do not own.
That led to a read-oriented guest experience for public content, with sign-in required where identity matters: creating a post, participating in chat, liking content, or managing keys and settings.
The distinction belongs at the server boundary as well as in the interface. A disabled composer explains the state; an authenticated mutation enforces it. If the API accepts the action without a session, hiding the button is only theater.
Realtime likes need canonical state
A like button seems like the smallest possible social feature. It still has to answer several product questions.
- Is one person allowed one reaction per post?
- Does the count update for other viewers?
- What happens when an optimistic toggle is rejected?
- Can a guest see the count without being able to change it?
- Which record proves the current user’s state?
The implementation moved likes into Convex mutations and queries so the button and count observe shared state instead of a local animation pretending to be an outcome.
There are no public engagement numbers attached to this retrospective. The commit proves the feature path was implemented, not that people used it.
An API key is a second interface
The first developer endpoints exposed posts and chat through a versioned /api/v1
surface authenticated by account-managed keys.
That is not simply the web UI without components. An API needs explicit request validation, stable response shapes, revocable credentials, and errors that do not leak internal details. The server must derive identity and permissions from the key instead of trusting an author field in the payload.
Versioning the route creates room to evolve the application without silently breaking a client. It also creates a promise, so the surface should stay smaller than the internal function catalog.
Moderation should create a reviewable state
The model performs an initial publication triage. Unflagged posts enter the approved state, while flagged posts remain pending for human review and stay out of the public feed.
That boundary matters. A model can identify text that deserves a closer look, but it can also miss context, overreact to harmless language, or return an unavailable result. Flagged content therefore has a human review path instead of being treated as a final automated verdict.
The product still needs visible loading and failure states, while permissions, identity, and data integrity remain deterministic backend responsibilities.
The dashboard came last conceptually
Once those boundaries existed, the dashboard could become simpler.
It no longer needed to imply that every card was an independent feature. It could orient the user around the actual product loop: read, publish, discuss, respond, and manage access. Account controls could live where identity belongs, while public content remained reachable without sending every visitor through an application shell.
This is still an evolving x70 experiment, not evidence of a scaled network. The useful milestone was smaller: Social stopped being defined by the pages it had and started being defined by the state transitions it could defend.
That is the point where a template becomes a product.