ABOUT US We run a payments-adjacent integrations platform. Our customers connect their billing systems (Stripe, Chargebee, Recurly, plus two bank partners) and we normalize the inbound event stream into a single schema they consume through our API. Around 4.2M events/month right now, spiky, with the top decile of tenants producing most of the volume. Three engineers in-house. We bring in contractors for isolated infrastructure work where the boundaries are clean and the correctness requirements are explicit. STACK TypeScript end to end, Node 22 Hono on Cloudflare Workers for the edge ingestion tier Postgres 16 (Neon) with Drizzle, logical replication to a read replica Redis (Upstash) for dedup keys and rate limiting BullMQ workers on Fly.io for async processing Next.js 15 App Router for the internal operator console OpenTelemetry into Grafana Cloud THE PROBLEM Our current webhook receiver is a thin route handler that writes straight into Postgres and returns 200. It has three failure modes we've hit in production: Providers redeliver on their own schedule and we double-process. We've had duplicate ledger rows twice this quarter. When a downstream projection throws, the event is gone. There is no replay path, so recovery means asking the provider to redeliver, which two of our partners will not do. A single tenant's burst starves the shared worker pool and delays everyone else's events. We want the ingestion tier rebuilt as a durable, idempotent, replayable log. FIRST MILESTONE: IDEMPOTENT INGESTION GATEWAY WITH REPLAY Scope: 1. Signature verification at the edge. Per-provider HMAC schemes (Stripe's timestamped v1 scheme, plus two providers using raw body SHA-256). Constant-time comparison, configurable clock skew tolerance, reject outside the window. 2. Idempotency layer. Derive a stable key from provider plus event id, falling back to a content hash where the provider does not supply one. Redis SETNX with a 72-hour TTL as the fast path, unique constraint in Postgres as the authoritative backstop. A redelivery must return 200 and do nothing, not 409 and not a second insert. 3. Durable raw log. Append the untouched request body, headers, and receipt timestamp to an append-only events_raw table before any parsing happens. Parse failures must not lose the payload. This table is the replay source of truth. 4. Per-tenant fair queueing. Enqueue to BullMQ with a per-tenant concurrency ceiling so one noisy tenant cannot consume the pool. Bounded exponential backoff with jitter, five attempts, then a dead letter queue. 5. Replay endpoint. An internal, authenticated endpoint that re-emits a time range or a set of event ids from events_raw back through the processing pipeline. Replay must be safe to run twice, which falls out of the idempotency layer if it is built correctly. 6. Operator console page. A single Next.js page listing DLQ entries with the failure reason, attempt count, and raw payload, with a button to requeue one or requeue a filtered set. ACCEPTANCE CRITERIA Replaying the same 10,000 events twice produces zero additional rows in the projection tables. This is the main thing we will check. Signature verification is covered by unit tests, including a tampered-body case and an expired-timestamp case. p99 on the ingestion handler stays under 150ms, since two of our providers disable endpoints that respond slowly. Poison messages land in the DLQ rather than blocking the queue. Trace context propagates from the edge handler through to the worker, visible as one trace in Grafana. Delivered as one PR against a feature branch, with a written note on the tradeoffs you made. HOW WE WORK TOGETHER Once the contract is in place, we'll add you to a shared channel in our Slack workspace for day-to-day communication. Design questions, edge cases you hit in the provider payloads, and anything that needs a fast answer go there. Ticket detail and scope changes stay in Linear so there's a written record. We do not run standups and we do not expect instant replies, but we do check Slack through the US morning and you should be reachable within a few hours during your stated overlap window. Onboarding on day one is repo access, a seeded staging environment, captured real payloads from all five providers including several malformed ones, a load-generation script, and the Slack invite. WHAT COMES AFTER If this goes well, the backlog is adjacent: a projection rebuild runner for the read models, per-tenant rate limit tiers at the edge, and a partner-facing delivery log with its own retry semantics. That would move to a retainer or hourly. WHO WE ARE LOOKING FOR 5+ years shipping production TypeScript, with real backend ownership rather than UI work alone You have opinions about idempotency keys, at-least-once delivery, and why exactly-once is mostly a marketing term Comfortable in Postgres beyond the ORM. Unique constraints, advisory locks, and transaction isolation should not be new vocabulary Async by default. Linear tickets, PR review, Slack for the rest. Overlap with 9am to 1pm ET at least two days a week TO APPLY Skip the generic pitch. Instead: 1. Open your proposal with the word "idempotent" so I know you read this. 2. In four or five sentences: where do you put the dedup boundary, and what happens when Redis is unavailable but the request still has to be accepted? Give me the tradeoff you would actually make, not the textbook answer. 3. Link one repo or shipped system involving queues, webhooks, or event processing. BUDGET Fixed price for this milestone. Propose your number. We are not shopping for the lowest bid, and I would rather pay well once than pay twice. Ongoing work would be hourly. One practical note: keep the Slack mention worded as after the contract, the way it is above. Upwork's terms allow moving communication off-platform once a contract is active, but proposing it before that point is what gets posts flagged, and the phrasing here stays on the right side of that.

Fixed price: $100 We’re looking for experienced freelance developers to build a small, real-world web application using Marlow, an AI software development platform. Marlow lets you describe what you want to build, generates the application with you, and gives you ownership of the resulting source code. Applications can be deployed using Marlow or to your own infrastructure. We’re specifically looking for freelancers who regularly build websites, SaaS products, internal tools, or web applications for clients. The project You’ll receive a simple application brief similar to something a real client might request. Your job will be to: Create a free Marlow account (marlow.app/beta) Build the application using Marlow Test and refine the application Get it to a working state Spend approximately 60–90 minutes actively using the platform Provide candid feedback about your experience We are particularly interested in understanding whether Marlow could help freelancers deliver client projects faster. Feedback After completing the build, we’ll ask you a few questions such as: What was easy or difficult? Where did you get stuck? What did you like or dislike? How does Marlow compare with your normal development workflow? Would you consider using Marlow for an actual client project? What would need to improve before you would use it regularly? We want genuine feedback. Positive feedback is not required. There is also no requirement to post a review, social media post, testimonial, or public endorsement. Who we're looking for Ideally you: Have experience building web applications for paying clients Work as a freelance developer Have experience with JavaScript, React, Next.js, Node.js, or similar technologies Have completed multiple projects through Upwork Regularly work on web apps, SaaS products, dashboards, marketplaces, or internal tools Are comfortable testing new AI development tools Experience with tools such as Cursor, Claude Code, Lovable, Replit, Bolt, v0, or other AI development platforms is a plus, but not required. Compensation $100 fixed price Marlow usage credits required to complete the project will be provided. If you're a strong fit, there may also be opportunities for additional paid projects testing larger or more complex builds. To apply Please answer these three questions: What kinds of applications do you normally build for clients? What AI coding or AI app-building tools do you currently use, if any? Send us one example of a web application you've built. Please start your application with the word MARLOW so we know you've read the full description. We're looking to work with multiple developers.