An AI-native trade analytics platform
Punch Journal
Mixpanel for your own trading. It started as a one-week feature request and turned into a platform: over a hundred metrics across twenty-six widget families, computed from nothing but a trader's own tradebook. It shipped to 2,000+ traders.
Where it started
A one week feature request that I stopped and rebuilt as a platform.
P&L Calendar sat near the top of Builder's Lab, the public roadmap I ran, with more than 400 votes behind it. Every major broker shipped a version of it. It was about a week of work.
Then a conversation about Mixpanel stopped me. Everyone at Punch lived in it, and growth, product, support and engineering all got different answers from the same data. What changed was never the data, it was the question each team asked. So the brief stopped being "build a P&L calendar" and became "build the thing that lets a trader ask their own question of their own trades".
I built an AI workflow to survey what trade analytics platforms worldwide offered: 129 distinct widgets. Then I cut them against who my user was, what data I had, what a first version needs, and what each one cost to build. Twenty-six survived.
Please introduce a automated trading Journal on Android and web trading platform so it's easy to track daily basis also include percentage of P/L which will let the trader know how he is performing
Ashwin Siddheswar
Per day jitne bhi trade ho wo add ho jaye aur day wise profit n loss bataye aur usme lessons aur mistek likh sake jisse traders ko day wise add kar sake trade wise apni learning n misrek likh sake samaj ma aa sake
Jitendra
Were you following your trading plan? Did emotions affect your decisions? Any overtrades or revenge trades? Did you respect your stop losses?
Jayavant Somnath
The decision
If traders have questions, why not just ship a chat box?
The obvious move, and genuinely available. Plain English in, answer out. Cheap, easy to explain, clean path to a demo. I did not build it.
Asking is not thinking
First principles told me traders have questions. It did not tell me a typed question is how a trader thinks. What people do and what they say they do are usually different, and I had not earned that assumption.
They had already told me what they wanted
Somewhere to read their own trading back. A chat box answers a different question from the one they posted, and my job was to satisfy theirs.
Retention
A chat box opens when someone has a need. A dashboard opens to check on progress. Question-asking was maybe 10 to 15% of the experience; the rest was watching yourself improve, and a dashboard is the better shape for that.
What I built
You add questions to a dashboard, not widgets.
Traders know their questions but not how to reach the answers. "I have a high win rate and I am still net negative" is not one widget. Neither is "am I overtrading?" Both need two or three widgets beside each other, over the right window, synced. So the way to build a dashboard is to add a question and let the system assemble the widgets that answer it. On top of that I built curated dashboards in four layers, so a trader could stop wherever suited them: land on a full diagnosis, browse others, adjust the widgets, or compose their own.
That is the design. What happened is more awkward. I deliberately did not push anyone past the first layer, and a larger share than I expected stopped at the default view and stayed there. They liked the tool, but most traders are in a loss, and six dashboards showing them exactly how they are losing money was demotivating enough to keep them from coming back.
Showing them less was not the answer. A trader who is losing needs somewhere to go next, and the numbers on those dashboards already point at it. The next thing to build was a layer that reads a trader's own results and tells them what to work on, so the diagnosis arrives with a direction attached. I did not get to build it.
How it was built
Designed in Pen.dev, then built with Claude Code and one engineer.
I built the frontend myself with Claude Code doing the implementation, and one engineer covered the backend pipeline and the deployments. That is the whole team. A tradebook CSV is the only input and the frontend computes nothing, because two widgets that disagree about net P&L is one bug you never recover from.
Zero to one is mostly deciding what not to build
129 widgets became 26. The chat box was obvious and I refused it. The feature 400 people voted for got stopped. None of it is visible in the finished product.
A design system is what makes agent-built software cohere
An agent will give you any number of plausible widgets and no two will feel like the same product. The token layer was the constraint that made speed safe.
Pen to Storybook to a wired frontend
A design file becomes a real React application without the fidelity decaying, because every component is reviewed in Storybook against the tokens first. That chain is why I could ship the frontend myself.
Running several agent teams at once
A scheduling and review problem before a technical one. The limit is how much I can check, not how much they can produce, and git discipline is what keeps it from becoming a mess.
About
Most of the seven years was spent alongside the CEO, the head of design, engineering, business analysts, subject matter experts and growth.
What I want next is AI-native product work, and a place where I can keep building great products myself.
Education
-
MS, Cognitive Science
Indian Institute of Technology Gandhinagar2015 to 2017
Thesis on the cognitive system of musical improvisation, read through phenomenology.
-
BS, Life Science and Biochemistry
St. Xavier's College, Mumbai2012 to 2015
- sunat.archit6@gmail.com
- +91 99136 42634