InkVein

InkVein began with InkIdea, a creative club I started while attending Mt.San Antonio college. The club eventually fell through because of a combination of difficult club requirements and leadership decisions that I would’ve definitely handled differently today.

Rather than abandoning the idea behind it, I carried the part I cared about most into InkVein, “creating a place where creatives can find one another, collaborate, and build opportunities together”.

That history also changed how I approached my product. InkVein was not only an interface problem. I wanted to think about the systems underneath a community like, ownership, moderation, accountability, collaboration, privacy, and what happens when those systems hit their bottleneck.

InkVein is built with React Native, Tamagui, and a Django backend.

I chose React Native so Android and iOS could share a primary application codebase instead of requiring two independently maintained clients.

Shared code, however, does not mean identical devices. IOS and Android both has its own distict platform modualso to support their OS speciic logic. One of the lessons from development has been that cross platform “equity” requires intentionally accounting for native differences.

Android system navigation, safe areas, device cutouts, camera housings, keyboard behavior, and outher platform specific interaction patterns can all change how the same interface behaves. My goal became feature and experience balance rather than “pixel for pixel sameness”.

When a platform specific problem appears, I like to document the behavior and add the lesson or post mortem to the development guidance I use with my AI tooling so later work considers the same constraint instead of rediscovering it.

Moderation quickly became one of the more complicated systems in InkVein.

Social platforms need mechanisms for dealing with abuse, safety issues, disputes, and outher legal obligations, but those same tools can create privacy problems when they expose more user information than a moderator actually needs.

Before building the moderation interface, I worked through more than 100 moderation related product and design decisions. Three principles became especially important:

• A moderation case should expose only the information necessary to evaluate that case.
• Access to additional private information should not be granted simply because someone has a moderator role. It “needs” to have a defined reason and authority.
• A moderation response should provide room for a moderator note so an affected user could understand that a human reviewed or approved the decision.

I started with a mobile moderation experience rather than a separate desktop administration product. The goal was to keep routine moderation accessible while reducing the complexity of maintaining another completely different interface.

The initial set was intentionally bounded:

• Assigned tickets
• Moderation history
• Invite and join access
• Moderator profile
• Moderation guidance
• Legal or policy agreements required before receiving moderation privileges

Instead of creating an unrelated second application, I reused InkVein's existing interface patterns and adapted them for moderator's responsibilities. This helped keep the product familiar while still separating moderator capabilities from ordinary user capabilities.

I use AI as part of the development workflow, but I preserve important product constraints instead of asking the model to rediscover them every time.

When I find a platform difference, accessibility constraint, architectural rule, or regression pattern, I document it in the guidance used by my development tools.

The intent is to make accumulated project knowledge reusable while keeping product decisions and verification under human control.