[{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/ai-coding/","section":"Tags","summary":"","title":"Ai-Coding","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/aws/","section":"Tags","summary":"","title":"Aws","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":" Building Trail Spark: How AI and Serverless Built a Resilient EV Road Trip App # Every great EV road trip is a journey of discovery. Last November, my wife, our golden doodle Korra, and I drove our Rivian R1S from North Bend, Washington to Denver, Colorado. 3,000 miles. Three mountain passes. Zero gas. I took 225 photos and thought: I should build something to show this trip the way it felt, not the way Instagram would flatten it.\nThat impulse turned into Trail Spark—my hobby platform dedicated to EV road trip documentation and sharing. But there was a catch: I do not code full-time at work anymore, and between professional and family life, I hardly have any time to sit down and write code at home. Furthermore, since I work at AWS, building this on AWS serverless tech was very much a case of eating my own dogfood.\nIn this first post of my engineering blog, I want to talk about how I built a highly resilient, secure, and production-ready serverless system on AWS—and how the entire project was made possible through a partnership with AI coding assistants.\n🤖 The Engine: How AI Made a Hobby Project Possible # In the past, building a full-stack web application as a side project was a daunting multi-month commitment. You had to set up the boilerplate, configure routing, write custom image metadata parsers, manage IAM roles, design database schemas, configure CORS, write test suites, and troubleshoot CDN deployment issues. For a hobbyist with only a few spare hours a week, projects usually died in the bootstrap phase.\nTrail Spark exists today because I partnered with AI:\nCursor allowed me to iterate quickly on the frontend React components and prototype pages. Claude Code acted as a CLI co-pilot, orchestrating infrastructure setups, preparing deployments, and running backend tests. Antigravity helped me deep-dive into complex debugging loops—like tracing why CloudFront was throwing WAF 403 blocks, calculating rolling 5-minute IP rate limits, and implementing in-place WebACL updates. By delegating the boilerplate, configuration syntax, and debugging loops to AI, I could focus entirely on system design and product flow. Instead of writing code, my role shifted to that of an architect: defining goals, reviewing plans, and making high-level architectural decisions.\n📋 The Blueprint: Product Specifications \u0026amp; Claude\u0026rsquo;s Role # Before writing any architecture or code, establishing clear boundaries for the MVP was critical. I used Claude to draft and refine the Product Requirements Document (PRD) for Trail Spark, defining a phased roadmap focused on core features: a chronological, location-aware road trip timeline sorted automatically by time and location (with a media lightbox, narrative description editing, and coordinates linking to Google Maps), public read-only trip URLs for easy sharing, secure DynamoDB persistence, and an AWS SAM serverless backend with CloudFront/S3 hosting.\n🏗️ Architectural Decisions: Why Serverless and SAM? # For a hobby project, operation and maintenance overhead must be near zero. I don\u0026rsquo;t want to wake up to a crashed server, manage container patches, or pay for idle virtual machines.\nThis constraint drove my core architectural decisions:\n1. The Monolithic Server: One to Rule Them All # Instead of splitting the app into multiple microservices, the backend is a single monolithic Express server (~2,300 lines of code) that handles auth, trips, timelines, blog posts, image uploads, engagement, and admin invite codes.\nThe Reason: When building alone, the cost of microservices is the overhead of multiple deployment pipelines, service discovery, and complex distributed tracing. Keeping it monolithic means everything shares the same client instances, middleware configurations, and error handlers. The Serverless Bridge: The Express app exports cleanly for Lambda using @vendia/serverless-express—a thin adapter translating API Gateway HTTP events into standard Express requests. The production handler is only 6 lines, and the exact same codebase runs locally via node server.js for seamless development. 2. S3 + CloudFront with Origin Access Control (OAC) # The frontend is a React SPA hosted in an S3 bucket. However, the bucket is completely blocked from public access. Instead, traffic must go through CloudFront.\nThe Reason: CloudFront acts as a global CDN, caching assets at edge locations close to users for fast load times. By enforcing Origin Access Control (OAC), I ensure that S3 content is only accessible via signed CloudFront requests, preventing direct S3 access and protecting against data scraping and unexpected S3 download bandwidth bills. 3. DynamoDB Single-Table Design # Instead of setting up a relational SQL database that requires connection pooling, server provisioning, and maintenance, I designed a single DynamoDB table. All entities—users, trips, milestones, charging data, and blog posts—coexist in the same table, indexed using composite primary keys:\nUSER#\u0026lt;userId\u0026gt; + SK: PROFILE → user profile (bio, vehicle) USER#\u0026lt;userId\u0026gt; + SK: POST#\u0026lt;tripId\u0026gt; → trip summary \u0026amp; metadata POST#\u0026lt;tripId\u0026gt; + SK: META → detailed trip timeline config POST#\u0026lt;tripId\u0026gt; + SK: MS#\u0026lt;order\u0026gt;#\u0026lt;id\u0026gt; → specific timeline milestone POST#\u0026lt;tripId\u0026gt; + SK: IMG#\u0026lt;id\u0026gt;#\u0026lt;index\u0026gt; → image mapped to a milestone POST#\u0026lt;tripId\u0026gt; + SK: CHARGE#\u0026lt;order\u0026gt;#\u0026lt;id\u0026gt;→ charging log record USER#\u0026lt;userId\u0026gt; + SK: BOOKMARK#\u0026lt;id\u0026gt; → user saved post reference The Reason: DynamoDB has zero maintenance overhead, scales instantly, and costs nothing when there is no traffic (fitting entirely in the free tier). Single-Table design allows me to fetch a complete road trip—metadata, stops, images, and charging data—in a single Query operation on PK = POST#\u0026lt;tripId\u0026gt;, avoiding database joins and multiple round-trips. 💥 Lessons from the Edge: Tracing the Silent Failures # Building serverless systems on the AWS edge introduces unique integration challenges. Two debugging stories stand out:\n1. The WAF That Ate My Blog Posts # Initially, users could create trips, but writing blog posts containing HTML in the rich-text editor (TipTap) triggered a \u0026quot;Network error: Unexpected token '\u0026lt;'\u0026quot; and crashed the React app.\nHere is the chain of events I had to trace:\nThe rich text editor sends request bodies containing HTML: { body: \u0026quot;\u0026lt;p\u0026gt;My \u0026lt;strong\u0026gt;blog\u0026lt;/strong\u0026gt; post\u0026lt;/p\u0026gt;\u0026quot; } AWS WAF\u0026rsquo;s AWSManagedRulesCommonRuleSet flags the request via its CrossSiteScripting_BODY rule and blocks it with a 403 Forbidden. CloudFront\u0026rsquo;s custom error configuration converts the 403 response into a 200 OK serving the React SPA\u0026rsquo;s index.html (standard for client-side routing fallback). The React frontend parses the HTML page where it expects a JSON response, leading to the crashing syntax error. The Fix: I updated deploy.sh to configure WAF in-place and exclude the CrossSiteScripting_BODY rule from the managed rule group, since our blog editor is supposed to accept HTML. I also adjusted CloudFront to only apply SPA redirects to 404s, letting 403 errors surface properly to the API layer. 2. Native Binaries on Lambda: The Sharp Dilemma # To generate high-performance image timelines, the backend converts iPhone HEIC files to JPEGs and resizes thumbnails via sharp.\nThe problem: sharp relies on a native library (libvips). The binary compiled on my local macOS environment fails on Lambda\u0026rsquo;s Graviton2 ARM64 Amazon Linux runtime. The Fix: I wrote a lazy-loading mechanism. When the server boots, it runs a native dependency check. If sharp fails to load (e.g. during a mismatched local runtime test), the app falls back to writing the raw image buffer. The uploads still succeed, ensuring the application remains robust. 🛡️ The Billing Breaker: Andon Cord \u0026amp; Budget Kill-Switch # For a personal hobby project, a primary concern was AWS budget overruns. A sudden surge in traffic—or a malicious DDoS attack—could scale a serverless application instantly, potentially racking up thousands of dollars in usage bills.\nTo prevent this, I implemented two defensive layers:\n1. Multi-Tier Rate Limiting \u0026amp; Scope-Downs # I configured WAF edge limits to block automated scrapers. However, a timeline with 225 photos loads them in parallel, which instantly tripped our strict edge limit of 100 requests per 5 minutes.\nTo fix this without compromising protection, I added a WAF Scope-Down Statement using the base64-encoded representation of /img/ (L2ltZy8=):\nExcluded the /img/* prefix from the strict RateLimit100Per5Min API rule. Created a separate RateLimit2000ImgPer5Min rule targeting only /img/* to allow media loads while keeping defenses against DDoS flood attacks. 2. The Andon Cord # Taking inspiration from Toyota\u0026rsquo;s manufacturing line, I built an automated Andon Cord.\nIf AWS Budgets detects that my $10/month cap is breached, or if CloudWatch registers a DDoS-like invocation surge, an SNS alert triggers the Kill Switch Lambda. This Lambda instantly overrides the reserved concurrency of my Express API Lambda to 0:\naws lambda put-function-concurrency \\ --function-name trail-spark-api-prod \\ --reserved-concurrent-executions 0 This acts as a physical breaker, taking the API offline instantly to prevent billing overruns. I also built a CLI tool (./andon-cord.sh) to check status:\n./andon-cord.sh status # State: ONLINE (unrestricted) # Concurrency: Account Limit (default) 📈 Observability \u0026amp; Monitoring: An Engineering Manager\u0026rsquo;s Approach # As an engineer and engineering manager, I know first-hand that you cannot manage what you do not measure. Observability and monitoring are not optional add-ons; they are core architectural requirements. For a self-hosted hobby project on AWS, we need minimal operational overhead, budget safety, and fast troubleshooting.\nI structured our observability stack into four key pillars:\nUnified Dashboard (TrailSpark-BotTraffic): A 30-panel CloudWatch Dashboard tracking client traffic (CloudFront edge latency and cache hit ratios), compute health (API Gateway times, Lambda execution percentiles and error rates), data persistence (DynamoDB read/write capacity and latency), and security (WAF total, blocked, allowed, and bot traffic). Operational Alarms: Automated CloudWatch Alarms notifying me via an SNS Alerts Topic for elevated Lambda errors (trail-spark-lambda-errors), near-concurrency limits (trail-spark-lambda-throttles), API Gateway 5xx faults (trail-spark-api-5xx), and DynamoDB read/write throttling (trail-spark-dynamo-throttle). Automated Resilience (The Andon Cord): If CloudWatch registers a DDoS-like traffic surge—such as Lambda invocations exceeding 500/min or DynamoDB read/write capacity spiking—or if AWS Budgets detects our $10/month cap is breached, an SNS alert automatically triggers our Kill-Switch Lambda. This Lambda overrides the Express API\u0026rsquo;s reserved concurrency to 0, acting as a physical circuit breaker to take the API offline instantly and prevent runway billing. Logging \u0026amp; Privacy Auditing: We stream WAF logs continuously to CloudWatch Logs (aws-waf-logs-trail-spark-prod) with a 30-day retention policy to facilitate rate-limit tuning, and track AWS Rekognition metrics to monitor the dynamic license plate blurring pipeline during media uploads. 🧪 Validating the System: Gameday Testing # Because AI built these resilience systems, I needed a way to prove they work under real-world stress. I created a test script called gameday.sh that simulates live attacks and budget breaches directly against the production environment.\nThe gameday suite runs 12 automated scenarios, including publishing mock budget alerts, simulating DDoS spikes to trigger the Andon Cord, and launching concurrent request bursts to test WAF rate limiting. Running the suite verifies that all circuit breakers trip, notify, and recover successfully—giving me peace of mind that my pocketbook is safe.\n🚀 What\u0026rsquo;s Next? # With the backend secured and the infrastructure automated, I am currently focusing on:\nDynamic License Plate Blurring: Using AWS Rekognition to detect license plates in uploaded trip images and processing them dynamically using Sharp to preserve privacy. SPA Optimization: Migrating my frontend React app from Create React App to Vite to streamline local development and build times. Beta Sharing: Inviting other Rivian and EV road-trippers to start mapping and documenting their adventures. Stay tuned for my next post, where I will dive deep into the math behind spatial milestone grouping using EXIF geo-coordinates!\nI am a developer in Seattle who builds things for the EV community. I drive a Rivian R1S, travel with my golden doodle Korra, and have strong opinions about charging station coffee.\n","date":"May 25, 2026","externalUrl":null,"permalink":"/blog/building-trailspark/","section":"Blog","summary":"","title":"Building Trail Spark: How AI and Serverless Built a Resilient EV Road Trip App","type":"blog"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/cloudfront/","section":"Tags","summary":"","title":"Cloudfront","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/dynamodb/","section":"Tags","summary":"","title":"Dynamodb","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/","section":"Home","summary":"","title":"Home","type":"page"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/lambda/","section":"Tags","summary":"","title":"Lambda","type":"tags"},{"content":"I build IAM features at AWS used by millions of customers. I also write about things I\u0026rsquo;m passionate about: technology, electric vehicles, and longevity.\n","date":"May 25, 2026","externalUrl":null,"permalink":"/authors/punit-deotale/","section":"Authors","summary":"","title":"Punit Deotale","type":"authors"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/serverless/","section":"Tags","summary":"","title":"Serverless","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/side-project/","section":"Tags","summary":"","title":"Side-Project","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/categories/technology/","section":"Topics","summary":"","title":"Technology","type":"categories"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/categories/","section":"Topics","summary":"","title":"Topics","type":"categories"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/trailspark/","section":"Tags","summary":"","title":"Trailspark","type":"tags"},{"content":"","date":"May 25, 2026","externalUrl":null,"permalink":"/tags/waf/","section":"Tags","summary":"","title":"Waf","type":"tags"},{"content":"","date":"April 4, 2026","externalUrl":null,"permalink":"/categories/my-work/","section":"Topics","summary":"","title":"My Work","type":"categories"},{"content":"","date":"April 4, 2026","externalUrl":null,"permalink":"/tags/personal/","section":"Tags","summary":"","title":"Personal","type":"tags"},{"content":"I\u0026rsquo;ve always felt like I have a lot to say. Like there are all these opinions and thoughts bouncing around in my head that need to go somewhere. I think about a lot of things, probably too many things, and I follow a lot of passions, sometimes all at once. For years I\u0026rsquo;ve wanted to channel all of that through some kind of medium, and writing always felt like the right one.\nBut here\u0026rsquo;s what held me back. I don\u0026rsquo;t want to be another generic voice on the internet! There are a million blogs out there that all sound the same, saying the same things the same way. That\u0026rsquo;s not what this is. This is me thinking out loud about the stuff I actually care about, in my actual voice, with my actual opinions. If that resonates with you, amazing. If not, that\u0026rsquo;s cool too!\nSo what do I actually care about? A lot!!\nLiving life, and living longer. I\u0026rsquo;m fascinated by longevity science, metabolic health, the idea that we can extend not just how long we live but how well we live. I read everything I can get my hands on about this.\nTechnology and the future. I\u0026rsquo;m an eternal optimist about what tech can do for humanity. AI, clean energy, biotech. I think we\u0026rsquo;re living through one of the most transformative periods in human history and most people don\u0026rsquo;t even realize it!\nCars, especially EVs. I\u0026rsquo;m a car guy who went fully electric. Two Rivians in the driveway, 87,000 electric miles and counting, 31 tons of carbon kept out of the sky. I have a lot of thoughts about the EV transition and I\u0026rsquo;ve lived it firsthand.\nThe outdoors. I\u0026rsquo;m an environmentalist at my core. We are part of nature, not separate from it, and the fact that we\u0026rsquo;re destroying the ecosystems we belong to keeps me up at night. But I\u0026rsquo;m also hopeful because the technology to fix this is here!\nMy job. I work on IAM at AWS and honestly, it consumes me, but I love it! I love the challenge of building identity systems at massive scale. I love helping customers. And I\u0026rsquo;m obsessed with UX and CX. I\u0026rsquo;m always thinking about how to simplify the interaction between humans and computers. If the system makes the right thing harder than the wrong thing, that\u0026rsquo;s a design failure. I think about that constantly, not just at work but everywhere.\nThat\u0026rsquo;s what this site is. All of those things, all at once, unapologetically. Some posts will be about carbon math and EV road trips. Some will be about IAM permissions and developer experience. Some will be about longevity research or a new piece of tech that blew my mind. The thread that connects all of it is me. A person who can\u0026rsquo;t stop thinking, can\u0026rsquo;t stop tinkering, and finally decided to start writing it all down.\nLet\u0026rsquo;s go!!\n","date":"April 4, 2026","externalUrl":null,"permalink":"/blog/why-i-started-writing/","section":"Blog","summary":"","title":"Why I Started Writing","type":"blog"},{"content":"","date":"April 4, 2026","externalUrl":null,"permalink":"/tags/writing/","section":"Tags","summary":"","title":"Writing","type":"tags"},{"content":"","date":"March 4, 2026","externalUrl":null,"permalink":"/tags/cloud-security/","section":"Tags","summary":"","title":"Cloud-Security","type":"tags"},{"content":"","date":"March 4, 2026","externalUrl":null,"permalink":"/tags/developer-experience/","section":"Tags","summary":"","title":"Developer-Experience","type":"tags"},{"content":"","date":"March 4, 2026","externalUrl":null,"permalink":"/tags/iam/","section":"Tags","summary":"","title":"Iam","type":"tags"},{"content":"Every developer I\u0026rsquo;ve talked to has the same story. They\u0026rsquo;re setting up something on AWS. An EC2 instance, a Lambda function, an ECS task. They get to the part where it asks for an IAM role. They don\u0026rsquo;t have one. So they open the IAM console in another tab, spend ten minutes trying to figure out what permissions they need, give up, paste a wildcard policy, and move on.\nI\u0026rsquo;ve been working on IAM at AWS for years. Leading teams, driving product and security decisions, shipping features that millions of developers use. And I think IAM is the single hardest part of cloud computing! Not because it\u0026rsquo;s broken. The underlying model is actually very good. But we built it for security engineers and then asked every developer to use it.\nThe context switch is the real problem # IAM roles connect everything in AWS. Lambda needs to read from S3? Role. EC2 needs to write to CloudWatch? Role. ECS task needs to pull secrets? Role. Nearly every meaningful setup involves one.\nBut creating a role has always meant leaving whatever you\u0026rsquo;re doing, opening the IAM console in a new tab, and navigating a completely different interface. You have to figure out trust policies, pick the right managed policies (or write your own JSON), scope it correctly. All while trying to remember what you were setting up in the first tab!\nBy the time you get back, you\u0026rsquo;ve lost your train of thought. And honestly? Most people just attach more permissions than they need so they don\u0026rsquo;t have to do this again. Can you blame them??\nFrankenstein roles # Here\u0026rsquo;s what happens over time. Developers stop creating new roles altogether! They find one that \u0026ldquo;works,\u0026rdquo; usually some admin role from a debugging session months ago, and reuse it. Then someone else attaches another policy to it for a different use case. Then another.\nEventually you have these roles that are stitched together from five different purposes, with permissions nobody fully understands. They\u0026rsquo;re everywhere, and they\u0026rsquo;re a real security problem. But they exist because creating a properly scoped role was too annoying. That\u0026rsquo;s on us!\nThe inconsistency makes it worse # The other thing that doesn\u0026rsquo;t get talked about enough. The IAM role experience is different depending on which AWS service you\u0026rsquo;re using! Some services give you decent managed policies to start with. Others hand you an empty JSON editor. Others suggest policies that are way broader than what you actually need.\nSo even if you\u0026rsquo;re willing to do the right thing, the guidance you get depends entirely on where you happen to be. That\u0026rsquo;s a design problem!\nWhat I think the fix looks like # I\u0026rsquo;ve been thinking about this for a long time, and I keep coming back to one idea. The easiest path should be the secure path. I call it developer-first security. Not \u0026ldquo;dumb it down.\u0026rdquo; IAM is complex for real reasons and security teams still need full control. But most developers aren\u0026rsquo;t security engineers, and the system shouldn\u0026rsquo;t require them to be!\nWhat that means in practice: give people smart defaults instead of blank slates! If I\u0026rsquo;m setting up a Lambda that reads from a DynamoDB table, the system should know enough about that context to suggest the right permissions. Not make me go research the IAM docs first. Make the feedback instant. When something is denied, tell me exactly what and why, don\u0026rsquo;t make me dig through CloudTrail. And stop letting unused permissions pile up forever!\nThis is starting to happen # AWS just announced that you can now create and customize IAM roles directly inside service workflows. No more tab-switching! You get a panel right where you are, with default policies and a simplified way to set permissions. It works across EC2, Lambda, EKS, ECS, Glue, CloudFormation, DMS, Systems Manager, Secrets Manager, RDS, and IoT Core, with more coming.\nThis is the right direction!! It tackles the context switch. It reduces the temptation to reuse bloated roles. And it gives you contextual guidance instead of a blank editor.\nBut we\u0026rsquo;re still not there # Here\u0026rsquo;s the thing though. AWS also gives you the ability to create default IAM roles when setting up services. If you\u0026rsquo;ve ever created a Lambda function, you\u0026rsquo;ve seen it. The console offers to create a default execution role for you. Sounds great, right?\nThe problem is what that default role actually gives you. The AWSLambdaBasicExecutionRole (the one Lambda creates by default) grants exactly three permissions: logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents. That\u0026rsquo;s it! Your Lambda can write CloudWatch logs and literally nothing else!\nNeed to read from S3? Add a policy. Need to query DynamoDB? Add a policy. Need to pull a secret from Secrets Manager? You guessed it. Add a policy! You\u0026rsquo;re right back to where you started, digging through IAM docs trying to figure out the right permission strings.\nSo the default role gets you past the initial setup screen, but the moment your function needs to actually do something useful, you\u0026rsquo;re back in permission-land! It\u0026rsquo;s better than a blank slate, sure. But as a developer, what I\u0026rsquo;d love to see is the system being smarter about context. Imagine connecting a Lambda to a DynamoDB table and having the console suggest the right scoped permissions for that specific table automatically. That would be the dream! We\u0026rsquo;re not there yet, but I think that\u0026rsquo;s where this needs to go.\nI\u0026rsquo;ll say this. Getting permissions right in context across that many different services, without breaking the security model, is hard. IAM roles behave differently depending on the service, and there are real tradeoffs between making things convenient and keeping them secure. I know from experience that those tradeoffs have consequences at scale, and I\u0026rsquo;m glad to see them being taken seriously!\nI work on IAM at AWS. Opinions are my own.\nI want to hear from you!! If you\u0026rsquo;re a developer or a security engineer and you have thoughts on IAM, what\u0026rsquo;s working, what\u0026rsquo;s broken, what makes you want to throw your laptop out the window, reach out! I take this stuff seriously and your feedback shapes how I think about these problems. Find me on LinkedIn.\n","date":"March 4, 2026","externalUrl":null,"permalink":"/blog/why-iam-is-the-hardest-part-of-cloud/","section":"Blog","summary":"","title":"Why IAM Is the Hardest Part of Cloud","type":"blog"},{"content":" I\u0026rsquo;m an environmentalist who is deeply troubled by how we are destroying our planet and the ecosystems we belong to. We are one with nature. We are part of it, not separate from it. And somewhere along the way our species moved so far away from our place on this incredible planet. That keeps me up at night!\nBut I\u0026rsquo;m also an eternally romantic, hopeful person. Especially around tech and humanity\u0026rsquo;s future! I love animals, I love science, I\u0026rsquo;m a huge sci-fi nerd, and I want to be on the cutting edge of whatever comes next. I can\u0026rsquo;t help it. I read about a breakthrough in mRNA vaccines or CRISPR gene editing or a new clean energy breakthrough and I think, man, we might actually figure this out!!\nThat combination, the grief for what we\u0026rsquo;re losing and the excitement for what we might build, is what drives everything I do. This site is where those worlds collide.\nBy day, I work on Identity and Access Management at AWS. I lead teams that build and ship IAM features used by millions of customers. Root access management, multi-factor authentication, credential lifecycle management. My role spans the full product lifecycle: researching customer pain points, making product decisions, driving technical architecture, and bridging the gap between product and engineering.\nWhat I believe # I believe technology should meet people where they are, not the other way around! Whether it\u0026rsquo;s a developer trying to set up IAM permissions, or someone trying to go electric for the first time, or a patient trying to understand their health data. If the system makes the right thing harder than the wrong thing, that\u0026rsquo;s a design failure, not a people failure!\nIn my work at AWS, I call this developer-first security: the easiest path should be the secure path. But the principle is bigger than IAM. It applies to everything. EVs should be easier to live with than gas cars. Health information should be accessible, not locked behind jargon. Technology should amplify human capability, not gatekeep it!\nI\u0026rsquo;m a big believer that the next few decades are going to be transformative for humanity. mRNA, CRISPR, AI, clean energy. We are living through an inflection point! I\u0026rsquo;m very hopeful for what\u0026rsquo;s ahead, and I want to be part of building it.\nWhat I write about # This site is where I think out loud. Not just about work, but about the things I\u0026rsquo;m genuinely curious about:\nTechnology \u0026amp; Side Projects — AI, cloud security, identity systems, developer experience, and the technical side of building side projects (like TrailSpark for EV road trips) Longevity and Health — the science of living longer and better, from metabolic health to cutting-edge research My Work — lessons from building identity infrastructure at AWS scale Browse by topic on the Topics page, or see everything on the Blog.\nBefore AWS # I worked at DISH on enterprise automation systems, where I earned a \u0026ldquo;Best in Class\u0026rdquo; award for contributions to their platform.\nGet in touch # LinkedIn Google Scholar GitHub ","externalUrl":null,"permalink":"/about/","section":"Home","summary":"","title":"About","type":"page"},{"content":"","externalUrl":null,"permalink":"/categories/electric-vehicles/","section":"Topics","summary":"","title":"Electric Vehicles","type":"categories"},{"content":"","externalUrl":null,"permalink":"/categories/longevity-and-health/","section":"Topics","summary":"","title":"Longevity and Health","type":"categories"},{"content":" Peer-reviewed research # Design of Problem Solving Environment for Automated System Integration Education P. Deotale, S.-J. Hsieh ASEE Annual Conference \u0026amp; Exposition, 2011 ASEE PEER\nUse of Games for Learning Automated System Integration P. Deotale, S.-J. Hsieh ASEE Annual Conference \u0026amp; Exposition, 2012 ASEE PEER\nDevelopment and Usability Evaluation of an E-learning Application Using Eye-tracking P. Deotale, S.-J. Hsieh ASEE Annual Conference \u0026amp; Exposition, 2012 ASEE PEER\nUsability Evaluation of a Problem Solving Environment for Automated System Integration Education Using Eye-tracking P. Deotale, S.-J. Hsieh ASEE Annual Conference \u0026amp; Exposition, 2012 ASEE PEER\nFor citation counts and related work, see my Google Scholar profile.\nIndustry publications \u0026amp; coverage # Coming soon.\n","externalUrl":null,"permalink":"/publications/","section":"Publications","summary":"","title":"Publications","type":"publications"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":" Talks # Check back soon — upcoming speaking engagements will be listed here.\nIf you organize meetups or conferences on cloud security, IAM, authentication, or developer experience and are looking for speakers, I\u0026rsquo;d love to talk. Reach out on LinkedIn.\n","externalUrl":null,"permalink":"/talks/","section":"Talks","summary":"","title":"Talks","type":"talks"}]