About
This is Ayan and I am always building things that need to exist. A frustrating process, an outdated system, or a problem people have quietly accepted is usually where the best ideas begin. The goal is to find a modern way through it and make something people actually enjoy using.
Background
Outside work
Coffee, soccer, and being outside shape a lot of my days.
Moving across the world for college made it easy to walk into unfamiliar rooms, start conversations, and find common ground with people from all kinds of backgrounds. California has become home in its own way, especially the Bay Area. There is something motivating about being around people who are excited about their work, chasing big ideas, and building lives they care about.
Soccer has always been a big part of life. Five years playing, three of them club, has meant early mornings, long drives, tough losses, good teammates, and the kind of friendships that form when everyone is working toward the same thing. It keeps me competitive, but more than that, it taught me how to show up, bring energy, and make the people around me better.
Outside of work there is usually a coffee shop to try, a hike to take, or another stretch of Highway 1 worth driving. Most of the route has been explored by now. Beaches, viewpoints, roadside stops, small towns. The best part has always been the people and the conversations along the way.
The work matters, but so do the people around it. The best projects, teams, and ideas usually start with a good conversation.
How I got here
I do not like settling for what is handed to me. A degree is a title. It does not set the limit on what you learn or how far you take it.
Being stuck inside a problem and building the way out is what has moved me toward the places I want to be.
How I work
I start by finding where a system will be wrong, then design so that being wrong costs as little as possible.
That sounds defensive. In practice it moves fast. Deciding up front what happens when the model is unsure, when the scan is unreadable, when the guidance has changed since last month, means you are not rebuilding later after something silently breaks.
When I am stuck, I read the code instead of the tests. Twice on Fraqt the tests were green while the system was wrong, and both times reading found what running did not.
What I will not do is ship something that guesses. A refusal is a real answer. A confident wrong answer is not.
Approach
Find where it breaks
Before building, work out what happens when the input is bad, the source is stale, or the model is unsure.
Put the safeguard where it cannot be forgotten
Tenant isolation lives in the database, not in application code, because application code changes.
Make it refuse
If the system cannot support an answer, it says so. Every refusal is a design decision, not a gap.
Write down what it cannot do
The research paper states its limits. The churn model ships a limitations table. Fraqt lists its known gaps.
Toolkit
Languages and databases
Python
SQL
TypeScript
PostgreSQL
AI and machine learning
scikit-learn
Data and analytics
Power BI
DAX
Power Query
JMP Pro
Excel
Engineering
Next.js
React
AWS
Git
Also
AI and machine learning
LLM application design
Retrieval-augmented generation
Vector search
Embeddings
Prompt engineering
Grounding and refusal design
AI guardrails
LLM evaluation
Classification
Regression
Data and analytics
ETL pipelines
Data modeling
ERD design
Dashboards
KPI reporting
A/B testing
Customer segmentation
Survey methodology
Statistical analysis
Data validation
Engineering
OCR
Multi-tenant architecture
Application and database security
Automated testing
PII handling