Deepak Kumar Jha
SmartSitting — Building an AI-native childcare marketplace from zero on GCP
SmartSitting · Dec 2025 – Present · Full role details →
The Problem
SmartSitting needed a childcare placement marketplace that could match families and institutions with vetted candidates — with no existing platform, no existing infrastructure, and a small team. The business bet was that AI-assisted matching and support could do the work a much larger operations team would otherwise need, from day one rather than as a later optimisation.
Constraints
- A 4–5 engineer team owning the entire surface area at once: the public web app, the admin platform, candidate and institution onboarding, and a mobile app.
- Zero inherited infrastructure — domain, email, CI/CD, deployment pipeline and payment gateway all had to be stood up from nothing, not migrated.
- AI features needed to be production features with a support burden, not a demo — matching quality and generated text both needed a correction path when they were wrong.
- Any system touching applicant and institution data had to be self-hostable in principle, since childcare data is exactly the category regulators and parents are most sensitive about.
Architecture
The stack splits into a conventional application layer and a separate AI service layer, deliberately kept apart so the AI half can be iterated on, retrained against or swapped without redeploying the product:
Web & mobile clients
The public marketplace, the admin platform and the mobile app, each talking to the API layer over REST.
Core API (Node.js / Express, MongoDB)
Owns accounts, listings, applications and the payment integration; deployed on GCP with zero-downtime rollouts.
Gemini-powered features
Chat automation and an AI-driven profile suggestion and review engine, called from the core API for user-facing generation tasks.
RAG agent service (Node.js / Express, MongoDB)
A separate service that embeds queries with Ollama (nomic-embed-text), retrieves from a Qdrant vector index kept in sync with MongoDB, and generates answers with a self-hosted Llama 3.1 model — semantic search over SmartSitting’s own data without sending it to a third-party model provider.
Key Decisions & Trade-offs
Split the AI service from the core API on day one
The RAG agent is its own deployable with its own database sync job, not a module inside the main API. It costs an extra service to operate, but it means a bad model change, a Qdrant re-index, or an experimental prompt can ship without touching the code path that handles payments and applications. At a 4-person engineering team this separation is easy to skip for speed; I kept it because the alternative — one service where "improve the AI answer quality" and "don’t break checkout" compete for the same deploy — gets more dangerous as the team grows, not less.
Self-hosted inference for the retrieval layer, hosted APIs for generation-facing features
Chat automation and the review engine — user-facing, latency-sensitive, and not touching applicant PII beyond what the user already typed — use Gemini. The RAG agent, which retrieves and reasons over the platform’s own candidate and institution data, runs on Ollama-hosted models instead. That is a cost and control trade-off, not a capability one: self-hosted inference is slower per token and needed its own ops burden (Qdrant, model updates), but it keeps the data class most people are protective of, off a third party’s servers.
Own the full deployment path instead of outsourcing it to a PaaS
CI/CD, zero-downtime rollouts, domain, email and payment gateway integration were all built rather than bought as a managed platform. Slower in week one; it meant no vendor lock-in on the piece of the stack most likely to need custom behaviour later (webhook handling, blue-green rollouts around the AI services specifically).
Outcome
- Shipped Gemini-powered chat automation and an AI-driven profile suggestion and review engine.
- Contributed to 3x growth in weekly candidate applications.
- Full GCP infrastructure — CI/CD, zero-downtime deploys, domain, email and payment gateway — owned end to end by a 4–5 engineer team.
What I'd Do Differently At Greater Scale
At meaningfully higher query volume, the RAG agent’s sync-from-MongoDB step is the part I’d revisit first — it is currently a good fit for the platform’s current write volume, but a higher-throughput marketplace would need either a change-stream-driven incremental sync or a queue in front of the Qdrant writes to avoid the index lagging the source of truth under load.