Meetvo: Building a Text-First Professional Network for Tech Talent

Meetvo started with a simple question: could professional networking for technology talent be more useful if it focused on the things that actually matter to a person's career?

Most social platforms are designed around consuming content. Professional networks are not necessarily much different. Profiles exist, but the experience often becomes dominated by feeds, media, engagement metrics, and general social activity. I wanted to explore a different model.

Meetvo was designed as a text-first professional network specifically for technology professionals and recruiters. The focus was professional identity, technical knowledge, conversation, and opportunities. I eventually deployed the project as a live product at meetvo.me. I later stopped developing it and chose not to renew the domain, but the application remains available through its Vercel deployment.

The Product Idea

The central idea behind Meetvo was that a technology professional should be able to represent their career without needing to construct that identity across several different platforms.

A profile could contain employment history, academic history, projects, portfolio links, a CV or resume, and a professional description. That profile was publicly accessible and intended to function as a digital CV. The profile therefore became more than a username and a biography. It was the foundation of the professional identity within the platform.

Why Text-First?

One of the most deliberate decisions was making Meetvo text-first. There were no image uploads or file-sharing features. Posts were short, text-based micro-posts with a maximum length of 100 words.

This was intentional. The product was not designed to compete for attention through photographs, videos, or increasingly elaborate media. The idea was that technology professionals should be able to share technical ideas, opinions, lessons learned, career experiences, questions, and observations without needing to turn every contribution into a piece of media.

That constraint also simplified parts of the system. There was no need to build media storage, image processing, file upload infrastructure, or content delivery around user-generated media. The product could stay focused on text and the relationships between users.

Two Types of Users

Meetvo was designed around two primary types of users: techies and recruiters, each with different reasons for using the platform.

A tech professional needed a place to represent their career, participate in technical conversations, discover opportunities, and connect with other professionals. A recruiter needed a way to discover talent, understand someone's background, publish opportunities, and start conversations. This distinction influenced the application's data model and product workflows. Authentication was therefore not simply about creating an account. The platform needed to understand what role the user played within the professional network.

The Profile as a CV

The profile was probably the most important part of Meetvo. Instead of treating a profile as a short social biography, I wanted it to contain enough structured information to function as a digital CV.

Users could provide a profile description, employment history, academic history, projects, portfolio links, and externally hosted CV links. This created a structured professional identity. A recruiter looking at a profile could get a much better picture of someone's background without requiring the user to maintain a completely separate professional profile somewhere else.

The approach also meant the profile data had to be modeled more carefully than a typical social profile. Employment history and academic history are structured information. Projects have their own context. A portfolio link is different from a post. A CV is different from a short biography. Those distinctions became part of the backend model.

Professional Conversation

The profile represented someone's career. Posts represented what they were thinking about. Meetvo introduced short-form text posts that allowed users to share technical and professional ideas. Posts could be liked and commented on, and users could follow one another, with following creating a personalized feed of posts from people a user had chosen to follow.

This created the social component of the platform without making social activity the entire purpose of the product. The intended relationship was professional identity leading to professional conversation leading to professional connections, rather than simply content leading to engagement leading to more content. That distinction was central to the product concept.

Following and the Network

A professional network needs relationships between people. Meetvo allowed users to follow one another, and following created the basis for a personalized feed and let users keep up with the technical thoughts of people they were interested in.

This also meant the backend needed to model relationships between users rather than treating every profile independently. The system had to account for who follows whom, which posts belong to which users, which posts should appear in a user's feed, engagement with posts, and profile visibility. These are relatively straightforward concepts individually, but together they form the foundation of a social graph.

Connecting Talent With Recruiters

The other half of the product was hiring. Recruiters could create job postings and active hiring roles. Techies could discover those opportunities and apply to jobs directly. Recruiters could then review applicants through their profiles.

This was important because the profile-as-CV concept and the job board were designed to work together. A recruiter did not simply receive an application detached from the rest of the platform. The application could lead back to a professional profile containing the person's experience, academic history, projects, portfolio, and other professional information. The goal was to reduce the distance between who someone is professionally and the opportunity they're applying for.

Messaging

Meetvo also included direct messaging. Recruiters could initiate conversations with techies, while techies could communicate with other techies. There was an intentional limitation around messaging: the platform did not support media or file sharing. Recruiters could also close conversations to prevent further messages.

That constraint was partly about keeping the platform focused and partly about reducing opportunities for unwanted communication. The messaging system was intended to facilitate professional conversations, not become another general-purpose chat application.

Keeping the Product Free

Meetvo was designed as a free platform. There were no paid plans and no hidden fees. This was consistent with the original goal of reducing friction for both sides of the network. A technology professional could create a profile and look for opportunities without paying. A recruiter could use the platform to discover and communicate with talent without immediately encountering a subscription wall.

