Tan LE

How we moved a React single-page app hosted on Azure Static Web Apps onto a custom domain managed in Cloudflare, without exposing an unfinished site, and what else had to change behind the scenes: CORS, transactional email, and Stripe redirects. Background Our product is a SaaS tool for domain-name research. The frontend is a React app deployed to Azure Static Web Apps through GitHub Actions. The backend is an ASP.NET Core API on Azure App Service . Until recently the frontend lived on the default *.azurestaticapps.net hostname that Azure hands out. The business made two decisions at once: the public domain would be a .ai domain already sitting in a Cloudflare account, and the brand would change to match it. So the job was part DNS, part configuration, and part find-and-replace. What "moving the site" actually touches Pointing DNS at the new host is the easy part. The frontend origin is baked into several other places, and if any of them is missed the app br...

How I ported a ticket-inventory monitoring workflow to Python, solved a proof-of-work bot challenge in pure code, pushed the heavy lifting into SQL Server, and shipped a tool that alerts the team on Slack within seconds of a new listing appearing. The problem In the secondary ticket market, timing is everything. A well-priced listing for a high-demand show can appear and disappear in under a minute. Our purchasing team needed to know, immediately, when a new listing showed up for the events they were tracking on GoTickets, filtered by price ceiling and section, and with a one-click link to buy. We already had this workflow for another marketplace, running inside a larger C#/.NET application. But that app was heavy, tightly coupled to a desktop environment, and hard to deploy on a fresh machine. For GoTickets, I wanted something different: a small, dependency-light Python service that anyone on the team could stand up in ten minutes and leave running unattended. That projec...

I needed to process DNS zone files for about 1,000 top-level domains, load ~280 million domain names into SQL, and do it on a schedule without paying for a server that sits idle 95% of the time. This is how I set it up, what the stack looks like, and the mistakes I made along the way. The problem ICANN's Centralized Zone Data Service (CZDS) gives approved users a daily snapshot of every gTLD zone file: .biz , .info , .xyz , all the way to .com . Each file lists every registered domain in that TLD. I wanted to turn those into one table: label -> number of TLDs it is registered in , so that for a keyword like cloudapp we can show "registered in 37 TLDs". Requirements: Run once a week for now, nightly later. Big memory for the largest zones, so a real VM, not a serverless function. Cost close to zero when not running. No one logging in to press Start. The stack Layer Choice Why Worker .NET 8 console app, published self-contained for linux-x64 Str...

How a "should we just move this to SQL?" question turned into a lesson about where cloud costs actually hide. It started with a Slack message about decommissioning a web app. "How much storage is that? Curious what the pros and cons are of storing in blob vs Azure SQL?" I thought I'd answer it in five minutes. I was wrong in three separate ways, and each one taught me something. Wrong #1: "Storage is basically free" My first answer was the one everyone gives: blob storage is ~$0.02/GB/month, the data is small, cost is a rounding error. Move it to SQL, kill the web app, save the hosting bill. Then I actually looked at the write rate: ~100,000 blobs per day , one per availability check, around 20 KB each, never deleted. That changes everything: 2 GB/day → ~60 GB/month → ~730 GB/year, growing forever. Blob storage also charges per write transaction . 3 million writes/month is another $15–20, every month, regardless of retention. After one y...

Every week, part of my ticket-operations workflow involved the same manual routine: open the StubHub inventory site, apply the same filters, and work down a research spreadsheet of performers one by one — searching each name, adding what qualified, and noting the ones with no events. It's exactly the kind of task that is too UI-bound for an API integration but too repetitive to keep doing by hand. So I automated it with Power Automate Desktop , Microsoft's desktop RPA tool. This post walks through how the flow works and the design decisions that made it reliable enough to run unattended, week after week. What the flow does The flow runs on a weekly cycle, and its first job is to know where it is in that cycle: Weekly reset. On start, it gets the current date and time in Pacific time and checks the day of week. If it's Sunday at 6:00 AM or later, the week is over: it resets the state file ( CompletedSpecPerformerList.txt ) and stops. Every other run continues the ...

Before my current automation work, I spent about a year as a freelancer building a market-intelligence and purchasing-workflow platform for a US ticket-brokerage client. The secondary ticket market moves fast: events go on sale at a fixed minute, prices and seat availability shift constantly across a dozen marketplaces, and the brokers who win are the ones who see changes first. My job was to give a small operations team that visibility — and to automate as much of the surrounding workflow as possible. This post is a technical retrospective of that system: what it did, how it was architected, and what I learned running data pipelines across two clouds. What the platform did At its core, the system ran four loops for the operations team: Primary-market ingest. Scheduled jobs pulled upcoming events from Ticketmaster's APIs — by state, by venue, by on-sale date — into a local SQL Server database, so the team planned their week from one screen instead of a dozen browser tabs...