Influencer marketing and creator economy · Case study
US influencer marketing startup: A two-sided influencer marketplace with messaging, deals, ads and back-office
Marketplace platform case study: creator discovery, in-house real-time messaging, collaboration offers, an ad server and an operations console on Next.js, Node and MongoDB.
- Client
- A US-based platform where brands discover creators, negotiate deals and pay them.
- Team
- 4 engineers, 1 designer, 1 project manager
- Timeline
- 8 months to launch, then ongoing feature work
- Services
- Web development, Enterprise software, Cloud and DevOps, UI/UX design
- 212
- Features across 32 modules
- 230+
- API endpoints behind shared auth and validation
- 56
- Front-end screens including 23 admin screens
- 182
- Pages of in-repo technical documentation
In short
A US influencer marketing platform needed one product instead of five tools: creator discovery with real follower data, direct messaging with receipts, structured collaboration offers, subscription metering and an ad system. We built the public app for brands and creators, public profile pages and a 23-screen operations console on Next.js 14, Node.js, MongoDB and Redis, with 32 modules, 212 features and 230+ API endpoints.
Where they started.
- Influencer marketing runs on conversations that are hard to industrialise, and off-the-shelf tools each cover one slice
- Discovery, messaging, deals, subscriptions and advertising had to work on one identity, one permission model and one set of messaging rules
- The operations team needed to import creator lists in bulk, review every profile before it went live and run outreach campaigns
- Bulk imports and campaigns cannot run inside a web request, yet users expect to watch them progress
The approach.
- One Node.js/Express API holding every module behind shared authentication and validation, and one Next.js app serving the marketing site, brand and creator apps, public profiles and the admin console
- A self-built WebSocket messaging layer with typing indicators, delivered and read receipts, presence and unread counts, replacing a third-party chat dependency
- Structured collaboration offers with per-platform terms, expiry dates, accept and reject with recorded reasons, and email plus SMS notifications
- An ad system with two formats, targeting by geography, follower band, profile type, interest or named accounts, CPM and CPC pricing, frequency capping and fraud checks
- Queued background processing for Excel imports and outreach campaigns with live progress pushed to the browser and recovery for stalled runs
- A moderation queue with a reason taxonomy and an audit trail so no profile reaches the public app unreviewed
What shipped.
- Phone-first authentication with one-time passcodes, separate brand and creator onboarding and bot protection
- Creator discovery with filters, sorting, mobile filter sheets and Excel export
- Real-time messaging with media sharing, quotas and per-user preferences
- Ad manager back-office with analytics, impression logs and creative upload
- Stripe subscriptions with metered message and outreach quotas renewed nightly
- Link-in-bio public pages, TikTok OAuth and Instagram data collection with scheduled refresh
- Bulk creator import, import logs, admin reporting by city, country and category, and a CMS for marketing pages
- Eight scheduled workers, CRM sync to Pipedrive, referrals, notifications and 182 pages of documentation
How the engagement ran.
Context
Brands finding creators, talking to them, agreeing deals and paying them is usually done across a CRM, a mail tool and a spreadsheet. This platform had to be one product instead of five: creator discovery with real follower data, direct messaging with delivery receipts, structured collaboration offers, subscriptions that meter how much outreach each account gets, and advertising that monetises the audience the platform already has.
Behind the public product, an operations team needed to import creator lists in bulk, review every profile before it went live, run outreach campaigns and answer questions about what happened by city, category and day. All of it had to share one identity model and one set of permissions.
What we built
- Phone-first sign-up with one-time passcodes, separate brand and creator journeys, guided onboarding and Cloudflare Turnstile bot protection
- Three roles enforced in API middleware and at the front-end edge, JSON-schema validation on write endpoints and rate limiting at three levels
- Discovery with keyword search, channel, demographic, interest, follower-range and brand-category filters, card, list and detail views and Excel export
- Messaging on authenticated Socket.IO connections with conversation rooms, twelve event handlers, heartbeat handling and quota banners
- Collaboration offers, an ad manager and an ad server with placement targeting on the link-in-bio and search pages
- Stripe plans, subscriptions and webhooks, message quotas with nightly renewal, profiles, link-in-bio customisation, TikTok OAuth and Instagram scraping
- Bulk messaging campaigns with SMS and email bodies, opt-out compliance, moderation, bulk import with row-level errors, admin reporting, CMS pages, announcements, referrals, notifications and support
Architecture and stack
| Layer | Technology | Why |
|---|---|---|
| Frontend | Next.js 14 App Router, TypeScript, Redux Toolkit, Material UI, Tailwind, React Hook Form and Zod, Quill, Socket.IO client | One app serves marketing, brand, creator, public profile and admin surfaces |
| Backend | Node.js, Express, Passport JWT, AJV, Socket.IO, Winston, node-cron | Every module follows the same routes, controller and validation shape |
| Data | MongoDB with Mongoose across 39 models, Redis | Profiles, targeting rules and campaign filters are document-shaped and change often |
| Infrastructure | AWS Elastic Beanstalk with nginx, CodeDeploy, Node 22, GitHub Actions | Scripted deployment with separate development and production environments |
| Integrations | Stripe, Twilio, SendGrid, SMTP and IMAP, S3, SES, SNS, Lambda, Pipedrive, TikTok OAuth, Cloudflare Turnstile | Payments, messaging, storage, serverless scraping and CRM without bespoke builds |
The product is deliberately one API and one web app. For a domain this interconnected, where nearly every screen touches users, subscriptions and messaging at once, a single deployment story and identity model is the right trade. The three hard parts were messaging (getting the connection lifecycle right, not just the happy path), bulk work users watch (imports and campaigns as queued jobs with progress streamed back) and the ad server (resolving targeting in real time, recording impressions fast, and separating unique from repeat views with pre-computed daily aggregates).
How we worked
Code standards are enforced rather than suggested: ESLint on an Airbnb base with Prettier runs automatically on every commit. A custom security scanner blocks known code-injection patterns before a push lands and runs again in CI on every pull request. Security is layered in the application with headers, three levels of rate limiting, schema validation, bot protection on public forms and encryption for sensitive fields. Deployment is scripted, and a health endpoint reports database state rather than just answering up.
The engagement closed with 182 pages of in-repo documentation covering architecture, every module, every data model and every integration, written so the client's own team can pick the codebase up without us in the room.
Scale and complexity
| Measure | Figure |
|---|---|
| Modules / features | 32 / 212 |
| API endpoints | 230+ |
| Data models | 39 |
| Front-end screens / admin screens | 56 / 23 |
| WebSocket event handlers | 12 |
| Scheduled background workers | 8 |
| Third-party integrations | 11 |
| Documentation | 182 pages |
What this means for your project
Two-sided platforms live or die on the operations side that users never see: moderation, imports, campaigns and reporting. Budget for the console from the start, and design bulk work as background jobs with visible progress. The public app is the smaller half of the build.
We scope marketplaces in a one to two week discovery and deliver them with a fixed-price MVP or a dedicated team, with the documentation handed over as part of the work.
What changed.
- A complete advertising system delivered: creation, targeting, serving, tracking, fraud checks and daily analytics
- Self-built real-time messaging with 12 server-side event handlers replaced a third-party dependency
- Eight scheduled background workers keep follower data, subscriptions, quotas, campaigns and ad states current without manual intervention
- 11 third-party integrations for payments, SMS, email, storage, serverless processing, CRM, social login and bot protection
Questions about this project.
Can you build a two-sided marketplace like this for us?
Yes. Marketplaces with messaging, deals and subscriptions are a recurring shape in our work. Expect a discovery sprint, then an MVP in the $50k to $150k range depending on how many of these modules you need at launch.
Why build messaging in-house instead of using a chat service?
This client started on a third-party conversation service and outgrew it. Owning the WebSocket layer gave them receipts, presence, quotas and progress streaming on one connection, without per-message costs.
How do you keep long-running jobs from breaking?
Imports and campaigns run as queued jobs with per-minute workers, live progress over WebSockets, a recovery job for stalled runs and a lock against overlapping executions.