Linstagram

I built Linstagram as a full-stack social platform that could hold both product-facing UI work and deeper backend and infrastructure decisions in the same system.

The project gave me room to work through search, graph-backed relationships, media flows, AWS services, and deployment tradeoffs in one application, with real decisions around latency, cost, and operational complexity.

The application covers the core product surface you would expect from a social platform: user accounts, profiles, posting, comments, likes, follows, search, and mobile-friendly flows.

I wanted it to feel like a coherent product rather than a collection of isolated screens, which meant treating feed behavior, post creation, discovery, profile flows, and responsive layouts as one connected experience.

One of the most important tradeoffs was cost. AWS Neptune was the original graph database target, but even the smallest managed configuration did not make sense for a non-revenue project. I chose to self-host JanusGraph on an existing EC2 instance instead.

I also tested moving the REST API to AWS Lambda, but cold starts introduced too much latency for a user-facing application. In practice, a continuously running EC2 instance was the better balance between performance and cost.

The natural next steps are notification and messaging systems, stronger frontend metrics collection, and deeper operational automation around CI/CD and deployment.

There is also room to improve some graph query patterns to reduce transactional friction and tighten up the backend data layer.