Data Engineer — E-Commerce API Ingestion & Warehouse Build (Postgres/Fabric, ~32 marketplaces)

We're a US multi-channel e-commerce importer rebuilding our data warehouse. About 2 million orders a year across roughly 32 marketplaces, two US distribution centers, ~5,000 active SKUs. We have legacy xlsx sheets with order data and an existing data warehouse that was vibe-coded. It works, but nobody internal can operate it, so we're replacing it with something clean and documented. What you'd build: Ingestion from Amazon SP-API and Ads API, Walmart Marketplace and Connect, eBay (5 stores), Shopify (6 stores), Google Ads, Newegg, SkuVault, plus ~19 more marketplaces through one ChannelAdvisor/Rithum integration. Then the warehouse itself — modeling, incremental loads, backfills, jobs that re-run safely, and data quality checks that catch problems before we notice them. Out of scope for now: PPC bid modeling, demand forecasting logic, and anything customer-facing. Those come later. Scale — please read before proposing Tens of gigabytes, not terabytes. No streaming requirement. Nightly batch is fine. We're a Microsoft shop, so Fabric, Synapse or plain Postgres all work — propose what you'd actually choose at this volume and tell us the monthly cost. Target is under $1,500/month. If your first instinct here is Snowflake with Fivetran and a Spark cluster for $10,000/month, we're probably not a fit. How this works Fixed price by milestone. We're awarding milestone 0 first — a paid ~1-week assessment where you review our environment and return an architecture proposal with itemized monthly costs and a revised estimate for the rest. We contract the remaining milestones based on what comes back. The $25,000 budget is our working estimate for the full build. If it is off — quote what the work actually costs and tell us why. We'd rather pay the right number than the posted one. All code goes in our repos and all cloud accounts in our name from day one. We need at least 2 hours of daily overlap with US Eastern. Attached brief has the full scope, including the specific data problems we've already diagnosed — timezone handling, order ID mismatches across sources, and a double-counting trap in how our channels overlap. Please reference them in your proposal. We won't reply to generic pitches.