Senior Backend Developer (Node, TypeScript, Postgres) - Ongoing, 4 Production B2B Apps

Four production codebases, five people. One full-stack dev, one front-end dev, one QA engineer, one DevOps engineer, and me. The gap is a backend specialist who owns schema and API work end to end. The architecture is decided and documented. I run a product studio in Los Angeles. My background is senior technical program management and analytics for Amazon, Google, Stripe, PayPal, and Nordstrom. Our clients hold us to that standard, and I hold the team to it. The team is small, the bar is not. You would not work all four codebases at once. Most weeks are one, sometimes two. HOW WE WORK, AND THE ONLY THING I CARE ABOUT MORE THAN YOUR STACK We use AI coding agents heavily. I use Claude Code every day and I expect you to. But there is a difference between steering an agent and slinging prompts at one, and that difference is what I am hiring for. If your process is prompt, run it, paste the error back, repeat until it compiles, you are letting the model make the architecture decisions. I can do that myself. Here is the process we actually run, on every non-trivial task: 1. Research. Deep-read the relevant part of the codebase and write the findings into a research.md. Not a chat summary. A file I can read and correct before anything else happens. 2. Plan. A plan.md with the approach, code snippets, file paths, and trade-offs. No code yet. 3. Annotate. I open the plan in my editor and write inline notes. Corrections, rejected approaches, constraints, domain knowledge the model does not have. You address the notes and update the document. This cycles two to six times. 4. Todo list. A granular task breakdown added to the plan. 5. Implement. Only now. The plan is the source of truth, tasks get marked complete as they go, typecheck runs continuously. The point is that by the time code gets written, every decision has already been made by a human. Implementation should be boring. The thinking happened in the annotation cycle. Boris Tane wrote this up better than I can, and his post describes almost exactly how we work: https://boristane.com/blog/how-i-use-claude-code/ If that reads like unnecessary ceremony, we are not a fit. If it reads like a description of your own workflow, keep going. THE OTHER HALF OF THAT Do not read the plan-first process as me handing you requirements. It is the opposite. You do the research, you propose the approach, you make the calls. I annotate the places where you are wrong about something only I could know, a business rule or a product decision. The rest is yours. We are a small studio, not an enterprise. There is no business analyst writing you a spec. There is no requirements document waiting in a folder. Tickets will be under-specified, sometimes because I do not know the answer either, and part of the job is figuring out what the answer should be. So read the codebase before you ask. Google it before you ask. Look at how the neighboring module solved the same problem before you ask. When you still cannot resolve it, bring me the question along with the two options you are choosing between. When you have to assume something, assume it, write the assumption into the plan, and flag it. I will correct it if it is wrong, and that costs me thirty seconds. Ten questions the codebase already answers costs me an hour. Judgment is the job. The line between initiative and recklessness is whether you did the work to narrow it down first. WHAT YOU WOULD BE WORKING ON Everything runs on AWS. A financial management and P&L SaaS for restaurant operators. Express, Drizzle ORM, Postgres on Supabase, Passport auth, Zod validation, Sentry and AppSignal, POS and Google Workspace integrations, scheduled jobs, PDF and CSV ingestion, on EC2. Most of the hours land here. An offline-first PWA for rental inventory. Express and Drizzle on Neon Postgres, S3 presigned uploads, QR scanning, an IndexedDB operation queue with a sync engine behind it. Local-first, server-authoritative. Sync conflict resolution is the interesting problem. A Django and DRF backend for a manufacturing client. Versioned budget line items and variance calculations that have to foot across four surfaces. Python, not TypeScript. A content platform on Supabase with edge functions and an admin layer. Lighter, but real. WHY YOU WOULD WANT THIS ONE You get ownership, not tickets. You take a domain end to end, from schema to endpoint to test, and you keep it. You are the backend specialist, not the person who does backend on Tuesdays. A dedicated front-end dev handles the client side. A QA engineer verifies the work. A full-stack dev covers the seams. You are not on-call and you do not own the infrastructure. A DevOps engineer runs AWS, deploys, and pipelines. You write the query, they keep the box up. The standards are already written. Every repo has an architecture doc covering conventions and settled decisions. You will still meet a 3,000-line file, but you will know why it exists and where new code goes instead. The patterns repeat. Drizzle, Zod, TanStack Query, Vitest, Playwright, applied the same way everywhere, so what you learn on one repo transfers to the next. Money moves through one of these products. Inventory moves through another. Your work ships to people who notice. No agency, no account manager, no committee. You ask a question, you get a decision the same day. THE WORK REST endpoints in Express and Drizzle, Zod validation at every boundary Schema design and Drizzle migrations, including backfills against live data Query optimization and indexing on Postgres, both Supabase and Neon Integrations: POS, Google, Resend, S3, Anthropic, OpenAI Offline sync and conflict resolution on the PWA Django and DRF serializers, with calculation logic that must match the frontend exactly Tests. Vitest for unit and integration, Playwright for E2E. QA verifies, QA does not write them for you Production debugging through Sentry and AppSignal STANDARDS Every PR is code you have read, understood, and can defend line by line. If you cannot explain why a query is written the way it is, it does not merge. Immutability over mutation. Small focused files over large ones. Errors handled explicitly. Input validated at every boundary. No any or unknown types. These live in the repo standards, not in my preferences. Tell me an estimate is wrong. Do not quietly miss it. YOU ARE A FIT IF You have worked inside a serious engineering organization, enterprise or well-run scale-up, and it shows in your defaults. Code review is normal to you, not friction. You have shipped under a release process, owned something in production, and written a postmortem for an outage that was yours You have shipped production Node and TypeScript backends, Express specifically You read a Postgres query plan and know what to index You have used Drizzle or a comparable typed ORM, and you know why a committed migration is never edited You write tests without being asked You can read a codebase you did not write and work inside its conventions rather than around them You have overridden an AI agent's proposed approach recently and can tell me why You have shipped against an incomplete spec, and you can tell me what you assumed and how you checked it You have worked in two-week sprints, you size your own tickets, and you say so when a sprint is over-committed Bonus: Python and Django REST Framework, required for the client backend Bonus: offline-first or sync-engine experience WHAT I AM NOT LOOKING FOR Anyone whose entire history is solo builds, small agency sites, and tutorial projects. This work reaches clients who audit it, and it has to survive that Equally, anyone who only functions with a business analyst and a fully groomed ticket. Enterprise habits, studio autonomy. I need both, and the combination is the actual job An agency or a reseller. One person, doing the work themselves. I will ask whether you subcontract, and your answer goes in the contract A front-end developer who also does some backend. Front end is covered Rewrites. If your first instinct on an unfamiliar codebase is to replace it, we will not get along HOW THIS WORKS Three steps, and you are paid from the first one. 1. A $150 fixed-price task, funded in escrow before you start. A real ticket from the real backlog, and it will be under-specified, on purpose and about as much as the real ones are. You write the research.md and plan.md first, with your assumptions stated, and I approve the plan before you write a line of code. That is how every task here starts, so the trial is the job rather than a simulation of it. You get paid whether or not we continue. 2. A 30-minute call. 3. A paid two-week trial at full rate. If it works, ongoing at 15 to 25 hrs/week. Rate: $55 to 80/hr depending on experience, the same at every stage. Steady ongoing hours, no sales cycle, no agency margin, and one client who answers the same day. CADENCE We run Scrum properly, not as a word in a job post. Two-week sprints. A 15-minute standup every day. One hour a week for sprint planning and backlog grooming. That is a little over two hours of meetings a week, and at 15 to 25 hours that is roughly a tenth of your time, so price it in rather than discovering it in week two. Everything outside those is async. Work is tracked in ClickUp. Standup is live at 2pm CEST, and you need to be on it. That is 1pm in London, 3pm in Bucharest, 5:30pm in Bangalore, 9am in Sao Paulo, and 8am on the US East Coast. If you are on the US West Coast it is 5am, which I am not going to ask anyone to do. I am in France right now and back in Los Angeles later in the year, so that hour will shift once. If your timezone works for one of those and not the other, say so in your proposal and we will sort it out before you start rather than after. Tools: GitHub, ClickUp, AWS, Sentry, AppSignal, Supabase, Neon. TO APPLY Send two things through Upwork. Both are required, and proposals missing either one do not get read. 1. A 90-second Loom. Show me a plan or spec you wrote before letting an agent implement something, and the moment you overrode the model. What did it propose, what did you do instead, and why were you right. Phone camera is fine, no slides, no music. I am listening for how you think, not how you present. 2. Two paragraphs on this. A mobile client goes offline for six hours, queues fourteen inventory mutations, then reconnects to find two of those records were edited server-side in the meantime. How do you resolve it, and what do you tell the user. I have deliberately not told you the business rules, and I am not going to. Decide what they should be, state your assumptions, and answer. Proposals that ask me to clarify the requirements first are answering the wrong question. Start your proposal with the word MIGRATION, and name the largest engineering organization you have worked in and what you owned there. One line is enough. Apply through Upwork only. Look up my email, phone, or LinkedIn and contact me there, and you are declined and reported. It violates Upwork's Terms of Service, and I read it as a judgment test, not initiative. I read every complete proposal and reply inside three business days. If the process I described sounds like how you already work, this will be a short conversation.