About JUNI
JUNI is a non-profit science-startup ecosystem in Berlin. We run our programmes across seven SaaS tools — newsletter, events, community, CRM, forms, applications, coworking — and a Postgres database underneath that is meant to be the single place a person exists.The database is the part we care about. One resolved record per person and per company, one append-only row per interaction, and a deterministic way of deciding which person a given payload belongs to. Its purpose is to make the path from first touchpoint to milestone measurable. The connective layer between the tools and that database is the work.
Your mission
Build the layer that connects our systems to one database, in both directions, and help us get the model right as we go.The shape of the data is mostly decided, and each new system will test it. Sources disagree about what counts as one person, when something happened, and whether they'll tell you about it twice. Working that out — and knowing when the model has to change to accommodate a source, rather than being bent around it — is the substance of the job.
We're looking for someone who can think that through with us and make a case for a particular design, not only build what's specified.
Your profile
Scope| Inbound | Each system into the database. Several pipelines per system — sources report a lot of different things. Identity resolution |
| Outbound | Some state originates with us rather than with a tool. The database decides and pushes to whichever platform executes it. |
| Keeping both honest | Platforms report back and sometimes contradict us. Nobody who opted out may be re-added. |
| Reporting | KPI data has to reach a BI tool. Getting it there is part of the job; building the dashboards is not. |
| Search | Making the lake queryable in natural language. |
| Documentation | Decisions written down, pipelines in github. |
Not in scope
- Front-end. There is none and none is planned.
- Integration against third-party APIs and webhooks, at depth: pagination, retries, signature verification, rate limits, undocumented payload shapes, late and out-of-order events, sources that fire on every change and won't say what changed.
- Bidirectional sync between systems that both think they own a field — loop prevention, echo suppression, an explicit answer to who wins on conflict.
- Postgres as an application database, not just a destination. plpgsql functions, triggers, constraints and RLS used to enforce rules at the write path. If your SQL experience is transformations downstream of the load, this is not the right fit.
- Idempotency as a habit rather than an afterthought. A pipeline that re-runs and changes nothing is the acceptance test.
- Git discipline — migrations, PRs, review.
- Working with personal data under GDPR, and understanding why that constrains what gets ingested at all.
- Written English. Most of the work is async, and what you build has to be legible to someone who wasn't there.
n8n or another orchestrator · Supabase · relevance work on a search index — Elasticsearch, OpenSearch, Meilisearch or similar; cluster operations are not the part we need · experience as the only person on a system · German.
We offer
How we workRemote and mostly async, but not silently so — expect real conversations, especially early, while you get your head around the systems and how they fit together.
Engagement
Freelance, starting as soon as possible. Three months to begin with; we'll see what's needed after that.
Berlin or remote within the EU.