Production Node.js and PostgreSQL. AI agents and MCP servers.

"Random logouts" took four pull requests over three weeks, and every one of them shipped with a green test suite. The first cause was two actors rotating the same refresh token: the web app and a background request each thought it was the only one refreshing, so one of them always ended up holding a token the server had just retired. The second cause only showed up in production, where the app lives on two hosts with separate cookie jars: a redirect between them bounced the browser back and forth until the session looked invalid.

Each half was correct on its own, which is exactly why the unit tests passed. The fix that finally held was a composition test that runs the whole login, refresh and redirect flow across both hosts the way a real browser does. The lesson I took from it: test the seam, not the pieces, because the bug lives where two correct things meet.

A customer noticed that tasks on their board were "submitted" hours before anyone had been assigned to them. When I looked, about two-thirds of all submitted tasks had the same impossible order. Two defaults had combined: new organisations were created in UTC rather than their own timezone, and the board took an ISO timestamp and simply sliced the time off it to get a date. In India, that moves a late-evening submission to the previous day.

The fix was one small date module with one rule, "a due date is a calendar date, not an instant", and a conversion that always goes through the organisation's own timezone. Every screen and every reminder reads dates through that module now, so there is one place to be wrong instead of thirty. The historical rows were corrected by a data fix shipped inside the same migration, so the code and the data changed together and nobody had to run a script by hand.

Recurring work in TaskTap ("payroll on the 1st", "standup every weekday at 9:30") is created by BullMQ repeat jobs. When an organisation changed its timezone, the schedule was re-registered with the new time, but the old repeat kept running too, because a repeat job's key cannot be addressed once it is created. For weeks that organisation got each recurring task twice a day, a few hours apart.

Two changes fixed it for good. The scheduler is now keyed by the recurring template's id, so there can only ever be one live schedule per template. And at boot, the worker reconciles what the queue thinks is scheduled against what the database says should exist, removing anything the database no longer knows about. The same review caught a cousin bug: a reminder re-enqueued after a restart could be delivered, and charged for, twice. Reminders are now only rescheduled when the task is more than a day away, so a restart can never double-send.

TaskTap bills per seat, and a team's seat count changes all the time. With a card subscription, Razorpay lets you update the amount in place. With a UPI Autopay mandate, it does not: the mandate is fixed at the amount the customer approved, so the only way to change seats is to create a replacement subscription and retire the old one at the right moment. The billing code had assumed every subscription could be edited the same way, which worked for every test customer and failed for the first real one on UPI.

The billing flow now branches on the payment method, and the awkward UPI case is handled with a replacement subscription that starts exactly when the old one ends. Prorated top-ups for seats added mid-cycle are keyed on the payment id, so a retried webhook or a double tap can never charge twice. Payments that fail halfway are the unglamorous part of a SaaS, and the part I most want to get right.

WhatsApp reminders are the feature customers notice first, and one morning every single one failed. The templates had been registered with the language code "en", and the code was sending "en_US". WhatsApp treats the template name plus language as a contract, so a mismatch is simply a message that does not exist. Nothing crashed; the queue just drained into errors.

The fix was a one-line change and a lot of hardening around it. The template language now comes from one place and is checked when the worker starts. The kill switch that turns WhatsApp sending off accepts "False", "off" and "no" with a trailing space, because those are the values that actually appear in config files written by hand at 11 PM. And alerts about the WhatsApp worker go out by email, not over WhatsApp, so the alert path never depends on the thing it is alerting about.

For a while TaskTap had tests and a deploy pipeline, and nothing connecting the two. A deploy would go out on a push, and whether the tests had been run depended on whether I remembered to run them. As the only engineer I always meant to. The honest fix was to make the machine remember.

CI now brings up a throwaway Postgres and Redis for every run, applies the migrations from scratch, and runs the backend suite against them. A schema-drift check compares the Prisma schema with the migrations, so a model change without a migration fails the build instead of failing in production. The deploy job depends on the checks job, which taught me a GitHub Actions lesson the hard way: a job name with a hyphen inside an expression parses as subtraction, so the dependency silently never applied until the name changed. Now a bad deploy is blocked by a red test, not noticed by a customer.