Vixiaa is a specialized marketplace connecting pharmaceutical, biotech, and life sciences companies directly with vetted independent consultants — across disciplines like statistical programming, toxicology, clinical operations, regulatory writing, CMC, medical affairs, and digital health.

The client's brief was clear and deliberately unusual for this space: no escrow, no platform-managed payroll, no middleman. Companies and consultants negotiate and pay each other directly. Vixiaa's job is purely to be the best possible place to find the right expert — fast, filtered by real domain specialization rather than generic keyword search, and trustworthy enough that a pharma company will hand a consultant real project details on the first message.

I was brought on as the sole full-stack developer to design and build the platform from the ground up: architecture, database schema, backend APIs, and the entire frontend experience for two very different user types — pharma companies posting needs, and consultants building a professional profile.

Life sciences is not a generic gig-economy vertical. A few constraints shaped every decision:

Two distinct onboarding flows. A pharma company signing up is trying to describe a project need; a consultant signing up is trying to represent 10–20 years of deep, credential-heavy expertise (therapeutic areas, regulatory bodies worked with, GMP experience, trial phases, etc.). These couldn't share a single generic "create account" form without losing signal on both sides.

Discovery had to be precision-first. With specializations as narrow as "Alliance Management and Strategic Partnership" or "CMC Regulatory," a company searching for help doesn't want a ranked list of loosely-related freelancers — they want to filter down to the two or three people in the world who actually fit.

Trust without a payment layer. Since Vixiaa deliberately stays out of the money flow, the platform's credibility has to come entirely from profile depth, vetting signals, and a frictionless path from "found the right person" to "started talking."

It had to scale from zero. Launching a two-sided marketplace means the consultant side and the demand side grow at different rates — the architecture needed to stay lean and cheap to run early on, while being ready to scale search and data volume as the consultant directory grew.

Rather than free-text search, I designed a structured skill/specialization taxonomy in PostgreSQL — each consultant is tagged against defined specialization entities (Statistical Programming, Toxicology, Business Development, Regulatory Writing, Medical Affairs, AI/ML, and dozens more), each with its own description and consultant count. This became the backbone of the "Find Consultants" experience: company users can browse by area of expertise and drill straight into a filtered, relevant shortlist instead of sifting through an undifferentiated directory.

This was the piece I'm proudest of. Getting the data model right here mattered more than any UI polish — it's what turns "a list of freelancers" into "a marketplace that actually understands life sciences."

Two separate sign-up paths — Join as Pharma and Are you a consultant — feed into distinct profile schemas and permission sets on the backend, while sharing a single authenticated session layer. Pharma accounts are built around posting needs and browsing/searching; consultant accounts are built around building a credibility-dense profile that surfaces well in search.

Using Next.js and React, I built a fast, server-rendered marketing and directory experience — clean specialization pages, a "How It Works" flow explaining the direct-engagement model, and a search interface that filters consultants by specialization instantly. Speed and clarity mattered here more than flashy interaction design: the users are pharma executives and senior consultants, not power users of software.

The backend exposes the APIs powering search/filtering, profile management, authentication, and content for static informational pages (FAQ, About, Terms) — kept deliberately simple and stateless so it could be deployed and scaled independently of the frontend.

The application is deployed on AWS, with the Node.js API and Next.js frontend running as separate services and PostgreSQL as the system of record for consultants, companies, specializations, and their relationships. Keeping these layers decoupled was intentional — it lets the frontend, API, and database each scale or get optimized independently as usage patterns become clearer post-launch.

The core technical challenge was the consultant search and matching logic — not because filtering by a tag is hard in isolation, but because the taxonomy itself had to support real-world nuance: specializations overlap (a Clinical Operations consultant might also cover Medical Monitoring), some categories are brand-new and sparsely populated, and the schema needed to stay flexible enough that new specializations could be added without a migration every time the client identified a new niche in the market.

I solved this by modeling specializations as their own first-class entities in PostgreSQL — each with a stable identifier, its own description, and a many-to-many relationship to consultant profiles — rather than hardcoding categories into the consultant table. That decision paid off immediately: it meant search-by-specialization, specialization landing pages, and "consultant count per skill" could all be derived from the same clean data model instead of three separate ad-hoc implementations. It also means the client can add or refine specializations as the industry's needs shift, without touching application code.

Vixiaa is live in production, serving both sides of the marketplace — pharma and biotech companies searching for specialized talent, and consultants building profiles across 45+ life sciences specializations. The architecture decisions around a decoupled Next.js/Node/PostgreSQL stack on AWS were made specifically so the platform can keep adding specializations, refine search relevance, and scale the consultant directory without needing a rebuild.