Skip to content
innoverse
← All work
Talent sourcingDACH

Pluto: from a stuck MVP to a sourcing platform that scaled

A DACH talent-sourcing platform — working MVP, no scale. The collection pipeline and the API rebuilt in sequence, while the product kept running.

Leads
01Collection
Snapshot
02Search API
Recruiter
FIG. 01 — The pipeline, with the two bottlenecks marked where they sat.

Context

Pluto (plutoapp.ch) was a talent-sourcing platform for the DACH market. A recruiter defines the role — skills, experience, location — and the platform finds matching candidates. Its edge was the data: instead of querying third-party sources live, Pluto searched its own continuously refreshed snapshot of public professional profiles, with every person unified into a single profile even when they appeared on several platforms.

When we joined, the MVP was real and working — and stuck. The pipeline that kept the data fresh was too slow, and the search API strained under exactly the load the product needed in order to sell.

FIG. 02 — Same person, four platform listings — unified into one profile by unique source keys.
The work

Scaling is bottleneck-ordering.

We took the bottlenecks in sequence — and once collection kept up, the truth moved: the API was the next constraint.

01

Collection

The pipeline that turned third-party leads into owned, refreshed profile data — rebuilt so the snapshot stayed current instead of aging behind the market.

02

The API

Rather than patch the aging Express/MongoDB monolith once more, we rebuilt it as LoopBack 4 — TypeScript end to end, a typed profile schema, OpenAPI, multi-tenant firms and roles, PostgreSQL alongside MongoDB.

Identity became a data-layer guarantee — unique keys per source profile, so one person stayed one profile no matter how many platforms listed them. The platform came out as three services with clean seams: API, collection, and orchestration, each replaceable without touching the others. All of it shipped while the product kept running.

Before1 SERVICE
Express monolith
MongoDB
After3 SERVICES
API
Collection
Orchestration
MongoDB
PostgreSQL
FIG. 03 — One monolith became three services behind seams — the data layer split by workload.
The hardest call
Replacing the API mid-flight instead of patching it once more. Slower for a month; faster every month after.

The result

The business case was never technical. A sourcing product is its data freshness — a pipeline that lags and an API that times out don't lose milliseconds, they lose deals. After the rebuild, recruiters ran searches that returned in usable time over a fresh, deduplicated talent snapshot, and the firm-and-roles model made the product sellable to teams rather than individual seats.

The platform ran publicly for years after the engagement ended.

Firm
Supervisor
Manager
Recruiter
FIG. 04 — Firms and role-scoped seats: the multi-tenant model that made teams the customer.
TypeScript, Node.js, LoopBack 4, MongoDB, PostgreSQL

If your demo works and your scale doesn’t.

This is the work Build exists for.

Talk to us