Things I built, and what was actually hard about them.

Salongraphy is a two-sided hiring platform: artists build a portfolio and apply for work, salons post jobs and hire. I built the whole thing: the Express API, the Postgres schema, the Flutter app on the Play Store, the server-rendered marketing and discovery site, and the internal admin console. I run it in production.

The interesting part is not any one screen, it is that four codebases share one API contract without drifting. The admin console is a backend-for-frontend: the browser never sees a token, every call is same-origin through Next route handlers, and a single refresh-and-retry hop handles token rotation so an expired access token never reaches the user as an error.

• REST API of 60+ controllers over a 45-table Postgres schema: profiles, job posts, applications, a social feed with comments and reporting, follows, search, and subscriptions.
• Role-based admin console with a permission matrix, immutable audit logs, post moderation and a user-deletion pipeline, running as a backend-for-frontend so no token ever reaches the browser.
• Monetisation across three payment providers: Razorpay, Google Play billing and Apple IAP, behind one eligibility service that decides what a given user may actually do.
• Background workers on BullMQ for push notifications and email, with per-route rate limiting, client version gating and a locality index seeded from Indian locality data for geographic search.
• Flutter client in clean architecture: 300+ files split across domain, data and presentation layers, Riverpod for state and go_router for navigation.

Apache Fory is a multi-language serialization framework. Its IDL compiler could already emit model types for eleven languages, but gRPC service generation was landing language by language. I owned Dart and Swift: a Fory IDL service definition now produces an idiomatic client and server in both, across all four gRPC shapes and all three schema frontends.

Both PRs are merged into apache/main and shipping. Along the way I found and fixed a runtime divergence in Fory's Swift implementation: under reference tracking, Swift wrote a different reference flag for value-type structs than Java, Rust and C++ did, so Java could not read Swift-produced bytes. Swift now follows the same convention as the other runtimes.