Whether that was ultimately the right business model is a separate question. At the product stage, the priority was reducing the barrier to participation and seeing whether the network itself could become useful.

Building the Backend

The backend was built with Node.js, Express.js, and PostgreSQL, using a structured backend architecture with separate models, migrations, and application logic. The database needed to represent several interconnected areas: users, profiles, employment history, academic history, projects, posts, followers, comments, likes, messages, jobs, and applications.

This made Meetvo a useful backend engineering exercise because it combined several common application patterns into one system. It wasn't simply CRUD around a single resource. The relationships between those resources were what made the application useful.

Building Around Relationships

One of the more interesting parts of Meetvo was that much of the product value came from relationships. A user has a profile. A profile contains professional history. A user creates posts. Other users follow that user. Followers see those posts. Recruiters discover profiles. Recruiters create jobs. Techies apply to jobs. Recruiters review applicants. Users communicate through messages.

The system therefore became a network of connected entities rather than a collection of independent features. This affected how I thought about the database and API design. The backend needed to preserve those relationships while still keeping the individual application areas manageable.

Designing the Experience Around Constraints

A lot of Meetvo's product decisions were actually constraints. Text only. No image uploads. No file sharing in messages. Posts limited to 100 words. Public professional profiles. Separate recruiter and techie roles. External links for CVs and portfolios.

These restrictions were intentional. The product was trying to answer a specific question rather than become a general-purpose social network: what happens when a professional network deliberately removes some of the things that normally compete for attention and focuses instead on professional information and conversation? Meetvo was an experiment around that idea.

What I Learned From Building It

Meetvo taught me that product design and backend architecture are closely connected. A seemingly simple product decision can create significant implications for the backend. Making profiles function as CVs creates structured professional data. Adding followers creates a social graph. Adding a personalized feed creates aggregation and relationship queries. Adding jobs introduces another set of relationships between recruiters, positions, and applicants. Adding messaging introduces conversation state and access rules. Making the product text-only removes an entire category of infrastructure. The architecture followed the product decisions.

The Product Was More Than a Prototype

Meetvo eventually moved beyond the idea stage. I deployed it publicly at meetvo.me and made it available as a functioning product. That was important, because many of the assumptions behind a product like Meetvo are difficult to validate purely through development. A working application lets you discover whether people actually want the thing you built.

The deployment also forced the project through the less glamorous parts of software development: production configuration, database deployment, authentication, frontend and backend integration, deployment management, domain configuration, and handling real users and real application flows. Those experiences were valuable independently of whether Meetvo ultimately became a lasting product.

Why I Stopped Working on Meetvo

Eventually, I lost interest in continuing Meetvo. The project had reached a point where I was no longer motivated to keep developing the product, and other work became more important. Rather than keeping the domain active indefinitely, I decided not to renew meetvo.me. The application itself remains functional through its Vercel deployment, but the original public domain is no longer maintained.

This was not a technical failure. The software worked. It was a product decision. At some point, maintaining a product requires more than the ability to keep writing code. There needs to be enough reason to continue investing time into it. For Meetvo, I eventually decided my time was better spent elsewhere.

The Value of Abandoning a Project

Stopping a project can be as useful as completing one. Meetvo gave me an opportunity to take a product from an idea through design, implementation, and deployment. It also showed me what happens when interest moves elsewhere.

There's a natural tendency as a developer to measure a project by whether it's still running. I think that's too narrow. A project can still provide value after it has stopped operating. The technical decisions remain useful. The product experiments remain useful. The mistakes remain useful. And the experience of taking something all the way to deployment remains useful. Meetvo became one of those projects for me.

What I Would Carry Forward

Several ideas from Meetvo continue to influence how I think about products.

The first is that constraints can improve a product. Removing functionality is sometimes more useful than adding it. The second is that professional identity benefits from structured information. A profile becomes much more useful when employment, education, projects, and other career information are represented explicitly rather than hidden inside one large text field. The third is that different users can need very different workflows even when they participate in the same platform. Techies and recruiters both used Meetvo, but they didn't have the same goals, and the backend and product design had to account for that difference.

Conclusion

Meetvo started as an experiment in building a different kind of professional network for technology talent. It combined structured professional profiles, technical conversation, networking, messaging, and hiring into a text-first platform. I designed and built the product, deployed it publicly, and learned from taking it beyond the development environment.

It eventually became a project I chose to stop investing in. I did not renew the domain, and the public service was discontinued, although the application remains available through its Vercel deployment. The project did not become the long-term product I originally imagined. But it gave me something useful. It taught me how product constraints shape architecture, how professional identity can be modeled as structured data, how social relationships affect backend design, and what it means to take an idea all the way to a functioning product.

Meetvo was an experiment. And like many useful experiments, its value did not depend on becoming permanent.