# Jaskirat Randhawa > Senior Product Manager at Fastly, managing developer platforms for edge compute. Previously co-founded a climate tech company and built machines that 3D print glass. ## Blog Posts ### A self-hosted e-ink dashboard for my PM context fatigue *2026-05-16* · PM work means juggling many technical contexts a day. I needed a list that stayed visible without becoming a second monitor. Here's what I built and what changed. I'm a PM at [Fastly](https://fastly.com). On a normal day I'm in three to twelve different deeply technical contexts: API planning in the morning, a customer design review after lunch, developer-tooling roadmap at 4pm, 1:1s with engineers in between. Each one wants my full attention. Each one gets some, then gets dropped, then gets picked back up. ## What wasn't working The dropping and picking back up is where the cost lives. Call it context fatigue: each handoff is small, but they compound across a day. I had a Notion database that listed what I was working on. *Today, In Progress, Upcoming.* When I actually looked at it, it helped. The list itself wasn't the problem. The problem was where the list lived. Notion is a tab in a browser, or an app in the dock, jostling with other tabs and other apps. The moment I switched to Slack to answer an engineer, or to a design doc that needed my full head, the list slipped out of sight, which was, by definition, exactly when I needed it most. Out of sight, out of mind. I never built the habit of looking. Going back required remembering it existed, which was the thing the list was supposed to do for me. I tried the usual things first. Paper (bullet journals, sticky notes) doesn't hold URLs, and half my context lives in URLs. A second monitor with Notion always open eats desk space and adds another sheet of always-on glass to a room I already sit in for ten hours a day. Focus apps were aimed at the wrong problem. I didn't need discipline. I needed a list that didn't disappear. ## What I needed What I wanted was a small, dedicated, persistent surface that showed the list and only the list. Always visible, no chrome, no notifications, no animation. Pulls from Notion so I never have to type the same task twice. Sips power. Doesn't compete with anything else on the desk because it isn't trying to. E-ink is exactly that, when it's allowed to be. It draws power only on refresh. It looks like paper. It sits there. It's wireless, and I've charged it once in three months. Low maintenance, hacker-friendly, zen. ![The TRMNL on my desk showing the Notion kanban during work hours](/images/posts/trmnl/kanban.jpg) ## Why I built it I looked at a few hosted dashboard products. Most of them are good at what they're for, but the polished ones want you to use *their* layouts and *their* data sources. I wanted the data to be Notion, the layout to be mine, and the device to be small. So I built it. It's not that hard. [TRMNL](https://usetrmnl.com) made the device part easy: a 7.5" e-ink panel that polls a server, gets back a Liquid template plus data, renders server-side, dithers for the panel, shows it. You can use their hosted service or BYOS (Bring Your Own Server) and run their LaraPaper container yourself. I'm BYOS, on the [NAS from earlier](/blog/homelab-fanless-qnap), with two small adapters I wrote on Fastly Compute (kicked the tires on Compute while I was at it). Notion kanban during work hours; an "earth from above" photo from Unsplash otherwise, because if it's going to be on the desk it might as well be nice to look at when I'm not working. ![Close-up of the TRMNL panel rendering the Notion kanban: Today, In Progress, Upcoming](/images/posts/trmnl/kanban-closeup.jpg) > ## The list stopped being a tab and became a place. Always visible, never demanding. ## What changed The setup is small. What it shifted isn't. I pay attention to fewer things. The list of what's important is right there, all the time, and the act of looking at it is the act of remembering. I finish more high-priority work because high-priority work has a permanent visual home. When I come back from a context switch, the list is still there, in the same place, with the same shape. Context-switching stops feeling like dropping a stack of plates and starts feeling like turning a page. There is less clutter on the desk and, more usefully, less clutter in my head. I didn't expect the wellbeing part. Switching contexts now feels relaxed. The screen is the visual entrypoint into the rest of the work; I can pick up exactly where I left off in Notion because the list told me where that was. The weight of holding a dozen open threads in my head (the part that was stressful) got externalized to a piece of paper-that-isn't-paper. Not a small change. ![The TRMNL showing an Earth-from-above photo in the evening](/images/posts/trmnl/earth.jpg) ## What I'd do differently If I were starting again, I'd go larger. The 7.5" panel was the right place to start because the problem was urgent, the device was cheap, and the build was a weekend. The next iteration probably wants to render an actual Notion screenshot directly rather than reconstructing the kanban out of TRMNL's UI components, closing the gap between *what I see* and *what I edit*. Same problem, more fidelity. Until then: out of sight is no longer out of mind. Which was most of what I needed. --- ### Part 3 of 3: The 11pm-in-an-airport test *2026-05-04* · Making my home services feel like real websites, regardless of device or network. One hostname, one autofill, no browser warnings. Part 3 of 3. *Previously: [Part 1: A fanless NAS, a windowsill, and one user](/blog/homelab-fanless-qnap) · [Part 2: The patchwork I'd been calling a homelab](/blog/homelab-patchwork)* It is 11pm. I am in an airport. Plex has wedged itself and is refusing to stream. I need to log into the NAS from my phone to restart one container and get on with my life. I am hunting for the LAN IP I never bothered to memorize. I am fishing the admin password out of my password manager by searching "QNAP" because the saved URL doesn't match anything I'd type. I am trying to remember whether I'm on airport wifi (NAS reachable via Tailscale's subnet route) or whether I'd already brought up Tailscale on the phone (NAS reachable directly). This is the friction I built the rest of this setup to kill. > ## The moment you need to fix something is the moment you have the least patience for friction. The ask, in product terms: same hostname, same autofill, no browser warnings, regardless of device or network. If I have to think about how to log in, I've already lost. ## The IP was already solved The whole problem collapses if you accept one observation: my NAS advertises `192.168.x.0/24` as a Tailscale subnet route. So `192.168.x.163` (the NAS) is reachable from anywhere on the tailnet, not just on the home network. Same IP, two contexts. That means *the IP is already solved*. The only thing left is *name resolution*: making `immich.home.arpa` resolve to the NAS from every device, regardless of which network the device is on. I'm using `.home.arpa` because it's reserved by [RFC 8375](https://www.rfc-editor.org/rfc/rfc8375) for residential networks. It will never resolve publicly. No registrar, no domain renewal, no chance of collision with something I might buy later. Two paths to resolution, one per device class: - On the iPhone, AdGuard already runs as my DNS (from Part 1). One wildcard rewrite (`*.home.arpa → `) covers every service at once. It works at home (LAN to AdGuard) and traveling (Tailscale subnet route to AdGuard), with no client-side configuration. - On the Mac, a single line in `/etc/hosts`. No DNS daemon, no VPN-vs-DNS interaction. The line works on hotel wifi, home LAN, PIA, Tailscale, in any combination. ![One hostname resolves through three different paths (Mac via /etc/hosts, iPhone via AdGuard wildcard, traveling laptop via Tailscale subnet route to AdGuard) and all converge at Caddy on the NAS](/images/posts/homelab/name-resolution-paths.svg) ## Why AdGuard has its own LAN identity A short architectural note that earns the rest of this. AdGuard isn't a process on the NAS, even though it runs there. It's a separate peer on the LAN, with its own MAC, on its own static IP (`192.168.x.100`). I run it on a virtual switch in macvlan mode so it gets its own L2 identity. The point is decoupling. The Tailscale ACL and every device's DNS pointer reference `192.168.x.100`, not the NAS host's IP. If the NAS were rebuilt or replaced, AdGuard could come back at the same `.100` and nobody else would have to be reconfigured. You don't get this for free with `network_mode: host`. You get this by treating "the DNS server" as a thing that has its own LAN-routable presence, independent of the box it happens to run on. ## TLS without the busywork Browser warnings are papercuts. I wanted real HTTPS for `immich.home.arpa`, `plex.home.arpa`, and so on, even though none of these are public services. Three options I considered: 1. mkcert per service. Configure TLS in each app individually, mount certs in each container, track renewals manually. Adding a service means cert work plus app work. 2. A public domain with Let's Encrypt DNS-01. Real publicly-trusted certs, but it requires owning a domain and an ACME-capable DNS provider. Overkill for purely internal services. 3. Caddy with `local_certs`. One reverse proxy that runs its own internal CA, issues certs on demand, renews automatically, and terminates TLS for every service behind it. Trust the CA on each device once. I went with Caddy. Adding a service is one stanza in the Caddyfile: ```caddy immich.home.arpa { reverse_proxy 127.0.0.1:2283 } plex.home.arpa { reverse_proxy 127.0.0.1:32400 } service.home.arpa { reverse_proxy 127.0.0.1:8080 } ``` ## The airport, replayed It's 11pm. I'm in an airport. Plex has wedged itself. I open [Termius](https://termius.com/) on my phone and SSH into `nas.home.arpa`. Tailscale is already up, so the hostname resolves and the tunnel routes me there. I run `dcr plex` (a shell alias for `docker compose restart plex`) and the service comes back. Less than a minute, start to finish. The rest of the experience clicks into place the same way. The page loads with a real green padlock (because the CA is installed on my devices, and Caddy issued the cert from it). My password manager autofills the login form because the URL matches the entry I saved at home. The same hostname resolves through three different paths depending on which combination of LAN, hotel wifi, Tailscale, or PIA I'm on, and they all converge at Caddy on the NAS. Same hostname. Three networks. One mental model. If you've made it through all three posts, this is the whole thing. It's small and dependable. It does what I do at home and gets out of the way for the rest. Future me at 2am can fix it without asking present me anything. --- ### Part 2 of 3: The patchwork I'd been calling a homelab *2026-04-25* · What it took to stop being the patch pipeline for my own NAS, and the AdGuard scare that finally made it urgent. Part 2 of 3. *Previously: [Part 1: A fanless NAS, a windowsill, and one user.](/blog/homelab-fanless-qnap)* A year ago, my "homelab" looked nothing like the post you just read. It looked like this. - **Tailscale** was installed as a native QPKG package, because the version in the NAS App Center was old enough to break tailnet behavior. I'd gone out of band, which meant manual updates from then on. - **AdGuard** was running through Container Station's clicky UI, with what turned out to be no persistent volume. - **Plex** came from the App Center, on App-Center's update cadence, which is whatever it is. - A handful of other things were in Docker Compose, because that's where I'd started doing it right. Four installation methods. Four update cadences. Four UIs. Four failure modes. One NAS holding all of my personal data. ![Before and after: four installation methods consolidated into one Docker Compose stack with Watchtower auto-update and ntfy push notifications](/images/posts/homelab/migration-before-after.svg) ## I was the patch pipeline The Tailscale situation should have alarmed me sooner. The reason it ended up out of band is that the App Center version was lagging upstream by enough that my tailnet was actively misbehaving. So I bypassed the App Center, which felt clever at the time, and which then meant *I* was the update mechanism, forever. > ## Out-of-band installs mean I'm the patch pipeline. I'm bad at being a patch pipeline. I learned this lesson the day I noticed I'd been running a Tailscale build with a known CVE for several weeks, because I hadn't checked. The box has my photos. My media library. Sensitive personal data I'd rather not enumerate publicly. Treating its security update path as "things I'll get to" was a posture I couldn't defend if pressed. One out-of-band install is manageable. Four is four separate pipelines I'm now responsible for, and I am not staffed for that. ## AdGuard was the canary The acute moment was AdGuard. I'd set it up months earlier through Container Station's UI, because that's what the documentation suggested and the UI made it easy. Click, click, running. Filter lists configured, DNS rewrites in place, query log accumulating, life good. What the UI never asked me, and what I never thought to check, was *where* any of that state was being stored. The answer was: nowhere persistent. Container Station hadn't configured a volume because I hadn't told it to, and the UI didn't surface that the writable container layer was the only thing holding my config. One `docker rm` and the entire AdGuard configuration would have been gone, with no warning and no recovery. I'd been running it that way for months. The fix was straightforward (copy the live config out of the running container, set up a Compose service with a real bind mount, restore the config). The lesson was that the UI hadn't lied to me. It just didn't know enough to warn me. *Trust the UI* was the failure mode, and the patchwork was symptomatic. AdGuard was the canary and the mine was every other service that had been clicked into existence the same way. ## The IaC instinct Every other system I touch professionally lives in Git. Configs are diffed, reviewed, and rolled back. State is explicit. When something breaks, the question "what changed?" has a real answer. I wasn't doing any of this for the box that holds my personal data, because the NAS UI made it convenient not to. So I migrated everything to Docker Compose. The point was *one mental model*. Every service comes up the same way. Every service fails the same way. Every config change is a `git diff`. When something breaks at 11pm, I know how to triage it without remembering which UI I clicked through six months ago. This was not a clean weekend. Each service had its own flavor of "where exactly is the state, and what happens when I move it?" Plex's metadata library, Immich's Postgres directory, Tailscale's tailnet identity. Each one needed a careful copy from old-home to new-home, then a careful restart, then a careful verification. ## Auto-pilot, with a brake I do not, in fact, want to be the update pipeline at all. Even with everything on Compose, manually checking image versions is the kind of chore I will reliably let slide. [Watchtower](https://github.com/containrrr/watchtower) handles this. Every morning at 4am it checks for new images and pulls anything updated. Containers get recreated with the same Compose config. If a service fails to come up, the restart policy keeps the previous version running. The brake is that Watchtower is **opt-in via container label**. I add `com.centurylinklabs.watchtower.enable=true` only to services where I'm comfortable with auto-updates. Plex, Immich, AdGuard: yes. Anything fragile, or where I'd want to read release notes first: no. A breaking image push doesn't take down the whole stack, just the services I've explicitly trusted. When something does change, I get a push notification. Self-hosted [ntfy](https://ntfy.sh/) for the actual server, with one trick: ntfy.sh acts as the upstream relay for iOS background push. The relay only sees a content-free wake-up; my phone fetches the real message body from my self-hosted ntfy. Messages stay private, push works at all, and I'm not running a separate Apple Push Notification cert at home. The result: updates happen without me, and a notification arrives only if something changes. The box is asking less of me, not more. ## Bonus: clean architecture paid me back Here's something I didn't plan for. Once everything was in Compose with clean network boundaries, sharing Immich albums publicly (so family could view photos without joining my tailnet) became *trivially safe*. I spun up a stateless [public proxy for Immich](https://github.com/alangrainger/immich-public-proxy) in its own container, attached to a dedicated Tailscale Funnel sidecar, with the public blast radius scoped to exactly that one container. Immich itself stays fully private. The shared proxy gets a real Let's Encrypt cert via Funnel's `*.ts.net` hostname. That kind of pattern is awkward to do safely in a patchwork setup. In a clean Compose setup, it's a stanza in a yaml file. ## What's coming [Part 3: The 11pm-in-an-airport test](/blog/homelab-airport-test) is the airport-friction post: making my home services feel like real websites, with the same hostname and the same password-manager autofill regardless of device or network. --- ### Part 1 of 3: A fanless NAS, a windowsill, and one user *2026-04-20* · How a music collection, an ad blocker, and an itch to tinker led me to build a small, dependable, single-user homelab. Part 1 of a 3-part series. Five things led me to put a NAS on a windowsill, in this order. 1. Manual backups and I have an unhappy history. My Mac has plenty of space, but my phone doesn't have a 1TB drive, and I was reliably not plugging in the external HDD on any schedule that could be called a schedule. Cloud backup would have solved it, except paying a subscription to compensate for my own laziness felt like admitting defeat. 2. I'm a Spotify premium user and I don't love it. (Don't @ me.) I want the iTunes-era folder-and-artist compact view, not whatever Spotify's interface is doing now. Plex serving my own library scratches that itch in a way Spotify never has. 3. Ads on my phone had become personal. Blocking them sent me to Pi-hole, which made me realize I could host a lot more than that if I had something to host it on. 4. I love my password manager, right up until it refuses to autofill because the saved URL is a raw IP address I never typed the same way twice. 5. The amateur engineer in me was clamoring for an excuse. You know the feeling. *Custom builds.* So I bought a small fanless NAS (a QNAP TS-410E, if you want the specifics), populated it with SSDs, perched it on a windowsill behind a curtain, and have since learned more about Docker, DNS, TLS, and route tables than I expected. ![A QNAP NAS sitting on a windowsill beside a plant](/images/posts/homelab/qnap-windowsill.jpg) ## The box A Celeron N5095 with no fans. SSD-only. The whole thing is silent enough that I forget it's there until something pings me. It sits behind a curtain, in the corner of a room I don't otherwise spend time in. You wouldn't notice it, and that quietness is the whole point of the form factor. A fair number of homelab posts open with a rack diagram and forty-something services in Portainer. That's not what's happening here. My homelab has one user. Me. That constraint shapes everything. I don't need high availability. I don't need clustering. I don't need to learn Proxmox right now (the geek itch is loud, I'm aware). The goal was to use this thing, not maintain it. > ## The goal was to use this thing, not maintain it. ## What's running The full inventory: - Tailscale for off-network access, advertising the home subnet so I can reach everything else by its LAN IP. - AdGuard filters ads and trackers for every device in the household. - Caddy is the reverse proxy and TLS terminator for everything else. - Plex serves the aforementioned music collection (and TV). - Immich holds the photos. - TRMNL drives the e-ink dashboard on my desk. - ntfy pushes notifications from the NAS to my phone. - Watchtower auto-updates everything else. That's it. If you came here for a screenshot of forty-seven services, wrong blog. The list above covers what I do at home: listen to music, look at photos, browse without ads, see one or two pieces of useful information, and get told when the box wants my attention. ## The mental model After a year of running a messier version of this, and learning what hurts, I converged on three rules. They are deliberately unimpressive. 1. **Every service is `docker compose`.** Same up command, same down command, same logs command, same diff in Git. One mental model applied uniformly beats nine clever per-service workflows. 2. **Every incident lives in `troubleshooting.md`.** When something breaks at 11pm, I want to find the answer fast, not re-derive it. 3. **Every non-obvious decision lives in `decisions.md`.** Why are we using Caddy's local CA instead of mkcert? Why is AdGuard on its own LAN IP? Why didn't we just port-forward Immich? Future me has a habit of relitigating these questions, so I write the answer down once and link to it. ## The whole shape Here's how traffic flows. Same hostnames at home and on tailnet, terminating at Caddy on the NAS, distributed to whichever container owns the request: ![Network traffic flow across home LAN and tailnet, all converging at the QNAP NAS](/images/posts/homelab/network-flow.svg) Four ideas hold this together: - One stable IP for DNS (AdGuard) so devices, routers, and Tailscale ACLs all point at one thing. - One stable IP for everything else (the NAS) so Caddy can do TLS and reverse-proxy in one place. - [Tailscale](https://tailscale.com/) for off-network access without exposing anything publicly. - AdGuard filtering applied to every device in the household, regardless of platform. ## What's coming It did not start out this clean. The next two posts cover how it got here. - **[Part 2: The patchwork I'd been calling a homelab](/blog/homelab-patchwork)**: a NAS with services installed four different ways, no auto-updates, and a DNS resolver one `docker rm` away from oblivion. The migration to one mental model, with auto-pilot updates that tell me when something happened. - **[Part 3: The 11pm-in-an-airport test](/blog/homelab-airport-test)**: what it took to make my home services feel like real websites, with the same hostname and the same password-manager autofill regardless of which device, which network, or which VPN I happened to be on. If you're here because you also want a quiet, dependable, one-user homelab and you're allergic to maximalism, the next two posts are written for you. --- ### ClimaSens: What Wearing Every Hat Actually Taught Me *2018-06-01* · Co-founding a climate intelligence platform, building the full stack, falling in love with maps, and learning when to stop engineering and start shipping. *Role: Co-founder / Full-Stack Developer · 2018–2023* ClimaSens is a climate intelligence platform for urban spaces. We helped organizations monitor micro-climate variations and assess the impact on their operations, from heat risk on buildings to disaster resilience across entire cities.
## Building everything from scratch At ClimaSens I built across the entire stack. The frontend was Nuxt.js, rendering dense geospatial visualisations (heatmaps, time-series overlays, interactive risk layers) on top of mapping libraries. The backend was a constellation of data pipelines ingesting real-time IoT sensor observations, historical climate records, and remote-sensing satellite data. Kubernetes orchestrated it all. Getting my hands dirty with every layer taught me what good developer experience means. Why clean APIs matter, why observable systems save you at 2am, why the gap between "it works on my machine" and "it works in production" is where most engineering effort lives. None of that comes from a requirements doc. I had to feel the pain of a poorly indexed geospatial query or a flaky deployment pipeline to internalise it.
## Falling in love with maps Working with geospatial data changed how I see the world, quite literally. There is something deeply satisfying about transforming raw climate observations into a map layer that makes a pattern immediately obvious. A spreadsheet can tell you a suburb is getting hotter; a well-rendered heatmap makes you *feel* it. Every new data source (satellite imagery, weather station feeds, IoT sensor networks) was another lens on the same physical reality. Layering them to find heat islands, flood risk corridors, or infrastructure vulnerability became addictive. I still carry that obsession into everything I do. ## The "many hats" trap Here's the part nobody puts on their LinkedIn: wearing every hat is over-glorified. For a stretch, I was so deep in the engineering (optimising pipelines, debugging Kubernetes networking, refactoring the frontend component architecture) that I lost focus on my product sense. I was romanticising the technical problems instead of asking the harder question: *who is this actually for, and does it solve their problem today?* I had to course correct. I stepped back from the codebase, talked to users, and forced myself to ship an MVP that was good enough rather than architecturally perfect. ## Landing it where it mattered That MVP became the tool we built with [Humanitech](https://www.humanitech.org.au/resources/climasens/) and [Australian Red Cross](https://medium.com/humanitech-au/making-sense-of-a-changing-climate-7c7988e6e1e1). Together we co-developed a location-based mapping tool that combined climate data with social and health information to identify populations vulnerable to extreme heat events. The pilot focused on South Australia's Telecross REDi program, which provides phone support to isolated people during heatwaves. Extreme heat causes more deaths in Australia than bushfires or cyclones. Our platform helped Red Cross teams pinpoint where vulnerable people were, so outreach could be targeted rather than blanket. Seeing ClimaSens used in the field, by people who weren't thinking about Kubernetes or data pipelines but about which elderly residents needed a welfare call before a 45-degree day, was the most rewarding moment of the venture. It validated the product, and it reminded me why I'd started building it. What I kept from the course correction: know which hat you're wearing, and check whether it's the one the moment needs. See more at [climasens.com](https://climasens.com) · [Humanitech case study](https://www.humanitech.org.au/resources/climasens/) · [Medium write-up](https://medium.com/humanitech-au/making-sense-of-a-changing-climate-7c7988e6e1e1) --- ### Urban Systems Lab: Where I Fell in Love with Maps *2016-09-01* · My foray into geospatial data at NYU, building a mapping platform that spun out tools for climate resilience research across ten cities. *Role: Data-Visualization Lead · 2016–2019* Urban Systems Lab at NYU is where I first got my hands on real geospatial data. I joined as the technical lead for data visualization, tasked with building tools for the [UREx Sustainability Research Network](https://data.urexsrn.net/sets/), a consortium studying urban resilience to climate extremes across ten US and Latin American cities. What I didn't expect was how much it would change the way I think about data. ## What a table can't show you Before USL, I understood data as rows and columns. Relational databases, spreadsheets, CSVs. They work, but they abstract away something essential: *where* things happen. The moment I started working with geospatial datasets, something clicked. Overlaying social vulnerability indices onto a 3D cityscape of New York, watching flood risk data drape across building parcels at neighbourhood scale, I could suddenly *see* the story the data was telling. A table might show that a census tract scores high on a heat vulnerability index. A map shows you that it's the same block with no tree canopy, ageing infrastructure, and an elderly population. I fell in love with it. The tactile feeling of panning across a city and understanding its systems through layers of information was unlike anything I'd experienced with traditional data tools. That obsession with geospatial data has stayed with me ever since. ![](/images/case-studies/urban-systems-lab/img-1.png) ## Building a platform Early on, I made a deliberate choice that shaped everything that followed. Rather than building one-off visualizations for individual research papers, I pushed to build a proper mapping platform: something researchers could use without writing a single line of code, something that could outlive any individual project. Research software has a reputation for being disposable. Limited budgets, short timelines, and the publish-or-perish cycle mean most tools get abandoned the moment a paper ships. I wanted to break that pattern. I wanted to build something researchers would *keep using* to communicate their science. The platform I built used [Vue.js](https://vuejs.org/) with Nuxt on the frontend and Firebase for data storage, authentication, and real-time content updates. [Mapbox GL](https://www.mapbox.com/) handled the mapping layer, chosen for its support for 3D building extrusions, vector tiles, and custom styling. Content creators could update visualizations in real-time without touching code. ![](/images/case-studies/urban-systems-lab/img-2.jpg) That bet on building a platform paid off. The core mapping infrastructure became the foundation for multiple products that spun out of the lab: - **[Ocellus](https://urbansystemslab.com/featured-resources/2025/1/8/ocellus)** evolved into USL's flagship visualization tool, bridging quantitative social, ecological, and infrastructure data with qualitative insights from community workshops. It now serves as an interactive platform for researchers and urban planners across the UREx network. - **[Stormwater.NYC](https://urbansystemslab.com/featured-resources/stormwaternyc)** became a multi-hazard risk decision-support tool for New York City, integrating floodplain projections, demographics, land use, and critical infrastructure data. It was the first tool of its kind to offer integrated scenario comparison for flooding risk in NYC. - **[Green Roofs](https://urbansystemslab.com/featured-resources/2025/4/11/1hdl8icsx0uxqfrudap46nfenvygvi)** visualizations helped quantify the performance and coverage of green infrastructure interventions across the city. Each of these products built on the same mapping platform, the same geospatial pipelines, and the same design philosophy: make the data accessible so researchers can focus on communicating science, not wrestling with software.
## Bringing new tech to research I wanted to bring modern web technology into a space that still ran on desktop GIS tools and static images in PDFs. Researchers should be able to share an interactive 3D map as easily as a link. ### Geospatial narratives The feature I'm proudest of is the narrative system. Raw geospatial data, even beautifully rendered, needs interpretation. I designed and built a storytelling layer where researchers could author articles and choreograph map views to match their content. They could guide a reader's attention to specific neighbourhoods, zoom into building-level detail, and annotate what the data meant in context. We offered story templates (cards, long-form articles) so authors could pick the format that suited their message. ![](/images/case-studies/urban-systems-lab/story-layouts.jpg) Researchers could publish on the web with the same richness they'd get in a lecture hall, to anyone with a browser. ### Sharing perspectives User feedback made it clear that researchers needed to share specific views of the map with collaborators and in reports. I implemented a share feature with a link shortener so anyone could capture their exact perspective (location, zoom, active layers) and pass it along as a short URL or screenshot. ![](/images/case-studies/urban-systems-lab/share.png) ## The data pipelines underneath The visualizations sat on top of processing pipelines I also built. ### Spatial joins at scale The core challenge was taking parcel-scale disaggregated data and draping it over 3D cityscapes. Spatial joins on datasets this large (856,000 lots and over a million buildings in NYC alone) are computationally brutal. A naive single-core approach can take hours or days. ![](/images/case-studies/urban-systems-lab/spatial-join-2.jpg) I wrote a multi-threaded spatial join in JavaScript that operated on spatially indexed GeoJSON collections in MongoDB. The script tiled both datasets for batch processing, distributing the load across cores. The polygon-in-polygon join processed the entire NYC building and lot dataset in 17 minutes on a quad-core laptop. ### Raster to vector conversion Many of our source datasets arrived as massive GeoTIFF raster files. But to support interactive features like clicking, filtering, and on-the-fly styling, we needed vector tiles. I built a multi-threaded Python pipeline that ingested large raster files and output GeoJSON, which we then converted to MBTiles for serving to browsers. ![](/images/case-studies/urban-systems-lab/img-3.jpg) | File | Type | Size | |-----------------|--------|---------| | Original Tiff | Raster | 8.20 GB | | Raster Tileset | Raster | 508 MB | | 2-meter Tileset | Vector | 500 MB | | 5-meter Tileset | Vector | 150 MB |
## What it was used for The platform was used to communicate climate vulnerability and equity science across the UREx network's ten cities. The NYC map was used in work with the Mayor's Office of Recovery & Resiliency and the Science and Resilience Institute at Jamaica Bay. It was the first time 3D visualizations at parcel-scale resolution were used to examine equity in risk and vulnerability to climate-driven extreme events like coastal flooding and heatwaves. I also wrote a [cookbook](https://urbansystemslab.com/) with fellow USL researchers to document the principles behind geospatial visualization, so the work could continue and evolve as more researchers joined. ![](/images/case-studies/urban-systems-lab/cookbook.jpg) The platform didn't die when I left. It became Ocellus, it runs Stormwater.NYC, and researchers across the network still publish with it. ## Presented at - Data-Visualization Workshop at Modelling Complex Urban Environments, Waterloo Institute for Complexity and Innovation, Canada, 2018 - URExSRN Annual All Hands Meeting, demonstrated visualization platform, Phoenix Arizona, 2018 - Urban Climate Resilience at Ecological Society of America, 2018 - Data-Visualization Seminar at "Resilient Cities, Livable Futures" Data-Visualization Session, The New School, New York, 2017 --- ### Verizon: Conversational AI Before the GenAI Wave *2016-07-01* · Building chatbot experiences for 150M+ customers, developing real customer empathy at scale, and positioning for an AI shift we could see coming. *Role: Product Manager · 2016–2022* **Note:** *To comply with NDA obligations, I have omitted and obfuscated confidential information. The views expressed here are my own and do not necessarily reflect those of my employer.* ## Starting in the deep end I joined Verizon's Open Innovation Lab in 2016, fresh out of Parsons School of Design. The lab was a six-month residency where small teams researched new product opportunities and built functional prototypes within the constraints of the business. My focus was chatbots, and by the end we were pitching directly to leadership across the company. That residency turned into a six-year run on the Omni Customer Experience team, where I led conversational commerce strategy across all of Verizon's customer-facing channels: mobile apps, websites, social media, SMS, and business messaging. The scale was staggering. Over 150 million customers, and every one of them deserved a support experience that didn't feel like talking to a wall. ![](/images/case-studies/verizon/chatbot-cover.jpg) ## Learning what customer empathy actually means Everyone in product talks about empathy. In the chatbot world, it's easy to be bad at it. Early on, I realised that most automated experiences fail because nobody stopped to ask: *what just happened to this person before they opened this chat?* The technology is usually fine. That question became the foundation of how I thought about every use case. A customer who just saw an unexpected charge on their bill is in a completely different emotional state than someone browsing new plans. If the bot treats both interactions the same way, you've failed the first one. At Verizon's scale, neglecting even 1% of customers means 1.5 million frustrated people who trusted you to help them. I pushed for context-aware experiences that considered what the customer had just been through: what actions they'd taken, what events had occurred, what they likely needed right now. When we detected that someone was dealing with a serious issue, the right move was often to step back and hand off to a live representative for white-glove service. Knowing when *not* to automate was just as important as knowing what to automate. > ## The best automated experiences know when to get out of the way. This also meant getting the tone right. There's a Goldilocks zone in conversational design where responses don't come across as cold and robotic, but aren't trying too hard to be clever either. A brand serving customers of every age and background across the entire country needs to be inclusive and measured. I spent a lot of time with experience designers refining conversation flows, defining personality guidelines, and pressure-testing edge cases. Typography, response pacing, escalation triggers: all of it mattered. ![](/images/case-studies/verizon/my-role.jpg) ## Ahead of the curve on AI This was 2016 through 2022. GPT-3 launched in 2020, but generative AI as a mainstream product category didn't exist for most of my time at Verizon. We were building intelligent conversational experiences with the tools available: intent classification, entity extraction, decision trees, and carefully authored flows. It was painstaking, manual work to make a bot feel natural. But I could see where the technology was heading. The trajectory from rule-based systems to statistical NLU to transformer models was clear if you were paying attention. We started working with industry partners to evaluate and integrate the latest AI models as they became available, positioning Verizon's conversational platform to adopt generative capabilities before most enterprises were even thinking about it. What made this possible was that we'd built the right foundation. The platform architecture was designed to be model-agnostic: the conversation orchestration layer, the context engine, the channel abstraction. When better AI models arrived, we could plug them in without rebuilding the customer experience from scratch. That foresight, building for a future we could see coming even if we couldn't name it yet, is something I'm proud of. > ## We were solving for a generative AI future with pre-generative AI tools, and we built an architecture ready for the shift. ## What I carried forward Six years at this scale taught me things I couldn't have learned anywhere else. Customer empathy has to be an operational discipline, embedded in every product decision, every edge case, every escalation path. A design exercise doesn't survive contact with 150 million people. And the best product work at a large enterprise is the unflashy kind: something that works correctly for millions of people who just want their problem solved. And I learned to trust my read on where technology is going. Generative models have since remade conversational AI, and the principles we built around (context awareness, tone calibration, knowing when to hand off to a human) still hold. --- ## Projects ### Cognitive Flowers *Design & Technology · Dec, 2014* Interacting with tangible objects through non-invasive brain controlled interface. **Team:** [Jaskirat Randhawa](http://jaskirat.org), [Grace Jun](http://gracejun.com/) Cognitive Flowers explores physical computing and wearable technology. Our research was based on the concepts of Tangible User Interfaces, Zero UI (Theory that rejects the use of GUI & touch interfaces) and the concept of Ubiquitous Technology coined by Mark Weiser. The project sought to look into future interactions between a wearable head mount and physical artifacts to create an experience without interfaces. Could we go beyond Graphical User Interfaces?
The kinetics of the artificial objects are dictated by the calmness and attention of the user. We used Neurosky Mindwave Mobile to obtain Alpha brain wave values of the user. The flowers would behave erratically when the user is not mentally focused. But, when they are focusing, the flowers would relax, representing a state of tranquility. The mechanism is simple. The case on which the flowers are mounted consists of micro servos. The servos pull the invisible string to close the shape of the flower and release to relax the shape. The angle of rotation which generated the pull is directly proportional to the user's focus and attention. These values came from the Neurosky headset the user wore, as shown in the video above. ![](/images/projects/cognitive-flowers/img-1.jpg) --- ### Ontogenesis *Creative Code · May, 2015* Exploration of relationship between form and growth through the lens of art and code.
Ontogenesis is a study of cellular spatial structures organized as spheres. The project describes the framework of relationships between different cells rather than the study of their specific nature. The simulation itself is based on very few formulas of interaction and relation, which emulate the complexity of nature. It is a way of understanding the nature of the growth algorithm and its limits. The math behind this simulation was inspired by Andy Lomas' work. This project aims to model a hypothetical situation on a computer so that it can be studied to better understand how the real system works. By changing variables of the simulation, predictions may be made about the behavior of the actual system. ![](/images/projects/ontogenesis/img-1.jpg) The final simulation was created in C++ and OpenFrameworks library. The math was too intensive for a CPU; any future iteration would need to run on a GPU. Archived Code: https://github.com/jaskiratr/ofxMorphogenesis --- ### Jamming Bodies 1.0 *Visiting Researcher · Dec, 2015* An immersive installation that transforms the room into a pulsating laboratory, which can be tuned for stiffness, reconfigured on demand. Collaboration with Self-Assembly Lab, MIT + Lucy McRae + Storefront Gallery for Art & Architecture **Team:** Skylar Tibbits, Jared Laucks, Jaskirat Randhawa, Athina Papadopoulou, Dimitris Mairopoulos, Lina Kara'in, Christophe Guberan, Sulaiman Alothman, Kate Weishaar JB1.0: Jamming Bodies is an immersive installation that transforms Storefront's gallery space into a laboratory. It collapses architecture, technology, and art into a single object. While skin usually demarcates the transition between exterior and interior, this experimental installation transforms skin into a membrane that operates as both.
As the walls deflate, they become hard. Inflate them, and they are soft. The result over time is a pulsating room that can be tuned for stiffness, reconfigured on demand and which confuses the distinction between our skin and our walls. ![](/images/projects/jamming-bodies/img-1.jpg) **Press:** - [Wired UK : Jamming Bodies: This Robotic Wall Will Eat You Alive](https://www.wired.co.uk/article/lucy-mcrae-skylar-tibbits-jb10-jamming-bodies-film) - [Art Rabbit: JB1.0: Jamming Bodies](https://www.artrabbit.com/events/jb-jamming-bodies) - [London Architecture Diary](http://architecturediary.org/london/events/5597) - [MIT Architecture Press](https://architecture.mit.edu/architecture-and-urbanism/news/skylar-tibbits-and-lucy-mcrae-collaboration-jb10-jamming-bodies-opens) --- ### Wearshops *Co-teacher · Apr, 2016* Workshop for finding creative garment applications through shape changing fabrics. The "Shape Changing Materials" workshop brought together smart materials, computational design, and digital fabrication in the context of garments and wearables. Over three days, participants explored interactive wearables and alternative uses for smart materials. The participants experimented with responsive shape-shifting materials through 3D modeling and computation-based approaches using Rhinoceros and Grasshopper.
Along with hands-on prototyping, we provided starter code so participants and guests could simulate the materials digitally. Everyone left with prototypes of shape-changing materials and a sense of how they behave as garments, and used user-centered methods to find use cases for interactive garments. ![](/images/projects/wearshops/img-1.jpg) ![](/images/projects/wearshops/img-2.jpg) **Instructors:** Efilena Baseta, Grace Jun, Jaskirat Randhawa **Participants:** Attie Chan, Autumn Kietponglert, Boris Yu, Fulya Turkmenoglu, Harmony Pilobello, Ivor Ip, Jordan Frand, Mia Baldonado, Pablo Criado-Pérez, Ran Tian, Renata Gaui, Savani Mirashi, Suma Balaram, Terricka Johnson, Xiang Liu **Publication:** [Shape Changing Materials: Exploring Applications of Smart Memory Alloy with Fabric and 3D Visualizations.](https://www.researchgate.net/publication/301693041_Shape_Changing_Materials_Exploring_Applications_of_Smart_Memory_Alloy_with_Fabric_and_3D_Visualizations) --- ### Technkisi *Visiting Artist · Nov, 2014* Interactive kinetic sculpture created at Media Lab at Metropolitan Museum of Art. ![](/images/projects/technkisi/img-1.jpg) Technkisi is inspired by Kongo Power Figures from the 19th century. It re-imagines the rituals performed around the figurines from Central West Africa through a modern technological lens. Some of the original figurines are exhibited in the collection of Department of the Arts of Africa, Oceania, and the Americas at The Metropolitan Museum of Art.
The user communicates with the sculpture through their own brainwaves via a wireless BCI (Brain Computer Interface). The sculpture listens, interprets and absorbs the concerns of the user. It changes its physical form to respond to the user's state of mind. It then inherits the user's negativity and cries out machine oil, relieving the user of the burden. The goal was to develop an immersive and interactive experience to realize technology as a conscious entity. When the ritual is initialized, the sculpture begins to move. The user sitting in front of the sculpture quietly focuses on their thoughts and mentally addresses a concern to it. Once enough focus is established, the sculpture lights up and forms a human face, signalling that it is in sync with the user and has their undivided attention. The user then meditates to release the concern for the sculpture to inherit. After a while the sculpture cries oil, a sign of empathy with the user. ![](/images/projects/technkisi/img-2.jpg) The kinetic sculpture was designed by 3D scanning the original artifact and was modified into a low polygon model. The model was split into multiple 3D printed layers each of which can individually move in its own orthogonal plane. The whole assembly sits in a basin of oil. Support and guidance provided by: - Don Undeen - Senior Manager, MET MediaLab - Yaëlle Biro - Associate Curator for Arts of Africa > "Whenever I showed MediaLab guests around our space, this project was one of my favorites to explain. It exemplifies the spirit of the MediaLab because it takes a deep look at the Met's collection and uniquely uses technology to provoke conversation about what it means to be a museum in the twenty-first century. > How do we connect visitors from very different cultures to the original purpose of these objects? Technkisi is one approach to that question that I hope will inspire us to take a closer look at our relationship with ritual objects in museums." > > Don Undeen, Former Senior Manager of MediaLab **Publication:** [MET Digital Underground: Technkisi: A Spiritual Connection with Technology](https://www.metmuseum.org/blogs/digital-underground/2015/technkisi#) **Exhibition:** [Media Lab Expo: Arts, Robots and Chocolates](https://www.metmuseum.org/blogs/digital-underground/2015/the-medialab-fall-2014-expo) --- ### Terra *Design & Technology · Dec, 2015* Autonomous photogrammetry with drones to inspect high-voltage power transmission towers. ![](/images/projects/terra/img-2.png) **Team:** [Jaskirat Randhawa](http://jaskirat.org), [Grace Jun](http://gracejun.com/), Charles Saidel Terra is a terrain mapping service that uses drones to 3D scan for constructing and inspecting power lines. With PowerGrid India as the example client, we focused on a service for engineers who build and maintain transmission lines. > ### Helicopters can collect line data for about 125 miles a day, at roughly $300 per mile. Our user interviews put the daily cost of helicopter inspection at around $37,500. For a fraction of that, a drone can inspect within a 5-mile radius per flight.
It is useful in two scenarios. First, scouting and assessment: it can scan terrain before construction faster than a conventional aerial survey. Second, inspecting existing lines: detecting conductor sag, checking conductor health and ground clearances against standards, and spotting visual defects in towers and hardware. ![](/images/projects/terra/img-1.jpg) --- ### Quartz *Technical Lead · Oct, 2015* A modified Computer Numerical Control (CNC) router for fused deposition modelling using quartz glass. Quartz is a material research project that pairs computer-aided rapid prototyping with silica glass, a material humans have worked for millennia. Using open source CNC hardware and software, the extrusion process forms two- and three-dimensional glass artifacts that keep the material's toughness, optical quality, and thermal stability. **Team:** [Daniel Sauter](http://danielsauter.com/), [Jaskirat Randhawa](http://jaskirat.org) **Website**: [jaskiratr.github.io/quartz/](https://jaskiratr.github.io/quartz/) ![](/images/projects/quartz/img-1.gif) ![](/images/projects/quartz/img-2.jpg) The photo on the top shows the modified CNC Machine in its current stage. It can extrude simple geometries with consistent thickness and high fidelity based on a CAD drawing. The project documentation is available [here](https://jaskiratr.github.io/quartz/). **Related Links:** - [How-to-build guide](https://jaskiratr.github.io/quartz/) - [Experiment videos](https://vimeo.com/album/4021301) --- ### Programmable Carbon Fiber *Visiting Researcher · Jun, 2015* Large-scale Programmable Carbon Fiber produced on a 4'x2' multi-material FDM. **Team:** Skylar Tibbits, Athina Papadopoulou, Sulaiman Alothman, Jaskirat Randhawa, Dimitris Mairopoulos This project explores large-scale Programmable Carbon Fiber produced on a 4'x2' multi-material FDM. After printing, the carbon fiber is light-activated to trigger reversible shape transformation from a flat sheet to a spiral structure. The Programmable Carbon Fiber technology has been developed in collaboration with Carbitex as an extension of their existing fully-cured flexible carbon fiber technology, CX6.
The large-format multi-material FDM was custom developed with Shopbot as a modular and easily customizable printer for large-format 2D and 3D printed structures. ![](/images/projects/programmable-carbon-fiber/img-2.png) Exhibited at the BSA Space, Boston MA June 2015: [Bigger than a Breadbox, Smaller than a Building](https://www.architects.org/bsaspace/exhibitions/bigger-breadbox-smaller-building) --- ### Stickie *MFA Design & Technology Thesis · May, 2016* Thesis research on interactive design for real-time mobile collaboration, using smartphones and large screen displays.
Stickie is a mobile collaborative system. The project uses physical space as a medium for people to digitally annotate their environment. Stickie incorporates the smartphone as an extension of the human body to spatially interact with visual content. It folds the user experience of digital smartphones and monitor screens into one analog note making process, which allows people to physically post multimedia content from phones onto multiple surfaces. The web application lets people run sticky-note sessions remotely, using two devices every workplace already has: smartphones and TV screens.
A personal smartphone acts as the interface between tangible and digital space. Users leave notes on a TV screen by placing the phone itself against any ordinary non-touch display. Because it runs on commodity hardware, it works in most workspace setups without special equipment, and the code is open source. ![](/images/projects/stickie/img-1.gif) **Presented at:** - Parsons Thesis Exhibition, MFA DT Thesis Show 2016, New York - Verizon Connected Futures 2015-16, New York - NYC Media Lab Annual Summit 2016, New York - Spatial User Interfaces 2016, Tokyo - User Interface Software Technology Symposium 2016, Tokyo --- ## Notes & Mentions **Patents** - Systems and Methods for Recommending Linear TV Content. US 10986408 · Issued Apr 20, 2021 - System and Method of Retrieving and Conveying Sensitive Information When Using Voice Command Devices. US 10733278 · Issued Aug 4, 2020 - Methods and Systems for Virtualizing a Target Object Within a Mixed Reality Presentation. US 10380803 · Issued Aug 13, 2019 **Publications** - Co-authored "Visualizing Urban Social-Ecological-Technological Systems" in Resilient Urban Futures, 2021 - "Solving Problems with Puzzles" MISC Magazine, 2017 - "Shape Changing Materials: Exploring Applications of Smart Memory Alloy with Fabric and 3D Visualizations", Research Gate, 2016 - "Stickie: Mobile Device Supported Spatial Collaborations", ACM Digital Library, 2016 **Exhibitions & Talks** - Hosted Data-Visualization Workshop, Modelling Complex Urban Environments, WICI, Ontario, 2018 - Speaker at URExSRN Annual All Hands Meeting, Phoenix, 2018 - Speaker, Data-Visualization Seminar at "Resilient Cities, Livable Futures," The New School, New York, 2017 - Exhibited at ACM User Interface Software Technology Conference (UIST), Tokyo, 2016 - Exhibited at ACM Spatial User Interfaces Conference (SUI), Tokyo, 2016 - Exhibited at FabCafe/Loftwork for YouFab Awards, Tokyo, 2016 - Speaker at NYC Media Lab Annual Summit, New York, 2016 - Exhibited at Metropolitan Museum of Art, Media Lab Expo, New York, 2015 - Exhibited at Storefront Gallery for Art & Architecture, New York, 2015 **Awards** - Verizon Spotlight Award for performance excellence, 2019 - Three Verizon Patent Awards, 2018-2022 - Finalist, YouFab Global Creative Awards, Tokyo, 2016 - Verizon Connected Futures Grant, 2015-16 - Departmental Honors, AMT, Parsons School of Design, 2016 - The New Challenge Award for social innovation, The New School, 2016 - NYC Media Lab Combine Grant, 2015 - Dean's Merit Scholarship for MFA in Design & Technology, The New School, 2014 ## Links - [LinkedIn](https://www.linkedin.com/in/jaskiratr/) - [GitHub](https://github.com/jaskiratr) - [RSS](https://jaskirat.org/rss.xml)