For four years, I led analytics for one of the largest AI vendors serving Fortune 500 manufacturers, surfacing more than $15M in hidden quality losses from data already sitting in their systems. I now apply the same systems thinking directly for operators, founders, and data leaders who need a production-grade decision system, not another slide deck.
Transform documents, records, and knowledge bases into a system your team can query in plain language.
Clean, enrich, and automate operational data at scale, without manual reconciliation.
Production applications and dashboards built around your workflow, not a generic template.
Deployed on infrastructure your engineering team already recognizes. No exotic dependencies, no lock-in.
Cities generate thousands of public grievances daily: roads, drainage, waste management, street lighting. This data is publicly available, yet it remains fragmented across individual complaints. Cities cannot identify recurring failures, accountability gaps, or citywide trends.
Governments now publish more operational data than ever. Most public systems, however, are still built to track individual complaints rather than surface citywide patterns. Advances in search and language models make it practical to query large civic datasets in plain language, replacing complex dashboards and SQL.
Publyq converts raw public grievance records into a searchable civic intelligence layer. By combining data enrichment, geospatial mapping, and conversational analytics, it lets users understand what is happening across a city instead of searching through thousands of individual complaints. The same systems thinking I applied to Fortune 500 manufacturing data, now directed at public infrastructure.
Keeps conversational analytics responsive while reducing inference cost and eliminating dependence on external APIs.
Lower reasoning capability than frontier models, offset by materially better control over latency, privacy, and operating cost.
Public grievance data is highly structured. It benefits from relational queries, spatial enrichment, and deterministic retrieval ahead of language model inference.
Greater engineering effort during data ingestion, in exchange for more reliable and explainable answers.
Every bank exports statements in its own format, with different column names, date formats, and transaction descriptions. Understanding real spending, savings, and runway across several accounts requires opening each statement by hand and reclassifying the same recurring merchants every month. Most people fall back to a rough mental estimate of where their money goes.
Bank-exported statements are universally available, yet remain fragmented across formats and institutions. Advances in document parsing and transaction intelligence now make it possible to consolidate these records into a single, structured financial ledger that works consistently across banks.
Kashiq automatically parses bank statements, categorizes transactions, and combines multiple accounts into a single, searchable view of personal finances, with intelligent transaction clustering.
Strengthening the parsing and auto-clustering engine to support multi-format document ingestion (PDF, CSV, XLSX) and MECE-based transaction classification.
Clusters are keyed on the normalized counterparty and debit or credit direction only, not amount or bank. A recurring merchant, such as rent or a food delivery app, is grouped into a single cluster regardless of amount or account, so it is classified once.
Correctness depends entirely on clean counterparty extraction. Two distinct payees with similar noisy descriptions can collide into the same cluster if the name-cleaning rules are not precise enough.
Bank statement descriptions follow predictable prefixes, including UPI, NEFT, RTGS, IMPS, ATM, and POS. A sequential regex pipeline extracts clean merchant names without a model call per row, keeping parsing instant, free, and fully explainable.
Each new bank or statement format requires an explicit pattern addition. Formats outside those rules fall back to a generic heuristic, less accurate than the bank-specific matchers.
For a single-user, self-hosted tool, a flat JSON file keeps the dataset transparent, portable, and simple to back up or inspect, without the operational overhead of running a database.
It will not scale to concurrent multi-user access or high transaction volumes. For one person's transaction history, it remains simpler to reason about and debug than a full relational database.
You work directly with me, the person who scopes, builds, and ships the system. There is no account-manager layer, no junior developers learning on your project, and no markup for a team you will never speak with.
Every engagement is scoped and fixed-price before work begins. We agree on scope and investment together once I understand what you need built, so there is no open-ended hourly billing and no surprises.
Yes. I build on infrastructure your team already recognizes, including PostgreSQL, FastAPI, React, and standard cloud platforms, so there is no lock-in and your engineers can extend or take over the system after handoff.
I am glad to sign an NDA before any detailed discussion. My default architecture is privacy-conscious, including locally hosted models where it matters, rather than routing your data through third-party APIs by default.
Sometimes. More often, clients use me to move quickly on a defined system now, then hire in-house once the value is proven. I will tell you honestly which situation applies to you.