00 manifest · 01 thesis · 02 non-goals · 03 building · 04 work · 05 stack · 06 decisions · 07 changelog · 08 signals · 09 limits · 10 interfaces
┌───────────────────────────────────────────────────────────────────────────┐
│ SYSTEM MANIFEST v3.0 · live │
├───────────────────────────────────────────────────────────────────────────┤
│ │
│ name Nishant Kumar │
│ handle @datascyther │
│ role AI Product Engineer · Product Builder │
│ operating range problem → thesis → architecture → build → production │
│ │
│ primary loop understand · define · build small · test · refine · ship│
│ core belief context is infrastructure │
│ current focus longitudinal memory & AI-native personal software │
│ │
│ building Jouspace — an open-source AI-native journal │
│ shipped before a 170K+ audience, built from zero, with no shortcuts │
│ status building in public │
│ │
└───────────────────────────────────────────────────────────────────────────┘
I design and build AI products from product thesis to production.
Most AI products fail in the same place. Not the model — the architecture around the model. What the system remembers. What it retrieves. What it refuses to do. Whether the user understands why it said what it said.
That gap is where I work.
- AI bolted onto a finished product as a feature
- Chat as the answer to every product question
- Memory as an ever-growing transcript
- More autonomy assumed to mean more value
+ AI as part of the architecture from the thesis onward
+ Intelligence placed only where it earns its position
+ Memory as selective, attributable, retrievable context
+ Autonomy granted deliberately, with user agency preserved|
Questions I ask as a product person
|
Questions I ask as an engineer
|
quadrantChart
title Positioning across product and systems work
x-axis Product thinking --> Systems engineering
y-axis Shipping features --> Designing architecture
quadrant-1 AI product architecture
quadrant-2 Experience architecture
quadrant-3 Interface craft
quadrant-4 Infrastructure
Jouspace: [0.74, 0.86]
Context and memory design: [0.66, 0.79]
Made with NK: [0.24, 0.58]
Matrix UPI: [0.30, 0.30]
Audience and distribution systems: [0.12, 0.44]
Good products are defined as much by refusal as by ambition. So is a career.
| I don't build | Because |
|---|---|
| Wrapper products with no defensible experience | A prompt is not a moat, and a demo is not a product |
| Interfaces where AI narrates instead of helping | Volume of output is not the same as usefulness |
| Systems that hoard every token of history | Maximum retrieval is not the same as relevant retrieval |
| Engagement mechanics disguised as care | Personal software should serve the person, not the metric |
| Architecture diagrams no user ever benefits from | Sophistication should be earned by reality, not aesthetics |
An open-source, AI-native journal for writing, remembering, connecting, and reflecting across your personal history.
The problem. Journals are excellent at storing thoughts, and terrible at making old thoughts useful again. AI chat has the opposite failure: useful in the moment, amnesiac by design.
The bet. If a system treats writing, conversation, mood, and reflection as one accumulating personal context, the archive stops being dead weight and starts becoming leverage.
BEFORE JOUSPACE
Jan ▓ Jan ▓─┐
Feb ▓ Feb ▓─┼──▶ ⟨ relevant context ⟩ ─┐
Mar ▓ ← never revisited Mar ▓─┤ │
Apr ▓ Apr ▓─┘ ▼
May ▓ May ▓ ◀───────────── reflection ─┘
↓
an archive a history that stays useful
flowchart LR
W(["Write"]) --> M(["Remember"])
M --> C(["Connect"])
C --> R(["Reflect"])
R -. new perspective .-> W
classDef loop fill:#09090B,stroke:#22D3EE,stroke-width:2px,color:#E0F2FE;
class W,M,C,R loop;
See the surface — Journal with contextual recall
┌──────────────────────────────────────────────────────────────────────────┐
│ Jouspace ▸ Journal ⌘K ◐ ⚙︎ │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ Tuesday, 14 March 🌤 steady · 6/10 │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ I keep circling the same decision about scope. It feels less │
│ like indecision and more like I haven't named what I'm actually │
│ afraid of yet.▊ │
│ │
│ ╭─ Related from your history ─────────────────────────────────────╮ │
│ │ 18 Nov · "scope creep and the fear of finishing" 0.82 │ │
│ │ 03 Jan · "I mistake preparation for progress" 0.74 │ │
│ ╰──────────────────────────────────────────────────────────────────╯ │
│ │
│ [ Save ] [ Reflect on this ] [ Ask companion ] │
└──────────────────────────────────────────────────────────────────────────┘
See the architecture — three separated concerns
flowchart TB
subgraph EXP["Experience layer"]
J["Journal"]
CH["Companion"]
MO["Mood context"]
RF["Reflection"]
end
subgraph INT["Intelligence layer"]
CA["Context assembly"]
RT["Retrieval"]
MEM["Personal memory"]
RUN["AI runtime"]
end
subgraph DAT["Data layer"]
SB["Supabase"]
PC["Pinecone"]
end
J --> CA
MO --> CA
RF --> CA
CH --> RUN
CA --> RT --> MEM --> PC
CA --> SB
RT --> RUN
RUN --> CH
RUN --> RF
classDef e fill:#09090B,stroke:#22D3EE,stroke-width:1.6px,color:#A5F3FC;
classDef i fill:#09090B,stroke:#A78BFA,stroke-width:1.6px,color:#DDD6FE;
classDef d fill:#09090B,stroke:#10B981,stroke-width:1.6px,color:#A7F3D0;
class J,CH,MO,RF e
class CA,RT,MEM,RUN i
class SB,PC d
The point: memory, retrieval, and generation are separate concerns — so context can be selected, not dumped.
Engineering:
React 19 · React Native · TypeScript · Expo · Supabase · Pinecone · RAG · Zustand · TanStack Query · Vitest
|
AI-native journaling & personal context An open-source system exploring longitudinal memory across entries, conversations, mood, and reflection. Built around the idea that personal software gets better when it understands continuity.
|
A transactional interface with a spine An experimental payment experience combining interactive web engineering with a Matrix-inspired visual system — built to test how motion and identity can reshape an otherwise conventional flow.
|
|
The portfolio A curated record of the products, systems, interfaces, and experiments I build across AI and software engineering.
|
170K+ subscribers, built from zero A technology media brand grown through content strategy, audience analytics, and distribution systems — the part of product work engineering alone doesn't teach.
|
I think about capability in layers, not logos.
╭─ LAYER 4 · PRODUCT ────────────────────────────────────────────────╮
│ thesis · positioning · experience architecture · prioritization │
│ interaction design · roadmapping · product QA · build in public │
╰────────────────────────────────────────────────────────────────────╯
╭─ LAYER 3 · INTELLIGENCE ───────────────────────────────────────────╮
│ LLM application architecture · RAG · context engineering │
│ semantic retrieval · vector search · long-term memory │
│ prompt & instruction design · orchestration · structured output │
│ AI product evaluation │
╰────────────────────────────────────────────────────────────────────╯
╭─ LAYER 2 · APPLICATION ────────────────────────────────────────────╮
│ TypeScript · React · React Native · Next.js · Expo · Node.js │
│ Zustand · TanStack Query · Tailwind / NativeWind · REST APIs │
╰────────────────────────────────────────────────────────────────────╯
╭─ LAYER 1 · FOUNDATION ─────────────────────────────────────────────╮
│ PostgreSQL · SQL · Supabase · Firebase · Pinecone │
│ Git · CI-oriented workflow · Vercel · Firebase Hosting │
│ testing · QA · documentation · production deployment │
╰────────────────────────────────────────────────────────────────────╯
pie showData
title Honest effort distribution on an AI feature
"Context and data architecture" : 34
"Product decisions and scoping" : 22
"Interface and interaction" : 20
"Evaluation, QA and edge cases" : 16
"Prompting the model" : 8
The last slice is the one everyone talks about. It's rarely the one that decides whether the product works.
Engineers write ADRs for systems. These are the ones I've written for how I work.
ADR-001 — Build products, not AI demos · Accepted
Context. A model response is trivially easy to produce. A product someone returns to is not.
Decision. Every AI capability must be justified by a user outcome, an interface it improves, and a failure mode it handles.
Consequences. Slower initial output. Fewer screenshots. Products that survive the second week.
Rejected alternative. Ship the demo, figure out the product later. Historically this becomes "never."
ADR-002 — Context is infrastructure · Accepted
Context. Model quality is increasingly commoditized. What a system knows, retrieves, attributes, and deliberately forgets is not.
Decision. Treat retrieval, memory, and context assembly as first-class architecture with their own boundaries, tests, and evaluation.
Consequences. More upfront design. Significantly better behavior as history grows.
Rejected alternative. Append everything to the prompt and hope the context window absorbs the problem.
ADR-003 — AI must earn its place in the interface · Accepted
Context. Intelligence inserted everywhere makes a product feel busy, not smart.
Decision. Default to deterministic. Introduce AI only where it measurably beats a simpler mechanism.
Consequences. Quieter interfaces. Higher trust. Easier debugging.
Rejected alternative. AI on every surface, because the API call was already written.
ADR-004 — Ship before architecture becomes theology · Accepted
Context. Systems can be refined indefinitely without ever meeting a user.
Decision. Build the smallest correct system, test it against reality, and let evidence drive sophistication.
Consequences. Some rework. Far less wasted work.
Rejected alternative. Perfect the diagram first — usually because a diagram looked lonely.
ADR-005 — Users keep agency · Accepted
Context. In personal software, autonomy without control becomes intrusion.
Decision. AI is user-initiated where it touches personal context. Retrieval is attributable. Behavior is inspectable and overridable.
Consequences. Fewer "magical" moments. Considerably more trust.
Rejected alternative. Proactive engagement designed to manufacture retention.
gitGraph
commit id: "problem"
commit id: "thesis"
branch experience
commit id: "flows"
commit id: "interface"
checkout main
merge experience
branch intelligence
commit id: "retrieval"
commit id: "memory"
commit id: "evaluation"
checkout main
merge intelligence tag: "v0.1"
commit id: "test against reality"
commit id: "refine"
commit id: "ship"
A career, written the way I'd write release notes.
v3.0 · PRODUCTS ────────────────────────────────────────────── current
Founder · AI Product Engineer
+ Building AI-native products end to end: thesis, architecture,
implementation, refinement, deployment
+ Focus on contextual AI, memory systems, retrieval, and
human-AI interaction
+ Jouspace developed and released in public
~ Shifted from "what can the model do" to "what should the system remember"
v2.0 · DELIVERY ───────────────────────────────────────────── shipped
Project Management Intern · Pranavyuv Technologies
+ Project operations, technical coordination, documentation
+ Workflow management and delivery under real constraints
~ Learned that clarity is a deliverable, not a byproduct
v1.0 · DISTRIBUTION ───────────────────────────────────────── shipped
Founder & Content Strategist · Mighty-Tech Shorts
+ Built a technology media brand to 170K+ subscribers from zero
+ Content strategy, audience analytics, experimentation systems
~ Learned the thing engineering doesn't teach well:
distribution, attention, and why people actually care
timeline
title The route here
Phase 01 : Built an audience from zero to 170K plus
: Learned distribution, attention and retention
Phase 02 : Worked inside real delivery constraints
: Learned coordination, documentation and shipping
Phase 03 : Moved into full-stack engineering
: React, TypeScript, data and infrastructure
Phase 04 : Committed to AI product engineering
: Context, memory, retrieval and human-AI interaction
Now : Building Jouspace in public
: Open-source AI-native personal software
Contribution graphs are one narrow view of engineering. Product decisions, private development, design work, user research, and the ideas that quietly failed all stubbornly refuse to fit into green squares.
Every honest spec has this section. Mine does too.
| Limitation | Status |
|---|---|
| I'm an applied AI engineer, not an ML researcher — I architect systems around models, I don't train foundation models | By design |
| Large-scale distributed backend engineering is not yet my depth | Actively learning |
| I optimize for shipped, coherent products over exhaustive test coverage early on | Deliberate trade-off, revisited as products mature |
| I default to building rather than waiting for consensus | Feature and bug, depending on the week |
| Design systems at organizational scale are outside my current experience | Growing edge |
I'd rather state this clearly than let a reader discover it in week three.
Contact, documented like an API — because you should know what you'll get back.
| Method | Endpoint | Returns |
|---|---|---|
GET |
/portfolio |
Products, systems, interfaces, experiments |
GET |
/source |
Repositories and open-source work |
GET |
/building |
Jouspace, in progress and in public |
POST |
/collaborate |
A real reply, usually with questions |
POST |
/connect |
Professional context and background |
|
✅ Worth writing to me about
|
🚫 Probably not a fit
|
{
"building": "Jouspace — AI-native journal with longitudinal memory",
"learning": ["retrieval evaluation", "agentic workflows", "eval-driven AI development"],
"thinking": "how personal software earns the right to remember you",
"reading": "product architecture, human-AI interaction, memory systems",
"open_to": ["AI product engineering roles", "collaborations", "OSS contributors"],
"status": "building in public"
}
