# Arunkumar Alagarsamy — Product Designer — full site content
> Every page of https://aruncrafts.design as one markdown file,
> generated from the same source as the site. Index: /llms.txt
> Contact: arun.dev.des@gmail.com · +91 8825456092
---
# Arunkumar Alagarsamy — Product Designer
> Product designer who crafts user experience, writes code, and ships tools.
> 8 years designing UX; the last 2 years building and shipping products in the
> AI and developer-tools space. Background in computer science & engineering.
- **Canonical site:** https://aruncrafts.design
- **Location:** Bangalore, India
- **Email:** arun.dev.des@gmail.com
- **Phone:** +91 8825456092
- **Résumé (PDF):** https://aruncrafts.design/Arunkumar_Product_Designer.pdf
## What I do
- Crafts user experience (Figma)
- Writes code (Claude / TypeScript / React)
- Ships tools (Vercel, npm, Framer marketplace)
The through-line across the work: the less visible side of products — developer
consoles, platforms, design systems, and the tooling other teams build on top of.
The user is usually another engineer or another team, and the problem is usually
structure.
Outside work: calisthenics — pull-ups, push-ups and the occasional handstand.
## Live tools
- **[ConvertKitty](https://convertkitty.com)** —
a free archive converter for 38 formats (ZIP, RAR, 7Z, TAR and more). Conversions run in
the browser with 7-Zip compiled to WebAssembly, so files stay on the device; the server is
a fallback, used only with the visitor's consent.
- **[Prompt to Blade UI](https://razorpay-challenge.vercel.app)** —
type a prompt, get a real screen in Razorpay's Blade design system; a schema, not a
prompt, keeps every generated style on-system. Case study: [blade.md](https://aruncrafts.design/blade.md).
- **[First Rank Pro](https://www.framer.com/marketplace/plugins/first-rank-pro/)** —
in-canvas SEO analysis for Framer sites; instant page health score across titles,
headings, alt text and keyword placement.
- **[Greymemory](https://greymemory.vercel.app)** —
a self-hosted memory layer for AI agents that knows when facts change; around 80% on
LongMemEval. Case study: [greymemory.md](https://aruncrafts.design/greymemory.md).
- **[Reverse Engineer LinkedIn API Tool](https://linkedin-profile-api-phi.vercel.app)** —
turns a messy, undocumented profile payload into clean structured JSON, and stays
honest about gaps: 20 of 47 skills is reported as 20 of 47, not passed off as complete.
- **[OpenFreeMap 3D](https://www.framer.com/community/marketplace/components/openfreemap-3d/)** —
a free, keyless interactive 3D map component for Framer; tilt, rotate and drop markers
by pasting a Google Maps link.
## Case studies
| Project | Context | Year | Detail |
|---|---|---|---|
| [Hike Developer Console](https://aruncrafts.design/hike.md) | Developer platform · Hike Messenger · 50M users | 2017–2018 | The tool internal teams used to build and publish mini apps inside the messenger — and the same console third-party companies used to publish theirs. |
| [Tekion OpenAPI](https://aruncrafts.design/tekion.md) | Enterprise platform · Tekion | 2022–2024 | The developer console that lets internal and third-party developers build services on top of Tekion's automotive platform APIs. |
| [Prompt to Blade UI](https://aruncrafts.design/blade.md) | AI design agent · Razorpay AI × Design Challenge | 2026 | Type a prompt, get a real screen in Razorpay's Blade design system — every style resolves through design-system tokens, so it can't go off-brand. |
| [Applix Copilot & DMS](https://aruncrafts.design/applix.md) | Enterprise AI for manufacturing · Applix · Founding Product Designer | 2024–2025 | Two product films for a manufacturing AI platform that detects defects and stops them at the source. Storyboard and UX/UI design. |
| [Greymemory](https://aruncrafts.design/greymemory.md) | Memory for AI agents · side project, open source | 2026 | A self-hosted memory layer for AI agents. Built end to end including the eval harness — around 80% on LongMemEval. |
Each case study also has a designed page: /ux/hike, /ux/tekion, /ux/blade,
/ux/applix and /ux/greymemory.
## Writing
- **[AI Agents are just a while loop. I built one in 30 lines. No jargon. No bullshit.](https://www.linkedin.com/pulse/ai-agents-just-while-loop-i-built-one-30-lines-jargon-alagarsamy-etgle/)**
— a working AI agent in 30 lines, no frameworks: the ReAct pattern, tool execution,
memory as a messages array, ending on a complete multi-turn agent that handles real tool calls.
Tags: AI, Code.
- **[How I got AI to turn a prompt into Razorpay's Blade UI — without it ever going off-brand](https://www.linkedin.com/pulse/how-i-got-ai-turn-prompt-razorpays-blade-ui-without-ever-alagarsamy-ywwac/)**
— the structured-outputs technique behind Prompt to Blade UI: how a schema, not the
prompt, is what keeps an LLM's output on-system. Tags: Design, AI.
## Elsewhere
- GitHub: https://github.com/arun-dev-des/
- LinkedIn: https://www.linkedin.com/in/iamarun4official/
- Behance: https://www.behance.net/iamarun4official
---
# Hike Developer Console
**Developer platform · Hike Messenger · 50M users · 2017–2018 · Arunkumar Alagarsamy**
> Every team shipping into the platform had built its own way to release — which
> siloed the teams and slowed every mini-app down.
The tool internal teams used to build and publish mini apps inside the messenger —
and the same console third-party companies later used to publish theirs.
## The problem
Teams across Hike Messenger were building mini apps into a platform with
**50 million users**. It started as internal tooling and later became the
third-party developer platform — without a redesign.
- **Teams worked in silos.** Each had invented its own way to push an app, and the
process lived in people's heads.
- **Scattered information.** Not an absence of process — competing versions of it,
no agreement between them, no structured path from build to release, and no shared
vocabulary for what state an app was in.
- **Developer terminology was a wall.** My first design role — I had to learn what
each term meant to a developer before I could design a flow around it.
- **Aligning teams and stakeholders** on a single process was the biggest hurdle.
- **The cost was real.** Publishing slowed to a crawl, and buggy apps reached users
because nothing was consistently reviewed first.
## Getting everyone to one way
- **Interviewed the developers pushing mini apps.** Mapped what each team actually
did, step by step — not what a process doc claimed.
- **Competitive analysis across six consoles** — Google, Apple, Facebook, Amazon,
Opera, Kik — to find which modules all of them had, and why.
- **Then got the teams in a room.** I facilitated the sessions where the dev teams
worked through the flows together and agreed on how publishing should actually go.
- **Iterated fast, in front of them.** Agreement came from seeing their own input
land, not from a document circulated for sign-off.
## Two users, two weeks
| Publishing — first-time experience | Maintenance — long-term experience |
|---|---|
| Onboarding · App details · App release · Distribution · Manage testers · Feedback | Applications list · Analytics · Send notification |
Two different users on two different weeks. This split became the console's
structure — and it's why the same product later worked for third-party developers
without a redesign.
## Version management
States: **Draft → Under Review → In Testing → Testing Complete → Review Failed / Review Success**
- **A horizontal process across teams.** Development and testing move a version
through a chain of states, and each state has its own call to action.
- A vocabulary, not a status badge. Everyone finally meant the same thing by "ready".
- **Review Failed carries the reviewer's feedback**, opened from the same screen.
A gate that only rejects teaches nothing.
- Only a finalized version enters release.
### Design decisions
- **Verbose over minimal.** The process is genuinely complicated — so the screen
spells things out rather than hiding detail behind a clean surface.
- **A timeline down the side** so a developer can see the whole flow, where their
version is now, and the next action to take.
## Release management
| Stage | Exposure |
|---|---|
| Alpha | Inside the company first. |
| Beta | A percentage of real users. |
| Production | Chosen segments, by percentage. |
- Nobody ships to 50 million in one move. The interface makes the safe path the
default path.
- Same shape as scoping what an agent may touch, and widening it as confidence builds.
- Each version targeted at named segments — Bangalore and Mumbai, Chennai and Trichy,
Gujarat. Chosen, not assumed.
## Design system — UI
- Full state coverage across every flow: empty, filtered, loading, no results,
expired OTP, error.
- Redlined type scale, hex with opacity, button and content-width rules.
- **Every form component specced through default, focused, typing, filled and error** —
including visible focus states and inline error text.
## What it changed
One structured way to publish that every team had agreed to. The silos went, and
teams shipped faster than when each ran its own process — with a review and testing
stage that caught problems before users saw them.
---
# Tekion OpenAPI
**Enterprise platform · Tekion · 2022–2024 · Arunkumar Alagarsamy**
Tekion is a US cloud-based automotive platform that brings dealerships, OEMs and
customers into one ecosystem. OpenAPI is how internal teams and third-party
developers build services on top of it.
## Modules I worked on
The developer console spans the full lifecycle — discover an API, get scoped access,
prove you're safe, go to production, stay healthy there. I designed across it end to end.
- **Access & credentials** — Digital Certificate, Production Credentials, IP
Whitelisting: the path from a sandbox key to trusted production access.
- **Security & review** — the Certification tab, the gate an integration passes
before it can go live.
- **Partner administration** — Admin Controls, Multiple User Roles, Dealer
Management: who on a partner team can act, and for which dealerships.
- **Operations & health** — API Health status, Support Dashboard, Webhooks: what a
developer watches once they're in production.
- **Platform** — Basic Feed Subscription, API Icons, and the move to Design V2.0.
The API catalogue lets a developer pick which domains to build against, with each
API's scope and access model visible before a key is ever issued.
## Support Dashboard & API Health
Once a partner is in production, the question shifts from "can I get access" to
"is it working right now."
- **Support Dashboard** — one place to monitor the API endpoints an integration
depends on: request volume, error rates, and where a failing call is coming from.
Drill into one endpoint for volume, errors and source.
- **API Health** — the live status of each API, so a developer can tell a
Tekion-side incident apart from a bug in their own code before they open a ticket.
Is it us or is it them — answered before a ticket is filed.
## The through-line
The same publishing-and-lifecycle spine as Hike — discover, get scoped access,
prove you're safe, widen exposure — but at enterprise scale and with contracts attached.
## Reference
Full file — [Open API — Figma](https://www.figma.com/design/GuMSWLK3ND1sN9tJQsUSSH/Open-API?node-id=1-207039)
---
# Prompt to Blade UI
**AI design agent · Razorpay AI × Design Challenge · 2026 · Arunkumar Alagarsamy**
> Autonomy bounded by the system, not by the prompt.
Type your prompt → Claude creates a JSON description of a screen → real Blade
components rendered on screen. Built for Razorpay's Blade Build Challenge, in about
two hours.
## Project links
- Live demo: https://razorpay-challenge.vercel.app/
- GitHub: https://github.com/arun-dev-des/prompt-to-blade-ui
- Blog: https://www.linkedin.com/pulse/how-i-got-ai-turn-prompt-razorpays-blade-ui-without-ever-alagarsamy-ywwac/
- Schema playground: https://razorpay-challenge.vercel.app/schema-playground.html
- Deployed on Vercel
## Reach
| Metric | Value |
|---|---|
| Impressions | 30K+ |
| Reached | 19K+ |
| Tried it live | 593 |
## The problem
By default, an LLM is a free-form text generator. Ask it to "design a payment
screen" and it might hand back code with hard-coded colours like `#00ff00`, random
pixel sizes, a layout that ignores your design system, or a component that doesn't
exist. Often useful — but unpredictable. You can't guarantee it'll be on-brand.
## The technique
Don't let it write freely — make it fill a form. The Anthropic API has a feature
called **structured outputs**: you hand the model a schema (a rulebook), and the
reply is forced to match it. Claude chooses what goes in the blanks, but it can't
add a blank that isn't on the form — the API rejects anything off-shape.
**The constraint, not the prompt, is what keeps the output on-system.**
`UI_SCHEMA` is that strict form — the rulebook the reply is forced to match.
Everything Claude is allowed to return is defined in it, and anything off-shape is
rejected.
## What's inside UI_SCHEMA
`UI_SCHEMA` is a component library written as rules — a fixed set of elements, each
with a fixed set of props, and `additionalProperties: false` at every level.
```ts
export const UI_SCHEMA = {
type: 'object',
additionalProperties: false, // anything off-shape is rejected outright
required: ['title', 'sections'],
properties: {
title: { type: 'string' },
subtitle: { type: 'string' },
sections: { type: 'array', items: {
additionalProperties: false,
required: ['elements'],
properties: {
variant: { enum: ['card', 'plain'] },
layout: { enum: ['stack', 'grid'] },
heading: { type: 'string' },
elements: { type: 'array', items: { anyOf: [
// every element Claude may place — and nothing else is valid
{ kind: 'heading', text, size? small | medium | large },
{ kind: 'text', text, tone? normal | subtle | muted },
{ kind: 'amount', value, label?, currency? },
{ kind: 'statTile', label, value, currency?, delta?, up? },
{ kind: 'badge', text, color? positive | negative | notice |
information | neutral | primary },
{ kind: 'button', text, variant? primary | secondary | tertiary, icon? },
{ kind: 'input', label, placeholder?, inputType? text | email | password | textarea },
{ kind: 'switchRow', title, description?, on? },
{ kind: 'person', name, subtitle? },
{ kind: 'feature', text },
{ kind: 'divider' },
]}},
},
}},
},
} as const;
// note: even 'color' is a semantic token — positive, notice — never a hex.
```
## Blade Schema Playground
Explaining a guardrail is weaker than letting someone hit one — so I built a
playground. You assemble a screen the way Claude has to, by filling the fixed form;
the exact JSON spec builds alongside; then you try to add a raw colour and feel
`additionalProperties: false` push back. It runs offline, embedded in the deck.
## The renderer — Claude's JSON becomes real Blade
The validated spec never touches the DOM directly. A deterministic renderer walks it
and swaps each `kind` for a real `@razorpay/blade` component — every colour, space
and radius resolved through Blade tokens. An unknown `kind` is skipped, so schema
drift can't crash the screen.
```tsx
// SchemaRenderer.tsx — a validated UIScreen → real @razorpay/blade components
const Element = ({ el }: { el: UIElement }) => {
switch (el.kind) {
case 'heading': return {el.text};
case 'text': return {el.text};
case 'amount': return ;
case 'statTile': return … ;
case 'badge': return {el.text};
case 'button': return ;
case 'input': return el.inputType === 'password' ? : ;
case 'switchRow': return {el.title};
case 'person': return {el.name};
case 'feature': return {el.text};
case 'divider': return ;
default: return null; // unknown kind → skipped, the screen never crashes
}
};
export const SchemaRenderer = ({ screen }: { screen: UIScreen }) => (
{screen.title}
{screen.subtitle && {screen.subtitle}}
{screen.sections.slice(0, 4).map((section, i) => )}
);
```
The design line: the model owns content and arrangement, the design system owns
styling — the schema is where that line is drawn.
## Reference
[Anthropic, "Building effective agents"](https://www.anthropic.com/engineering/building-effective-agents)
---
# Applix Copilot & DMS
**Enterprise AI for manufacturing · Applix · Founding Product Designer · 2024–2025 · Arunkumar Alagarsamy**
> Two product films that turn a dense manufacturing AI platform into a story an
> enterprise buyer can follow in minutes.
Applix helps manufacturers catch defects on the line and stop them at the source. The
platform is powerful but abstract: CAD models, sensor logs, root cause analysis,
corrective actions. I storyboarded and designed two demo films used in enterprise
pitches, one for the Copilot and one for the Defect Management System.
Page: https://aruncrafts.design/ux/applix
## Role and team
- **Storyboard:** narrative, script flow, scene plan
- **UX/UI design:** every product screen shown in both films
- **Team of 3:** me, 1 motion designer, 1 illustrator
- **Output:** 2 product films (3:39 and 6:13)
## Film 1: Applix Copilot (3:39)
Video: https://aruncrafts.design/videos/applix-copilot.mp4
A walkthrough of detection and prevention, built around one drone case study so the
viewer follows a single product end to end.
- **Project dashboard.** Live metrics for product failures, cost, quality inspection and production efficiency.
- **Visual inspection plan.** The 3D CAD model sits at the centre with the bill of materials beside it. Hovering a part highlights it in the model.
- **A spell check for manufacturing defects.** On an iPhone or iPad, the CAD model is overlaid on the real part in augmented reality and snaps to it. Parts are checked against the design: green is correct, yellow is misaligned, red is missing.
- **Instant quality report.** One tap generates the report, and it can feed into legacy QMS systems.
- **From detection to prevention.** In the optimization module, engineers chat in natural language with a model tuned on engineering first principles. They ask for root causes, design for assembly or design for manufacturing reviews, then simulate the recommended changes. Every inspection feeds the loop toward zero defects.
## Film 2: Defect Management System (6:13)
Video: https://aruncrafts.design/videos/defect-management-system.mp4
Opens on the problem before showing any product: signals are everywhere, but they are
trapped in silos, so teams react instead of prevent.
- **The Control Tower.** One AI command center that ingests sensor logs, telematics and error codes, plus ERP, QMS and warranty systems, and surfaces early warning signs in real time.
- **Logging in seconds.** A defect is captured by voice, text or photo from the shop floor: a wire harness overheating at station five, with an image attached.
- **Identification.** Dashboards for defects by customer, cost of poor quality and defects per unit. Drilling into electrical defects surfaces the harness issue logged a moment earlier.
- **Prioritization.** Defects are grouped by taxonomy and ranked by severity and impact, then assigned to the right team.
- **Resolution and CAPA.** Teams run 5 Whys, FMEA or Fishbone analysis. Here the Fishbone points to improper routing, and the system drafts a corrective action plan. A CAPA dashboard then tracks whether failure rates actually drop.
- **Reports.** Custom reports shaped to each persona's needs.
## My role
- **Storyboard.** Shaped each film's arc: problem first, then the platform, then one concrete workflow a buyer can picture on their own line, then the outcome.
- **UX/UI design.** Designed the product screens shown in both films, from the project dashboards and AR inspection view to the Control Tower, prioritization and CAPA flows.
- **Working with motion and illustration.** Collaborated with one motion designer, who brought the screens to life, and one illustrator, who created the isometric scenes that explain data flowing into the Control Tower.
## Why film, not slides
Manufacturing buyers do not buy a model, they buy a fix for a problem on their line.
Each film follows one defect from the moment it is spotted to the moment it stops
recurring, so the value of the whole platform lands in a single story.
---
# Greymemory
**Designing memory for agents · a side project, open source · 2026 · Arunkumar Alagarsamy**
> LLMs are stateless by design. Memory is what makes an agent feel like it knows you.
A self-hosted memory layer for AI agents. It pulls atomic memories out of natural
conversation, notices when they contradict, supersedes the stale ones while keeping
their history, and brings the right one back into context when it's needed. I
designed and built it end to end — including the benchmark harness.
## Project links
- Website: https://greymemory.vercel.app/
- npm: https://www.npmjs.com/package/greymemory
- GitHub: https://github.com/arun-dev-des/greymemory
- Interactive knowledge graph: https://greymemory.vercel.app/#/viz
- Licence: Apache 2.0 · BM25 + vector RAG
## Why memory is a design problem
- An agent that forgets what you told it last week, or answers with a fact that
changed two months ago, doesn't read as "buggy" — it reads as **not very smart**.
- A wrong answer you can catch and correct. But agents don't just answer any more —
they **act**, and an action taken on missing or stale context isn't a bad sentence,
it's a wrong move someone has to notice and undo. The more an agent does on its own,
the more the right action depends on the right context — and that context is what
memory holds between sessions.
- Perceived intelligence is mostly memory: does it know me, does it keep up, does it
admit when it doesn't know.
## What good memory has to do — five abilities, each a real failure
### 01 · Information Extraction
*Recall one specific detail from months of conversation.*
March session: "Can you help me plan nut-free lunches for the week? Mrs. Alvarez just
banned nuts in my daughter's class and I'm out of ideas." Three months later:
*Q → Who's my daughter's teacher?* *A → Mrs. Alvarez.*
**Why it's hard:** the name surfaced inside a lunch-planning request, never as "her
teacher is Mrs. Alvarez." Store only explicit statements and it was never kept — so
retrieval has nothing to find.
### 02 · Multi-Session Reasoning
*Assemble one answer scattered across many sessions.*
Four separate sessions — Korean BBQ in February, a Thai place in March, an Ethiopian
restaurant in May, a ramen bar in June. *Q → How many new restaurants have I tried
this year?* *A → Four.*
**Why it's hard:** four unrelated dinners joined only by the abstract idea of "a new
restaurant I tried." No single query surfaces all four; the system has to gather
them, then count.
### 03 · Knowledge Updates
*Notice a fact changed, and answer with the current one — not both.*
January: "Reviewing every PR myself is still manageable with four engineers." April:
"Onboarding is brutal now that we're six." *Q → How many engineers do I lead now?*
*A → Six — not "four and six."*
**Why it's hard:** the old number isn't wrong, it's stale — ask what the team looked
like in January and four is still true. But "now" wants the current one. Without
supersession the system keeps both alive and hands you the ambiguity.
### 04 · Temporal Reasoning
*Reason about when things happened, not just what.*
Feb 3: a 40-minute outage. May 20: a full outage, DB failover didn't fire. June 10: a
near-miss caught before it took prod down. *Q → How long was it between our last two
real outages?* *A → About 15 weeks.*
**Why it's hard:** that number is written down nowhere — it's Feb 3 → May 20, computed
from two dates the system had to store as the event dates, not the dates they happened
to be mentioned. And "real outages" has to rule out the June near-miss.
### 05 · Abstention
*Know what it doesn't know, and say so instead of confabulating.*
June: "My sister's wedding is eating every weekend this month — I'm maid of honor."
*Q → What did I think of my brother's wedding?* *A → "You haven't mentioned a brother."*
**Why it's hard:** the system knows about a wedding and a sibling, so the helpful
reflex is to answer about the sister's. Resisting that — and naming the false premise
instead of inventing an opinion — is the skill. For most models, a confident wrong
answer beats an honest "I don't know."
## The knowledge graph as an interface
- Everything the agent holds, as one graph — facts, preferences, episodes, and the
`updates`, `extends` and `supersedes` edges between them.
- Type a question and it lights up what it would pull back. This is "memory is an
interface" made literal: a person can look at what the agent knows about them, not
just hope it's right.
- The live graph shown on the site: 272 memories, 37 docs, 63 links; nodes coloured by
type (fact, preference, episode, raw chunk), edges for updates / extends /
supersedes / source.
## How Greymemory handles them
- **Atomic extraction into a typed graph.** fact / preference / episode, each with a
confidence and a source — so a teacher's name buried in a lunch request still gets kept.
- **Supersession, not overwrite.** "I work at Barbell Cartel" → later "I now work at
Stripe": the second is classified as an update, the first is superseded but its
history stays queryable.
- **Temporal grounding.** Real event dates extracted, a timeline injected at read time —
this alone moved temporal accuracy 60% → 73.3%.
- **`forget()`** — soft-delete by meaning; gone from every query the moment you call
it, kept in the database.
```ts
// a fact, then one that contradicts it
await memory.add([{ role: 'user', content: 'I work at Barbell Cartel as a product designer' }])
await memory.add([{ role: 'user', content: 'I now work at Stripe as a PM' }])
await memory.search('where does Arun work')
// → 'Arun works at Stripe as a PM' — old fact superseded, not gone
await memory.getHistory('where has Arun worked') // full chain, newest first
await memory.forget('my old apartment address') // soft-delete by meaning
```
## The problem, measured
- **LongMemEval** (arXiv 2410.10813) breaks long-term memory into those five abilities
and tests them across ~500 hand-built questions.
- The baseline everyone quotes: GPT-4o reads the whole transcript and still scores
60.6% — it gets lost in the middle. ChatGPT's own long-term memory scores 57.7%.
- Greymemory: **80.0% overall** — 96% of a funded cloud competitor's score,
self-hosted, at ~$0.013 a session.
### LongMemEval — accuracy by ability
| Ability | Raw context | Greymemory |
|---|---|---|
| Information extraction | 81.4% | 93.3% |
| Multi-session | 44.3% | 66.7% |
| Knowledge update | 78.2% | 80.0% |
| Temporal reasoning | 45.1% | 73.3% |
| Preference | 20.0% | 66.7% |
| **Overall** | **60.6%** | **80.0%** |
## The design argument
Memory is an interface. If a person can't see or correct what an agent has stored
about them, they can't calibrate how much to trust it — which is why the graph, a
readable version history and an instant `forget()` are part of the product, not an
admin afterthought. The same store serves the person reading it and the agent acting
on it.
---