DEV Community: Anurag Kashyap

From Side Project to Play Store: Shipping a Stock Analyser with Capacitor, Cloudflare Workers, and Claude Code

Anurag Kashyap — Thu, 07 May 2026 10:33:44 +0000

                                                                                             The stack nobody warns you about — and what actually got it live.                                                                                                                             ---                                                                                            I built Buffett Stock Evaluator (https://kashvector.com/stock/) — a free tool that scores any stock against the Buffett, Ray Dalio, and Benjamin Graham frameworks — as a weekend project.

One month later it's live on Google Play. Here's the story-

The Stack

Vanilla HTML/CSS/JS — no framework, no build step
Cloudflare Worker — the secret glue that makes Yahoo Finance work
Capacitor — wraps the web app into a native Android APK with almost no code changes
Claude Code — AI pair programmer throughout

The Yahoo Finance Problem

Every free stock data project eventually hits the same wall: Yahoo Finance's quoteSummary endpoint requires a crumb — a token you can only get after completing a cookie handshake with fc.yahoo.com. You can't do this from a browser because of CORS. Public proxies that used to work got blocked or paywalled in early 2026.

My solution: a ~150-line Cloudflare Worker that handles the entire auth dance server-side.

// worker/yahoo-proxy.js (simplified)
async function getAuth() {
const cookieRes = await fetch('https://fc.yahoo.com');
const cookie = cookieRes.headers.get('set-cookie');
const crumbRes = await fetch(
'https://query2.finance.yahoo.com/v1/test/getcrumb',
{ headers: { Cookie: cookie } }
);
return { cookie, crumb: await crumbRes.text() };
}

The Worker caches the crumb per-isolate for an hour, adds an origin allowlist to prevent abuse, and rate-limits by IP using an in-memory sliding window — all without Cloudflare's paid add-ons.

The killer feature: the Worker is git-connected to the repo via wrangler.toml. Committing a change and pushing to main auto-deploys it. No dashboard clicking.

The Architecture Decision That Made Native Cheap

Before touching Capacitor I made one rule: only app.js is allowed to touch the DOM.

Every other file — the scorer logic, the data fetcher, the formatters — had to be pure functions: data in, data out. No document.querySelector, no window.*, nothing.

This felt like overkill for a web app. But when I ran npx cap sync to wrap it in a native Android shell, I made zero changes to any of the logic files. Capacitor just needed webDir:

"www" and the WebView handled the rest.

npx cap sync # copies www/ into android assets
npx cap open android # launches Android Studio to build

The DOM boundary isn't a style preference — it's the constraint that makes "ship to Android" a two-command operation instead of a rewrite.

Three Scoring Frameworks, One Data Contract

Each scorer (buffettScore, dalioScore, grahamScore) takes the same raw Yahoo data object and
returns:

{ results: [...], totalScore, maxScore, verdict }

Verdicts are ratio-based — totalScore / maxScore >= 0.85 → "Strong Buy" — because some criteria get skipped for financial stocks (banks shouldn't be penalised for high debt-to-equity ratios). maxScore shrinks when criteria are skipped, so the threshold stays meaningful.

One trap I hit: Yahoo reports debtToEquity as a percentage (53.2 means 53.2%). Every scorer divides by 100 before comparing thresholds. Miss this once and every stock looks catastrophically leveraged.

The Play Store Journey

The part nobody writes about honestly:

Create a Google Play developer account ($25 one-time fee, instant)
Closed testing — you must have at least 12 testers opt-in and run for 14 days before you can apply for production access
Production access review — Google manually reviews the app. Mine took about 7 days after applying
Sign with an upload keystore — lose this .jks file and you can never update the app again. Back it up somewhere outside the repo.

The closed testing period is the real wait. Recruit your testers early — getting 12 people to click an opt-in link takes longer than you'd think.

For the signed AAB I used Android Studio's built-in bundle generator rather than CLI signing.

Building with Claude Code

I used Claude Code as a pair programmer throughout — not just for boilerplate, but for architecture decisions, debugging Yahoo's auth changes, and writing the Play Store submission checklist.

The most useful pattern: describe a constraint first, then ask for implementation. "The scorer must be a pure function with no DOM access" produced much better code than "write a Buffett scorer." The AI respected the architecture rules when they were explicit.

One thing that surprised me: Claude caught the debtToEquity percentage trap before I did, flagged it as a known Yahoo Finance gotcha, and added a comment explaining why. That's the kind of domain-specific knowledge that would have cost me an hour of head-scratching.

What I'd Do Differently

Set up the Worker origin allowlist on day one. I added it after the Worker was already deployed and got a surprise traffic spike from a scraper.
Recruit closed testers before submitting. I lost a week waiting for the 12-tester threshold.
Don't skip the DOM boundary rule even on weekend projects. The Capacitor port took one afternoon. Without the rule it would have been a weekend.

The app is free, no sign-in required: kashvector.com/stock (https://kashvector.com/stock/) or
search "Buffett Stock Evaluator" on Google Play.

Built with Capacitor · Cloudflare Workers · vanilla JS · Claude Code

[Boost]

Anurag Kashyap — Fri, 01 May 2026 10:32:13 +0000

Anurag Kashyap

May 1

I Built My Own Fitness Dashboard Because the Technogym App Wasn't Cutting It

#showdev #analytics #data #sideprojects

Comments 1

4 min read

I Built My Own Fitness Dashboard Because the Technogym App Wasn't Cutting It

Anurag Kashyap — Fri, 01 May 2026 10:25:27 +0000

If you use Technogym equipment at your gym, you've probably opened their app, tapped around a few screens, and quietly closed it again. The hardware is excellent — but the app's dashboards feel designed for compliance rather than insight. I wanted to answer simple questions like "how many days did I actually go to the gym this month?" or "is my weights trending up?" and I couldn't get there without clicking through five menus.

So I built my own.

The Problem with Technogym's App

The Technogym ecosystem tracks everything: every rowing stroke, every set, every kilogram lifted, every step on the treadmill. The raw data is incredibly rich. But the native app surfaces it in a way that makes it hard to spot trends, compare months, or get an at-a-glance view of your progress.

My specific frustrations:

No meaningful weekly or monthly aggregation across session types
No way to know if my average weights lifted increasing over time
Calorie and distance stats buried per-session with no roll-up view
No "gym visits per week" concept — just individual activity logs

The obvious solution would be to use the Technogym API directly. I looked into it. Getting API access requires a business partnership with Technogym. As an individual developer and gym-goer, that door is closed.

But there's a workaround: you can export your own data.

The Data Export

Technogym lets you request a full data export from the app. You get a ZIP file containing four JSON files — your profile, body composition measurements, every gym session with full per-set breakdowns, and outdoor activities.

My export had 2,668 indoor activity records going back two years and 408 biometric measurements. The indoor activities file is the richest — each record contains the top-level session metrics plus individual set data including weight, reps, and duration.

One quirk: there are no human-readable exercise names. Each exercise is identified by an internal UUID. You have to infer what it was from the metrics present — if a record has rowing distance and stroke rate metrics, it's a rowing session; if it has weight and rep data in its sets, it's strength training.

I can re-download this export every few days to keep the dashboard fresh.

The Build: Web + Android from One Codebase

I wanted this on two surfaces:

A web app — to open on any browser and share a view with my trainer
An Android APK — to check on my phone after a session

Expo with React Native was the obvious choice — one codebase, two targets. The web app is deployed to GitHub Pages automatically on every push. The Android APK is built via EAS Build (Expo's cloud build service) — the free tier gives 30 builds per month, which is more than enough.

The entire ZIP file is parsed client-side. Your data never leaves your device.

Interesting Problems Along the Way

What "A Gym Visit" Actually Means

The Technogym export gives you one record per exercise — a typical gym session generates 10–15 records. So counting records as "sessions" would give you 100+ per week, which is meaningless.

Looking at the timestamps, every record from a given gym visit clusters within 1–2 hours on the same calendar day. So the right definition is simple: a gym visit = a distinct calendar day with indoor activity. That single insight turned a useless metric into one of the most useful charts in the app.

The Timezone Bug

I'm in Australia (UTC+10). The app was grouping all my April sessions into the March bucket — every month appeared one step behind. The cause was subtle: when converting a date to a string key for grouping, I was using the UTC date instead of the local calendar date. Midnight on April 1st in Sydney is still March 31st in UTC, so the bucket ended up in the wrong month. Once I switched to using local date methods, everything snapped into place.

Keeping Charts and Logic Separate

The rule I enforced throughout: no data transformation inside chart components. Every chart receives a plain array of pre-computed values. All the filtering, grouping, and aggregation lives in a dedicated hooks layer.

This paid off immediately when adding the Avg / Total toggle to charts like Weight Lifted and Calories Burned — the chart component just holds the toggle state and passes it to the hook. The chart itself doesn't change at all.

What I Can See Now

The dashboard has five tabs:

Overview — Gym visits per week/month, avg visits/week, avg calories per visit, activity type breakdown, training load (total active minutes), and metabolic intensity.

Biometrics — Weight, body fat, muscle mass, BMI and other body composition metrics as trend lines over time.

Workouts — Calories burned (indoor vs outdoor), total weight lifted, cardio distance — all with total/average toggles.

Cardio — Distance, calories, pace (in min:sec per km, green = fastest period), and elevation gain.

Strength — Weight lifted and rowing performance (distance + power) with avg/total toggle.

The most useful views for me personally: weights lifted trend and gym visits per week — a simple bar chart that makes consistency (or the lack of it) very visible.

Sharing with My Trainer

The web app lives at a public GitHub Pages URL. Before a session, I open the app, upload my latest export ZIP, and share the URL. My trainer can see exactly what I've been doing — session frequency, calorie burn by type, weight progression — without needing any account or login.

It's also a much better conversation starter than trying to scroll through the Technogym app together.

What's Next

A few things I'd like to add:

1RM trend — the export includes an estimated one-rep max metric per strength session
Body composition overlay — weight, fat mass, and muscle mass on a single chart

The data's all there. It's just a matter of building the views.

Code

The full source is on GitHub: github.com/kanurag4/technogym-dashboard

If you're a Technogym user frustrated with the native app's dashboards, fork it and point it at your own export. The ZIP format appears consistent across accounts — the parsing should work for any Technogym user.

Built with Expo, React Native, NativeWind, react-native-gifted-charts, and JSZip. Deployed to GitHub Pages and Android via EAS Build.

I Built a Suite of 6 Financial Tools in My Browser Stack — Here's the Architecture

Anurag Kashyap — Sun, 26 Apr 2026 10:53:59 +0000

I Built a Suite of 6 Financial Tools in My Browser Stack — Here's the Architecture

KashVector is live. Six free, client-side financial tools at kashvector.com. No login, no backend database, no data leaving your device. Everything runs in the browser.

I came back to coding after 15 years away — last time I wrote software was mobile apps before the iPhone. I used Claude Code as my development partner throughout. This is a writeup of the architecture, the key decisions, and the AI-assisted workflow I built around it.

The Tools

Stock Evaluator — scores any ticker against Buffett, Dalio, and Graham frameworks using live Yahoo Finance data
Budget Planner — six-step wizard with payslip parsing, waterfall spending chart, and savings benchmarks
Debt Recycling / Investment Property Calculator — models converting home loan debt to tax-deductible investment debt
Portfolio Health Check — concentration risk analysis across sector, region, and individual stocks
FIRE Calculator — Financial Independence number, time-to-retire, and Coast FIRE target
Mortgage Calculator — repayments, total interest, and offset/extra repayment impact modelling

Architecture: Deliberately Boring

The hosting stack is as simple as it gets:

GitHub → Cloudflare Pages (auto-deploy on push)
         ↑
         Cloudflare Worker (Yahoo Finance proxy only)

Cloudflare Pages serves all static assets. Every git push triggers an automatic redeploy — no dashboard clicks, no manual steps.

One Cloudflare Worker handles the only piece that couldn't be client-side: Yahoo Finance data. Yahoo requires a valid cookie and crumb authentication token on every request — you can't call it directly from a browser due to CORS and the auth handshake. The Worker (~150 lines of JavaScript) manages that handshake, fetches the financial data, and returns clean JSON with the right CORS headers. Every other tool — Budget Planner, Debt Recycling, Portfolio Health Check, FIRE, Mortgage — fetches zero external data. They compute entirely from what you type in.

The One Architecture Decision That Paid Off Twice

During planning for the Stock Evaluator, we made a rule: all financial logic must be pure functions with no browser dependencies.

No document, no window, no DOM manipulation inside calculation code. Scoring functions take numbers in, return numbers out. At the time it felt like unnecessary discipline for a browser app.

It paid off in two ways:

1. Android in a weekend. Capacitor wraps a web app in a native Android WebView. Because the calculation logic had zero browser coupling, npx cap sync pulled the web code into the Android project cleanly. No Kotlin. No Java. No rewrite. The same JavaScript that runs in Chrome runs inside the native app. Android Studio handled the signing keystore and AAB generation — the actual build-and-sign cycle took an afternoon to learn and became routine quickly.

2. Consistent logic across the suite. As I added more tools, the same discipline applied. Every calculator's core logic is independently testable and portable.

The Budget Planner: A Different Beast

Five of the six tools are vanilla JavaScript — single HTML files or minimal multi-file setups. The Budget Planner is the outlier: React + Vite + Tailwind, a full build pipeline.

That complexity was earned. The tool has:

A six-step wizard with conditional branching based on income type (gross vs net, PAYG vs self-employed)
Australian superannuation calculated separately from take-home pay
A waterfall chart (Chart.js) showing exactly where money goes
Savings rate benchmarked against Australian demographic data by age bracket

The feature I'm most proud of is drag-and-drop payslip parsing. Drop a PDF, Excel, or CSV payslip onto the income step and it auto-fills your income and pay frequency. Everything runs in the browser using pdf-parse and xlsx — the file is never uploaded anywhere.

Getting parsing right required handling a surprising variety of real payslip formats:

Fields in reversed order ("$4,200.00 — TOTAL NET PAY")
Labels like "TOTAL NET PAY - Bank Credit" as a single string
Date ranges written as "1 March – 31 March" for frequency detection instead of numbers
Superannuation listed as a deduction rather than a separate line

Key Bugs Worth Documenting

Dividend double-counting (Debt Recycling Calculator). The total loan balance wasn't decreasing year-over-year — it stayed nearly flat. The bug: dividends were being added to the investment portfolio value and counted in the cash flow used to pay down debt. Money was being recycled twice. The fix was a one-line deletion once I understood the mechanic, but diagnosing it required tracing the cash flow model step by step.

Chart.js resize loop (Debt Recycling Calculator). Charts were resizing every time the user expanded the year-by-year breakdown table, because Chart.js was recalculating dimensions after each layout shift. Fix: pin the Y-axis width via afterFit callback and call chart.resize() explicitly on the table toggle event.

CSS grid blowout (Budget Planner). The expense breakdown table was blowing past its container on narrow screens. Root cause: CSS grid columns default to min-width: auto, which means a long text string expands the column indefinitely. Fix: min-width: 0 on the column definition.

The AI Workflow I Built Around Claude

Using Claude Code as a coding partner is table stakes now. The more interesting thing is the structured workflow I built around it.

Superpowers Plugin

A set of workflow skills that enforce a sequence before any feature starts:

brainstorm → plan → implement → verify

The planning phase is where the pure-functions decision came from. Having a structured moment to think about architecture — before writing any code — consistently surfaces decisions that would be painful to retrofit later.

Peer-Review Sub-Agent (I Built This)

After finishing a feature, I trigger an isolated Claude agent that has zero context of how the code was written. It receives only the output — the files, the diff, the feature description. It reviews cold, like a senior engineer picking up someone else's PR.

It returns a prioritised issue list ranked by criticality:

Breaking bugs
Logic errors
Edge cases
Style / code quality

No anchoring to my decisions. No "we did it this way because." Just an independent read. It catches things I miss — usually edge cases around input validation and boundary conditions.

Lessons Learned File

After every project, Claude updates a running markdown file with things worth remembering. Before starting anything new, Claude reads it. This is how I stopped making the same debugging mistakes twice. The dividend double-counting bug went into that file. So did the Chart.js resize behaviour. Compounding knowledge across projects, not just within them.

What's Next

The stock evaluator Android app goes public once the Play Store closed testing completes (Google requires 12 testers for 14 consecutive days for new personal accounts before production access). More tools are planned — retirement modelling, property vs rent comparison.

All tools are free at kashvector.com. No sign-up, no tracking, no subscriptions.