• Dart generator (#3723): client and service base per schema, covering unary, server-streaming, client-streaming and bidirectional RPCs, with no manual Fory registration required at startup.
• Swift generator (#3776): providers, an async client, service metadata and stream adapters for grpc-swift, with a per-thread Fory runtime because the Swift runtime is single-threaded and a shared instance raced under ThreadSanitizer.
• Symbol-collision preflight that fails generation before writing files when two declarations would claim one identifier: namespace enums, duplicates, flattened helpers, names that normalise together, and nested declarations.
• Cross-language interop driven in both directions against a Java peer, across all three schema frontends, wired into CI on every relevant change.
• Reserved-name guarding: generated classes inherit from gRPC base types and Object, so an RPC named `ToString` produced an invalid override. Codegen now detects that and fails with a clear diagnostic.

Vajra is two systems that talk to each other. The detection engine is a C++ and Python pipeline that captures traffic through DPDK kernel bypass, inspects it, scores it with ML models, and responds by pushing firewall rules. The command center is a Flutter desktop app that launches the engine, subscribes to its live event stream over WebSocket, and renders threats and flows in real time.

The engine runs headless; the app is the operator's window into it. Team Sudarshana built it for Smart India Hackathon 2025 and won at the national level against a field of more than 50,000 participants.

• High-throughput TCP/IP packet pipeline in C++ over DPDK with vfio-pci: capture moved into user space, zero-copy I/O, inline feature extraction and entropy calculation.
• Suricata running on DPDK alongside it for line-rate deep packet inspection, protocol decoding and signature matching.
• Encrypted-traffic analysis that flags exfiltration, port scanning and C2 patterns on TLS sessions without decrypting them, plus a UBA engine for insider-threat signals.
• SOAR layer that generates iptables and nftables rules at runtime in response to detections, with every action recorded through a unified logger.
• Live WebSocket event stream into a cross-platform Flutter command center showing threats, flows and analytics as they happen.

Carbon-aware scaling is easy for batch and stateless workloads, which is where most tooling points. Stream processors are the awkward case: stop one carelessly and you throw away in-flight windowed state and break exactly-once processing. GreenOps handles that case. It watches grid carbon intensity, and when the grid turns dirty it suspends the Flink job, but only after its state has been safely captured to a savepoint.

The rule the whole system is built around: a job is never suspended unless its state is safely captured first. A failed or timed-out savepoint aborts the suspension and leaves the cluster running. Suspension goes through the FlinkDeployment rather than scaling the Deployment directly, because the Flink operator owns that Deployment and will undo any replica change made behind its back.

• Custom CRD and operator reconciling every 60 seconds: patches FlinkDeployment state to suspended, lets the Flink operator take a savepoint, then resumes from that savepoint path on a clean grid.
• Three scheduling policies: threshold, forecast (declines dirty windows too short to pay for the savepoint and restart), and optimising (prefers the jobs avoiding most carbon per second of disruption under a concurrency cap).
• Replayed over fourteen days of a simulated grid curve, the forecast policy kept 92% of the carbon saving for one-seventh of the suspensions and zero wasted ones.
• Self-calibrating cost prediction: the operator times its own suspends and restarts and keeps a rolling history, moving from static constants to observed percentiles to ridge regression on state size and parallelism as evidence accumulates.
• Ships as a Helm chart with a one-command local environment: Minikube, MinIO, the Flink operator, a sample job and the full monitoring stack.

Instead of switching to a separate UI to ask whether a table is healthy, where its data comes from, or who owns it, your team types `/datapulse` and gets a Block Kit answer in seconds. It also works in the background: polling OpenMetadata every fifteen minutes for newly-failing quality tests, and posting a 9am digest with the tables that need attention and an overall platform health score.

• Search, data-quality, lineage and ownership commands rendered as Block Kit, with a two-level upstream/downstream lineage tree.
• Resilience built in: retries, a circuit breaker around the OpenMetadata client, per-user rate limiting and friendly error messages rather than stack traces in a channel.
• Shipped alongside an upstream contribution to OpenMetadata itself: a StarRocks connector fix querying INFORMATION_SCHEMA for table comments.

A trained prediction model exposed through a Python inference API, wrapped by a Node backend that handles auth, roles and report storage, and consumed by a Flutter app. Clinicians submit a case, get a prediction and a stored report; an admin surface reviews what the model has been asked and what it answered.

• Model developed and evaluated in notebooks, then served behind a stable HTTP inference contract rather than shipped as a notebook.
• Node/Express backend with JWT middleware, admin role gating, and persisted prediction reports.
• Flutter client covering auth, submission, report history and an admin page, plus a companion marketing site.

Customers post orders, builders bid on them, and the platform manages the lifecycle between the two. The backend is a properly structured Express service: versioned migrations, request validation middleware, rate limiting, refresh-token auth and email OTP, with a Flutter client on top and CI on every push.

• Order, sub-order, bid and interested-builder models with a migration runner rather than ad-hoc schema drift.
• Layered middleware: auth, validation, rate limiting and centralised error handling, with structured logging and env validation at boot.
• Dockerised backend with a GitHub Actions pipeline.

ER triage is time-consuming during peak hours, inconsistent under human error, and prone to delay when staff are short, a failure mode the COVID-19 surge made obvious. VitalSense classifies incoming patients as severe or non-severe from real-time physiological data so the critical ones are seen first.

• Full pipeline from raw vitals through feature engineering to a severity classifier, with the problem framing and evaluation written up alongside the model.

Save, fetch, list and delete code snippets over gRPC. Small by design: it was the groundwork for the Dart gRPC codegen that became my Google Summer of Code project at Apache Fory, and it is where the shape of an idiomatic generated Dart client got worked out by hand first.

• Service and message definitions in proto, a server, and a demo client exercising every RPC.
• Directly informed the design that shipped in apache/fory#3723.