A Turkish-language care platform for families raising autistic children — combining structured daily tracking, medical document intelligence, and an AI assistant that cites the family's own history in every answer.
Client context
Needa is a product for Turkish-speaking families raising children with special needs, with a primary focus on autism spectrum disorder (ASD). Its users are parents who coordinate care across home, school, therapy, and medical settings — and the therapists and teachers who work with the same child from separate vantage points.
The platform is a full-stack web application (PWA-ready) built solo over an intensive development period, from data model and AI architecture through to the Turkish-language UI.
The operational challenge
Care for a neurodivergent child generates a continuous stream of information that nobody owns end to end:
- Fragmentation. Diagnosis reports live in one folder, therapy evaluations in another, school reports in a third. Day-to-day observations live in a parent's memory or a notes app.
- Recall under pressure. The question a parent actually asks — "he melted down at the supermarket again, what do I do?" — requires connecting today's event to a pattern that formed over months. Humans under stress do not perform that lookup reliably.
- Generic advice. General-purpose AI tools answer that question with textbook autism advice. They do not know this child's sensory profile, which strategies were already tried, or what the last therapy report recommended.
- Coordination gaps. The teacher does not see what happened at home; the therapist does not see what happened at school; the parent relays everything by hand.
The product problem was therefore not "build a chatbot." It was: capture the family's lived history in a structured way, then make that history retrievable at the exact moment a decision is being made.
Product strategy and approach
Three decisions shaped the build.
1. Structured capture before intelligence. An assistant is only as good as the substrate it reasons over. Daily observation logging was designed as a low-friction, tap-based form — arousal level, emotional state, emotional regulation, sensory sensitivity, sleep quality, nutrition routine, environment — rather than a free-text diary. Structured fields make longitudinal patterns computable; free text does not.
2. Memory as a first-class data model, not a chat transcript. The system separates three memory types, each with its own table, retrieval path, and lifecycle:
| Memory type | Holds | Used for |
|---|---|---|
| Episodic | Individual events with time, place, outcome, impact score | "What happened, and when" |
| Semantic | Extracted patterns with confidence and evidence counts | "What is generally true about this child" |
| Procedural | Named strategies with implementation and success counts | "What has actually worked" |
A scheduled consolidation job promotes raw episodes into semantic patterns and strategy records, and recomputes strategy effectiveness from follow-up observations. Effectiveness is a generated database column derived from success, partial-success, and implementation counts — the system's judgement about a strategy is arithmetic over recorded outcomes, not an LLM opinion.
3. Every claim in an AI answer is traceable. Responses carry inline citation markers that resolve to the underlying source: [E] episodic memory, [S] semantic pattern, [P] procedural strategy, [D] document. A parent can expand the sources panel and see exactly which of their own records produced the advice. For a product giving guidance about a child, this was treated as a correctness requirement rather than a UI nicety.
The core solution
Conversational assistant with longitudinal recall. On each message the system classifies the query, embeds it, and runs a parallel retrieval across five sources — episodic memories, semantic patterns, top-ranked strategies, processed documents, and the last 30 days of observations — before composing a child-specific system prompt that includes diagnoses, sensory profile, communication level, and the family's chosen therapy methodology (ABA, TEACCH, PECS, naturalistic/ESDM-PRT, Floortime, DIR).
Document intelligence. Uploaded PDFs and DOCX reports go through a background queue: text extraction, structured summarisation, metadata extraction, and embedding generation. Once processed, a health board report or therapy evaluation becomes retrievable in conversation and citable in an answer.
Multi-role collaboration. Parents invite therapists, teachers, family members, and medical professionals into a child's support network. A permission matrix defines, per role and per resource type (observation, document, conversation, profile, memory), what is always allowed, never allowed, or configurable by the parent. Professionals who own no child profile of their own get a different dashboard entirely: a caseload view with a "home updates" feed from the families they support.
Cost and latency engineering. Three mechanisms keep a memory-heavy AI product economically viable: a semantic response cache (exact-hash fast path, then pgvector similarity matching, with quality gating that refuses to cache error or low-value responses); two-tier model routing that sends routine questions to a small model and escalates multi-step analytical questions to a frontier model based on Turkish-language complexity indicators; and adaptive reasoning effort that drops to minimal when a query needs no retrieved context.
My role
Sole engineer and product owner: data modelling, AI architecture, retrieval design, prompt system, background processing, RBAC, compliance flows, and the Turkish-language UI. The initial interface scaffold was generated from a Magic Patterns design and then substantially rebuilt around real data flows.
Technical approach
Next.js 15 (App Router, React 19, server actions) on PostgreSQL 17 with pgvector for embedding search; Drizzle ORM; NextAuth v5 with JWT sessions; S3-compatible object storage for documents; Redis for rate limiting and login throttling; BullMQ for document processing; the Vercel AI SDK for streaming with a LangGraph agent graph in the codebase; Sentry and PostHog LLM analytics for observability. Prompt A/B testing infrastructure records which prompt variant produced which response, so prompt changes can be evaluated against user feedback rather than intuition.
Compliance was built in rather than bolted on: KVKK/GDPR data export, a 30-day cancellable account deletion window with audit logging, per-member network access logs, and immediate clearing of extracted text and embeddings on document deletion.
Outcomes and evidence
This case study documents delivered capability, verified by reading the codebase and exercising the running application against a locally seeded, entirely synthetic dataset. No adoption, revenue, or accuracy figures are claimed.
What is demonstrably built and working: structured observation capture and filtering; document upload with AI summarisation and embedding-based retrieval; a memory-aware assistant that cites the family's own records inline; role-differentiated dashboards for parents and professionals; a permission matrix covering seven relationship types; consolidation of raw events into confidence-scored patterns and effectiveness-scored strategies; and a caching and model-routing layer built specifically to control per-conversation AI cost.
Need a similar product or workflow? If you are building an AI product where answers must be grounded in a customer's own longitudinal data — care, compliance, operations, or field work — I design the retrieval architecture, the data model underneath it, and the cost controls that make it sustainable at scale.
