Visit us: risicare.ai
Drop your CV
[email protected]
,
[email protected]
Observability Platform Engineer
Role: Backend + Data Infrastructure + AWS/DevOps
Experience: 2-5 years
Location: Remote / (
Hybrid - Bangalore / Delhi)
Compensation: INR 12 LPA - 20 LPA
- ESOP*
Read this part first
We're building an observability platform for teams running LLMs in production - traces, spans, token cost, latency, eval scores. The stuff that tells you why your AI application did what it did, instead of leaving you to guess from logs.
We are pre-launch. Zero paying customers today.
The pipeline is built and hardened; the product surface is not. That's the honest state of things, and it's the most significant thing to know before you read further.
You'd be the first engineering hire. Founder plus you.
If "no customers yet, first engineer, you'll own the platform" reads as a risk to avoid, this isn't your role, and there's no hard feelings in that. If it reads as the interesting part, keep going.
What you'd actually own
You own the platform end to end. Not a service within it. The platform.
The ingestion path.
Customer SDKs send us spans. A Rust gateway takes them, Redis buffers them, ClickHouse stores them. Every stage of that has to hold up when things go wrong – because "we dropped your traces" is the one failure an observability vendor doesn't get to have.
The query path.
ClickHouse, holding span data that has to stay fast as it grows. High-cardinality queries over a lot of rows. This is where the product either feels good or doesn't.
The control plane.
Python/FastAPI over Postgres - organisations, projects, API keys, roles and permissions, audit logging. Multi-tenant, so the isolation has to be genuinely correct rather than approximately correct.
The dashboard.
Next.js/TypeScript. Where customers actually see their traces.
The infrastructure.
AWS. Deploys, IaC, CI/CD, cost, uptime.
Some weeks you're tuning a ClickHouse query. Some weeks you're in Terraform. Some weeks you're building the UI a customer will look at tomorrow. If that range sounds like too much rather than the appeal, that's useful information.
What this role is not
It's not an enterprise observability role.
Most jobs with this title mean: run Datadog or Splunk or Dynatrace, wire up dashboards, watch someone else's systems. That's a real skill set. It's not this one.
Here,
observability is the product
. You'll be on the other side of it - building the ingestion pipeline, the storage layer, and the SDKs that other engineers instrument their systems with. We care that you understand traces and spans as a data and systems problem
, not that you've administered a monitoring vendor's console.
What we need you to already have
- Python/JS in production. Real backend services - async, FastAPI or similar. Not scripts, not notebooks.
- SQL you're genuinely good at, and Postgres in production. Schema design with performance in mind, not just querying.
- Docker, and AWS you've actually operated. EC2, IAM, VPC basics, S3. You've deployed something and been responsible when it broke.
- Terraform and CI/CD discipline. Infrastructure in version control, reviewed like code. GitHub Actions or equivalent.
- Observability fluency at the data-model level. You can explain what a span is, how traces get assembled, what OTLP is for, why cardinality matters. OpenTelemetry graduated as the industry standard this year - you should be conversant in it and interested in where it's going.
- A reliability instinct. You think about failure modes before you're forced to. You've been on the wrong end of a production incident, and it changed how you build.
- 2–5 years of professional experience , with a production codebase you can talk about in real detail.
What helps but isn't required
- Rust
- our ingestion gateway is written in it. Already built, so you don't need this on day one. If you have it, that path becomes yours faster.
- ClickHouse or any columnar/OLAP store. Rare enough that we're not gating on it. If you have strong Postgres and real curiosity about analytical query performance, we'll get you there.
- Go , for high-throughput systems work.
- TypeScript / Next.js – you'll touch the dashboard regardless, but you don't need to arrive fluent.
- Redis, Kafka, or event-driven / streaming systems.
- Kubernetes and Helm – matters when we ship self-hosted for enterprise customers. Not where we are today.
- Open source contributions, SDK or client-library design, or prior dev-tools work.
- You've built something with LLMs and have felt firsthand how hard they are to debug. That's the problem we're solving.
How you use AI matters here Two people are building a platform. That math only works with AI genuinely integrated into how we work – and we mean directing agents through real work, reviewing their output critically, knowing when to trust them and when the answer is quietly wrong.
We'd rather see how you actually use it than read that you do. If you've built an agent, a tool, or an LLM-powered feature – even a small side project – we want to hear about that specifically.
How we'll evaluate you
Not your résumé. Not certifications – if you have AWS SAA, CKA, or the OpenTelemetry Certified Associate, we'll note it, but none of them will get you hired or keep you out.
The process
1. A conversation about something you've built and the decisions inside it.
2. A working session with the founder
- we go through your solution together and talk about what you'd do next.
That's it. No panel rounds, no take-home you never hear about again.
What we offer
- INR 12 LPA - 20 LPA plus Equity (depending on your candidature)
- first engineer, and the equity reflects that.
- Full ownership of the platform, and a say in the product itself.
- Direct line to the founder, every day.
- Pre-launch to first customers, seen from the inside. Most engineers wait a decade for that view, and plenty never get it.
What we don't offer Process for its own sake. Layers of approval. Certainty about what next quarter looks like. A team to hide inside on a bad week.
To apply
Send us
- Something you built that made repeated work disappear - and what you'd do differently now.
- How AI actually shows up in your workflow. Specifics, not a claim.
- Any agent, LLM feature, or tool you've shipped. Side projects count fully.
- A production system you've operated
- what broke, and what you learned from it.
No cover letter. A few paragraphs and links are plenty. —
Drop your CV
/
Work
/
Git
[email protected]
,
[email protected]
. See what you’ll be building: risicare.ai
©
2026 Conscience Labs Pvt. Ltd.
📌 Observability Platform Engineer (India)
🏢 Conscience Labs
📍 India