Project Overview
This project is an interest-based community platform designed to help users discover people, groups, and conversations that are relevant to them. At a product level, it sits somewhere between a social network, a local community tool, and a lightweight coordination platform. Users can register, build a profile, choose interests, create or join groups, post content, chat with other members, and receive suggestions based on activity, location, and shared intent.
What gives the product real business context is that it is not just about publishing content. It is trying to reduce the friction between “I signed up” and “I found the right people and actually participated.” The admin console and policy-content workflows also suggest this was meant to run as a managed platform, not just a prototype.
Quick Summary
- Project Type: Community discovery and group coordination platform
- Platform: Public web app, admin web app, API backend, and separate AI services
- My Role: Project Lead, with active involvement in backend API development
- Team Size: N/A
- Duration: N/A
Problem
The core challenge looks like community activation rather than simple content publishing. A basic social app can let people sign up and post, but that does not guarantee meaningful connection. This platform had to solve a harder problem: how to help users define who they are, find relevant groups, invite the right people, coordinate conversations, and stay engaged.
The repository also points to several operational challenges behind that product goal. Group membership is not binary; it includes invitations, join requests, approvals, and private/public visibility. Discovery is not based on one signal; it blends interests, geography, profile data, and behavioral activity. On top of that, the system had to support admins managing users, groups, interests, legal content, and moderation-style workflows.
Goal
Success here looks like creating a cohesive platform where a user can move from registration to discovery to participation without needing separate systems or manual coordination. From an engineering perspective, success also meant keeping that complexity maintainable: clear domain boundaries, consistent APIs, support for realtime features, and enough infrastructure separation to support chat, notifications, async processing, and AI services without overloading the core application.
My Contribution
I worked on this as Project Lead while also staying actively involved in backend API development. That combination is what makes the project meaningful to me. I was not only helping drive direction across the product, but also contributing directly in the areas where workflow design, system behavior, and integration boundaries mattered most.
My role spanned multiple layers of the platform. The frontend experience, admin workflows, backend services, and AI integrations all had to work together as one product rather than as disconnected technical pieces. In this project, one of the clearest stories is the amount of coordination required across public user flows, operator-facing tools, and AI-supported discovery features.
On the implementation side, I was actively involved in backend API work that supported identity flows, profile and interest management, groups, posts, messaging, invitations, notifications, and AI-adjacent workflows. I would describe this as a role that combined leadership, systems thinking, and direct delivery rather than pure oversight.
Tech Stack
Frontend
- Next.js (public site and admin app): Used for building both the user-facing product and a separate back-office interface while keeping the web stack consistent.
- React + Tailwind + HeroUI: A practical combination for shipping multi-step onboarding, profile flows, modals, admin tables, and responsive UI quickly.
- next-intl: Supports multilingual flows, which matters because onboarding, validation, and policy content all need consistent language handling.
- Laravel Echo / realtime client libraries: Used to connect frontend experiences to live notifications and chat updates.
Backend
- Laravel 11: The main application platform for API delivery, domain logic, validation, authentication, and admin-related workflows.
- Laravel Sanctum: A sensible fit for token-based authentication across web clients and admin access.
- PostgreSQL: Used as the main transactional database, with signs of deliberate migration work and support for more advanced data patterns.
- Service-layer domain structure: Important here because the product has real workflow complexity across auth, groups, posts, interests, and admin operations.
Infrastructure
- Docker Compose: Used to run the API, database, Redis, queue worker, cron process, and realtime server as separate services.
- Redis: Supports caching and likely helps isolate app concerns from slower workflows.
- Queue worker and cron containers: Useful for background processing and scheduled recommendation-style jobs.
- Realtime server: Separates live broadcasting concerns from the main HTTP API.
- GitHub Actions on self-hosted runners: Clear evidence of environment-specific deployment automation.
Integrations
- Kafka: Used to publish social events into downstream AI processing.
- FastAPI AI services: Separate Python services handle conversational AI, transcription, embeddings, and behavioral-intent processing.
- pgvector: Supports semantic retrieval and vector-based ranking.
- LLM providers and speech transcription APIs: The AI layer is designed to remain provider-flexible rather than hardwired to a single model.
Testing
- Laravel feature/unit tests: Present, but currently limited in scope.
- Service decomposition and validation-heavy design: The codebase relies more on structured services, validators, staging environments, and deployment pipelines than on broad automated test coverage.
- This is one of the places where I would be candid in a portfolio: the architecture is stronger than the visible test suite.
Architecture Notes
The codebase is organized around product domains rather than generic CRUD folders. The current Laravel app separates responsibilities into auth, core, and hub service namespaces, while controllers mostly act as HTTP entry points. That matters because the workflows are stateful and cross-cutting. Groups touch memberships, invitations, suggested users, posts, chat, and notifications. Interests affect onboarding, discovery, and group recommendations. Admin operations extend into content governance and policy pages.
What I found interesting is the architectural transition visible in the repo. There is an older split-service structure under a separate API area, and a newer consolidated application that still preserves domain separation internally. That is a pragmatic middle path: it reduces deployment sprawl while keeping the code modular.
Scalability decisions show up in a few important places. Pagination is used for chat history and post feeds. Realtime traffic is separated from the core API. Async AI analysis is pushed into Kafka-driven services. Vector search is combined with location filtering and interest checks instead of trying to do everything in one expensive query. Shared embeddings infrastructure is reused across AI components rather than duplicated.
What I Built
Identity And Onboarding
Purpose
Handle registration, OTP verification, login, social login, password reset, and profile setup.
Engineering challenges
This flow had to support both standard auth and social auth while preserving a staged onboarding journey. It also stores device, timezone, and location signals that later feed discovery and AI workflows.
Implementation highlights
The backend uses token-based auth, OTP verification, profile updates, and welcome-state handling. The frontend includes multilingual signup and login flows, plus location capture after authentication.
Business value
This turns registration into a richer starting point for matching and community discovery rather than a thin account-creation step.
Interest And Profile Modeling
Purpose
Represent what a user cares about and make that usable across onboarding, search, group creation, and recommendations.
Engineering challenges
Interest systems seem simple until you allow custom interests, category ownership, visibility rules, and profile updates that need to remain manageable over time.
Implementation highlights
The platform includes interest categories, user-interest mapping, support for custom interests, and logic to control who can manage them. That creates a reusable preference layer across the product.
Business value
This is the foundation for more relevant discovery and makes the rest of the platform feel intentional rather than random.
Group Lifecycle And Membership Workflows
Purpose
Support group creation, visibility rules, onboarding into groups, invitations, join requests, and member administration.
Engineering challenges
This is one of the more complex parts of the system because membership is governed by state. Private/public visibility, inviter permissions, duplicate prevention, request handling, and membership approval all have to stay consistent.
Implementation highlights
The product supports multi-step group creation, category assignment, interest tagging, suggested invitees, location capture, meeting-related fields, invitations, requests, and member views.
Business value
This is where the platform moves from “content app” to “community operations tool.”
Social Feed And Interaction Layer
Purpose
Let users publish posts, attach media, use hashtags, comment, like, and bookmark content.
Engineering challenges
Media handling, comment/like consistency, group-context posting, and growing query costs all matter once engagement increases.
Implementation highlights
Posts support media and thumbnails, hashtags were moved toward JSON-friendly handling, feeds are paginated, and interaction counts are computed in a way that is more scalable than naive per-item queries.
Business value
This gives communities a persistent activity layer and creates the behavioral signals that power downstream recommendations.
Realtime Messaging And Notifications
Purpose
Enable group chat and lightweight operational alerts.
Engineering challenges
Realtime systems are not just transport problems. They also need permission checks, pagination, storage, mention parsing, and user-specific delivery.
Implementation highlights
Group chat is backed by stored messages, media support, mention token resolution, and notification broadcasting through private channels. Notifications are persisted, queryable, markable as read, and broadcast in realtime.
Business value
This supports actual coordination, not just passive browsing.
AI-Assisted Discovery And Recommendations
Purpose
Use user behavior and context to improve discovery of people and groups.
Engineering challenges
The hardest part here is connecting AI to product workflows responsibly. Activity signals are generated asynchronously, embedded, stored, and later used by a separate conversational and recommendation layer.
Implementation highlights
The Laravel API emits Kafka events for posts, likes, and comments. A Python intention service classifies behavior, generates embeddings, and stores vectorized intent records in PostgreSQL with pgvector. A separate AI agent uses location, interests, vector search, and a state-graph workflow to return matched users and groups. Audio transcription is also integrated into the chat experience.
Business value
This turns the platform from a static directory of users and groups into a discovery system that can adapt to what people actually do.
Admin Operations And Policy Content
Purpose
Give operators a way to manage users, groups, posts, interests, and public-facing policy or footer content.
Engineering challenges
Operational systems often get ignored in portfolio writeups, but they are where real ownership shows. Admin permissions, document uploads, and content organization have to be secure and maintainable.
Implementation highlights
The separate admin app includes user, post, group, interest, category, and footer document management. The backend also includes admin auth and dedicated services for managing public legal and contact content.
Business value
This makes the platform operable by a non-engineering team and reduces reliance on code changes for routine updates.
Key Engineering Challenges
One challenge was workflow complexity. Groups are not just rows in a table. They carry interests, suggested members, visibility rules, invitations, requests, memberships, chat, and sometimes meeting metadata. The platform design reflects that by moving logic into domain services instead of leaving it buried in controllers.
Another challenge was mixing synchronous product features with asynchronous intelligence. Posts, comments, and likes need immediate transactional consistency, but behavioral interpretation and semantic ranking belong in a separate pipeline. Kafka, vector storage, and standalone AI services are a reasonable answer to that split.
A third challenge was keeping discovery relevant without making it opaque. The platform uses multiple signals such as interests, location, prior activity, and conversational queries. The AI services do not replace the product model; they sit on top of it.
The final challenge was operational evolution. The repo shows signs of moving from a more fragmented service model toward a consolidated but still modular backend. I like this because it reflects a real engineering tradeoff: reduce deployment overhead without giving up domain boundaries.
Outcome
The platform matured into a fairly complete community system rather than a narrow feature app. It supports registration, onboarding, interest capture, group creation, invitations, join workflows, content posting, realtime chat, notifications, admin management, legal-content operations, and AI-assisted discovery.
Verification was focused on end-to-end user flows, regression checks, and manual staging validation.
Why This Project Matters
This project matters in my portfolio because it shows the kind of engineering work I enjoy most: cross-functional systems where product design, workflow modeling, architecture, and delivery leadership all matter at once.
What makes it particularly important to me is the balance between project leadership and hands-on contribution. I was involved in shaping the direction of the product while also working directly in backend API areas where the complexity was real. That combination says a lot more about how I work than a narrowly scoped feature project would.
It also demonstrates that I can operate across multiple surfaces at once: public product, admin tooling, backend systems, and AI-enabled services. I value projects where the engineering story is tied closely to the product story, and this is a strong example of that.
What I Learned
This project reinforced how important it is to model workflows, not just entities. Users, groups, and posts are easy to name. Invitations, requests, approvals, recommendations, and operator workflows are where architecture starts to matter.
It also taught me that AI features are most useful when they are grounded in strong product structure. The vector pipeline and conversational layer work here because the underlying system already has interests, location, memberships, and activity signals to build on.
Just as importantly, it reminded me that leadership works best when it stays close to implementation. Being involved in backend API work while leading the project helped keep design decisions practical, grounded, and easier to align across teams.