Senior Python / Playwright Developer to Finish AI Reselling Automation Integration

I have an existing AI-powered reseller automation application called ResellerOS. This is NOT a build-from-scratch project. ResellerOS is primarily Python and already has working components for: • AI product identification from photos • AI-generated listing titles and descriptions • Item-specific/listing generation • eBay sold-comp and pricing research • Confidence-based recommendations • Inventory tracking • Nifty.ai integration • Existing draft updates • Review/approval workflows • Automated tests I need an experienced Python/Playwright engineer to finish and stabilize the end-to-end workflow for NEW inventory. GOAL I should be able to provide photos of a new clothing item and have ResellerOS process the item and create a completed Nifty draft with minimal human intervention. ResellerOS must NEVER publish the listing live. Final publishing remains with the seller. CURRENT BLOCKER The application currently gets through: Photos → AI identification → listing generation → pricing/review plan The problem occurs when creating the first Nifty draft for a completely new item. ResellerOS creates a local inventory UUID first. The current apply path incorrectly attempts to update Nifty using that local UUID. Since the item does not exist in Nifty yet, Nifty returns a 404. The repository already contains infrastructure for creating new Nifty drafts and storing the resulting Nifty item ID. I need someone who can understand the existing architecture and correctly connect these pieces rather than rewriting the application. REQUIRED BEHAVIOR NEW ITEM: Photos → AI analysis → listing generation → pricing → create Nifty draft → upload photos/data → save Nifty ID in ResellerOS → Ready for Review EXISTING ITEM: ResellerOS item → find mapped Nifty ID → update the existing Nifty draft The workflow must automatically determine whether to CREATE or UPDATE. Retries/restarts must not create duplicate Nifty drafts. SCOPE • Review the existing codebase and architecture • Fix the new-item → Nifty draft lifecycle • Preserve the existing update path • Store the Nifty ID against the local inventory record • Ensure photos and generated listing data reach Nifty • Preserve review-before-publish • Prevent duplicate drafts • Add/update regression tests • Add reasonable error handling • Validate the completed workflow on at least 5 new clothing items Normal use should NOT require the seller to enter UUIDs or run Python commands in Terminal. DEFINITION OF DONE We will test ResellerOS with 5 clothing items that have never existed in ResellerOS or Nifty. The system must create the appropriate Nifty drafts with the available photos and generated listing information. After restarting/re-running the workflow, those same items must NOT produce duplicate drafts. Nothing may automatically publish live. IMPORTANT I am NOT looking for: • A rewrite • A new n8n/no-code solution • A different application • Unnecessary UI redesign • Features outside this scope I want an experienced developer who is comfortable entering an existing codebase, diagnosing the architecture, and getting the current system working reliably. Strong experience desired: • Python • Playwright/browser automation • API integrations • Debugging existing applications • State/ID mapping • Idempotent automation • Automated testing • AI/LLM integrations Experience reverse-engineering web application workflows or undocumented APIs is a plus. This is an initial $500 fixed-price project. If this project goes well, there may be additional ResellerOS development work later. WHEN APPLYING, ANSWER THESE QUESTIONS: 1. A local application creates an inventory UUID before an item exists on an external platform. How would you design the create-vs-update workflow so retries cannot accidentally create duplicate external records? 2. Describe a Python + Playwright automation project you have built and the hardest problem you solved. 3. How would you handle a crash that occurs AFTER Nifty successfully creates a draft but BEFORE ResellerOS saves the new Nifty ID locally? 4. Are you comfortable improving an existing architecture rather than rebuilding it? 5. What do you believe you can realistically complete within the $500 fixed-price scope? Please include the word DOJO somewhere in your proposal so I know you read the full description.