DasKitta grew out of a genuinely annoying problem, NEPSE investors with multiple Meroshare accounts have to log into each one separately just to apply for a single IPO. Multiply that across family accounts and it becomes a repetitive chore every single time a new IPO opens. DasKitta exists to make that one click instead of five.
The core idea, bulk actions across accounts
The whole platform is built around one concept, letting a user link multiple Meroshare accounts and act on all of them at once. Apply to an open IPO across every linked account simultaneously, check allotment results for all of them together, browse application history in one place. Once that core loop worked, everything else, portfolio views, market data, dashboards, became additions on top of a genuinely useful base.
Handling credentials without becoming a liability
The riskiest part of this idea is obvious, storing Meroshare credentials for multiple accounts means becoming a target if that data leaks. Passwords are never stored in plaintext, they go through AES encryption before hitting the database and get decrypted only at the moment of authenticating with the Meroshare API. On top of that, JWT handles session auth so every protected endpoint validates a signed token before a request ever reaches a controller.
Choosing Spring Boot for the backend
Java and Spring Boot were not the obvious pick for a side project, but the strict structure paid off once the app grew past a handful of endpoints. Separating controllers, services, DTOs and repositories cleanly meant that IPO logic, account management and NEPSE market data fetching stayed isolated from each other. A global exception handler using RestControllerAdvice meant every error response stays structured and consistent, and no internal stack trace ever leaks back to the frontend.
Live market data was its own challenge
Pulling live NEPSE index data, gainers and losers, and per scrip price charts meant building a dedicated NEPSE client layer, including a token manager and symbol resolver just to keep requests to the exchange authenticated and mapped correctly. This ended up being one of the more fragile parts of the system, external market data sources are not always predictable, so caching and retry handling mattered more here than almost anywhere else in the app.
What i would improve next
Right now allotment checking and IPO application both hit each linked account's session individually, which works but does not scale gracefully as more accounts get added. A queued background job system would handle this more reliably than doing it synchronously on request. It is on the list for a future pass.
DasKitta is live if you want to see the dashboard, IPO flow and live NEPSE ticker in action.