More than the feed. Profiles, following, notifications and search are the visible half; the other half is moderation, abuse handling, rate limits and the tools your team uses to run the place. Products that skip the second half launch faster and get harder to operate every week.

It's designed in, not added. In practice: reporting from every piece of content, a queue with clear actions and an audit trail of who did what, automated flags for the obvious cases, and rules written down before the first incident rather than during it. The tooling matters more than the policy — a policy nobody can enforce is just a document.

It depends on how much of it is content and how much is interaction. A publishing platform with an editorial workflow is a different order from a social product with feeds, notifications and moderation. We scope after discovery and give a fixed number for a defined set of features.

That's an architecture decision made early, not a fix applied later. Feeds, notifications and search are the parts that break first, and they break at different thresholds. We build so the expensive parts can be moved without rewriting the product around them.

Both, and the admin side is usually half the work. Editors, moderators and support staff use your software more than any single user does. If their tools are bad, they either stop using the platform properly or start asking developers to make changes for them.

Usually yes, and often it's the right order — web is cheaper to iterate on while you're still learning what people do. The thing to check early is whether your product needs notifications and offline access to work, because those push you towards apps sooner.

Releases don't take the product down. Content, layout and configuration are editable without a deploy, so a publishing team isn't waiting on engineering to fix a headline. Anything riskier goes out behind a flag that can be switched off without a rollback.