I read the brief carefully. What stands out is that you are not simply looking for an n8n developer — you need a reliable decision pipeline that turns Amazon Ads, product and BSR data into actionable signals about wasted spend, pricing and product performance.
That is where I would focus the first milestone.
I’d build the foundation around:
• Amazon Ads data → validated performance data
• ClickUp catalog → structured product/ASIN mapping
• Keepa/BSR signals → pricing and product-performance context
• Deterministic calculations for spend, ACoS and opportunity sizing
• Claude for analysis and explanation, not as the source of financial truth
• Clear validation, retry and failure handling
• Slack alerts with the underlying data available for verification
For the first phase, I would deliberately start with the Ad Waste Detector rather than attempting all three workflows at once.
The goal would be simple: reliably identify meaningful waste, quantify its dollar impact, and give your PPC manager an action they can verify before expanding the system.
My relevant experience is in n8n workflow architecture, API/webhook integrations, structured data, validation, business logic, error handling and AI workflows. I use a schema-first approach so AI output is validated before it reaches business logic or storage.
I’d prefer to prove the fit through one clearly defined fixed-price milestone, with testing and documented handover included.
Best,
RAR 121
Comprehensive, Integrated & Powerful AI Business
Growth Ecosystem
With ~7,400 live products, how are ASINs currently mapped between ClickUp, Amazon Ads entities, and the royalty CSV? Is there already a consistent unique identifier across all three sources, or should the normalization/mapping layer be part of Phase 1?
Hi Colin, this is a great fit for what I do (n8n + Claude/OpenAI API integrations, REST APIs, Slack Block Kit). Feel free to DM me and I can share examples of workflows I’ve built.
Hi Colin — referencing “Business Performance Analyzer.”
The economics in your brief are strong enough that I would not start by building all three sub-workflows at once. I’d make Phase 1 prove that the source data and decision rules are trustworthy first.
One honest limitation up front: I have not shipped an Amazon Ads + Keepa client system in production, so I won’t claim that experience. My strongest hands-on work is n8n workflow reliability, API/webhook/data handling, state/idempotency, human-review boundaries, and structured LLM outputs. My current CLEAR MERIT Revenue OS is an Internal / Working Demo, not external client production proof.
For a paid first milestone, I’d propose:
Phase 1 — Ad Waste Detector
one week of Amazon Ads data / API payloads
deterministic waste rules first (for example 10+ clicks / 0 orders, ACoS > 40%)
source-total reconciliation before any AI interpretation
Slack output with each action traceable to the underlying campaign metrics
duplicate-safe daily runs
visible error/retry state so a partial API or Slack failure does not silently disappear
Claude used for explanation/ranking, not as the source of financial truth Acceptance checks
totals reconcile against the agreed source report;
the same input run twice does not create duplicate actions/alerts;
every Top-5 action can be traced back to raw metrics;
failed/partial runs remain visible and recoverable. Price / timing: USD 495 fixed, 4 business days after access to one representative Ads payload/report and the required API setup. If Phase 1 passes, I’d scope Phases 2–3 from the proven data shape and keep the overall build within your stated budget band if the API complexity matches the brief.
One suggestion from the brief: store the deterministic metric snapshot used for each Slack recommendation, so when the PPC manager challenges an action you can reproduce exactly why it was generated instead of relying on a later Claude rerun.
I can share my public n8n reliability template / Internal Working Demo structure if useful. If this is still open, send one representative Ads report or redacted payload plus the fields you currently keep in ClickUp, and I can confirm the Phase-1 acceptance checklist before any build starts.
Hi Colin — I’d approach this from the business-decision layer first rather than trying to build all three workflows at once.
My background is about five years working inside SME HR/GA/operations, so my role at CLEAR MERIT is understanding the operating problem, defining scope, business rules and acceptance criteria.
The technical architecture, implementation, testing and documentation are handled through CLEAR MERIT’s AI-assisted delivery workflow under my responsibility.
I don’t want to overstate prior production experience specifically with Amazon Ads + Keepa.
So I’d suggest proving fit with one bounded paid Phase-1 milestone first:
Amazon Ads → validated normalized data → deterministic spend/ACoS calculations → one Slack alert
with:
API/data validation
duplicate/idempotency protection
retry handling
zero-row / silent-failure detection
traceable source values behind each alert
exportable n8n workflow
short handoff/runbook
Claude should explain the numbers, not generate the financial truth — the metrics should come from deterministic calculations.
If that first slice passes your acceptance criteria, we can then scope the Keepa/ClickUp and wider CEO-reporting phases.
If the project is still open, send the expected Phase-1 inputs, one example output, and your acceptance condition and I’ll scope only that milestone.
I’m Pravallika Tadepalli, founder of RUNSTATE. I came across your Business Performance Analyzer project and I’m interested if it is still open.
I want to be transparent about fit: our strongest proof today is custom automation infrastructure rather than 5+ client-production n8n workflows. We’ve built persistent cloud automation involving APIs/webhooks, AI processing, retries, deduplication, state tracking, human approvals, browser automation and auditable workflows.
Rather than overstate n8n experience, I’d suggest starting with a smaller paid preflight: validate the Amazon Ads data shape, join sample data against ClickUp product metadata, store rerun-safe weekly metrics, and generate one decision-focused Slack report.
If that first slice works, I’d be happy to scope the full system within your $1,500–$3,000 Phase 1 budget.
One question before scoping: are your Amazon Advertising API credentials already approved and usable, and do you already have the Keepa access you expect the final system to use?
Hi Colin — I’m interested if the Business Performance Analyzer is still open. My background combines sourcing/e-commerce operations with hands-on n8n, Make, API and AI workflow work. I’ve worked across Alibaba, Lazada and TikTok-related operations, and I’m currently building Shinka AI, a prospect-research/review system with structured data, AI evaluation, validation, deduplication and human approval.
I would start with a small paid discovery phase: define the canonical product/ASIN mapping across Amazon Ads, Keepa and ClickUp, document unmatched records, and produce a static sample of the Slack brief. From there, the ad-waste detector and weekly analysis can be implemented in clearly testable phases.
I haven’t shipped this exact Amazon Ads/Keepa/ClickUp system in production, so I won’t pretend otherwise. I can offer the first mapping and architecture phase for USD 100, credited against a larger engagement if useful. I’m based in Bangkok (UTC+7) and can work asynchronously.
I’m interested in the Business Performance Analyzer project.
I want to be transparent about my current experience: I have strong hands-on experience with n8n workflow design, APIs/webhooks, structured data processing, AI/LLM workflows, validation, error handling and automation architecture, but I have not yet shipped this exact Amazon Ads + Keepa + ClickUp system in production.
Rather than pretending otherwise, I’d suggest starting with a tightly scoped Phase 1.
I would focus first on the Ad Waste Detector:
Amazon Ads data → normalized metrics → deterministic ACoS/spend rules → Supabase snapshot → traceable Slack alerts, with duplicate protection, retries and visible failure handling.
Claude can then explain and rank the results, while the actual financial calculations remain deterministic and traceable.
I’m comfortable working from your existing architecture, using the provided API access, and delivering the workflow with documentation and testing.
I’d be happy to discuss a clearly defined first milestone and prove the fit before moving into the larger build.