M01with full monitoring
0
Critical incidents post-launch
Case · Dibstr
Marketplace · 2024
A marketplace built for production from week one.
Dibstr came to us with a marketing-led prototype, a small founding team, and a deadline that did not bend.
fig. 01 — dibstr · marketplace · 2024
01
The brief
Context, constraint, and the part that mattered.
The product had to launch as an actual marketplace — not a landing page with a waitlist — with payments, KYC, seller onboarding, and the operational tooling to run a live cohort from the first week. Our job was to take the existing positioning and turn it into a system the founders could defend to investors and run with the team they had on day one. We started with a one-week architecture sprint that produced the data model, the integration shortlist, and a list of trade-offs we wanted the founders to make before we wrote production code. From there we ran a six-month engagement with weekly demos against real branches, merging into main from week three. The brand and product UI were rebuilt in parallel with the platform so the visual language could evolve as the system did, instead of being frozen by a separate agency on a different track. By the time the pilot cohort opened, the marketplace had real sellers, real payouts, and a runbook the founding team could operate without us. We stayed for two months of post-launch operation — monitoring, evaluation, an on-call rotation — and then handed over cleanly to an in-house engineer.
02
Approach
What we did, in the order we did it.
- 01
Brand and visual system
We rebuilt the brand from the inside out — wordmark, type pairing, color system, motion language — so it could carry both the marketing site and the product UI without translation loss between teams. The system was designed to be operated by a single in-house designer post-handover: limited primitives, documented exceptions, no decorative components that nobody could later justify. The result is a brand that reads premium without leaning on stock photography or stock illustration, and that survives the editorial scaling that happens once a marketplace has real listings and real sellers.
- 02
Marketplace architecture
The platform is a Next.js app on top of a Postgres-first data layer, with a thin service boundary in front of payments and identity. We chose boring, observable primitives — Prisma, BullMQ, Redis for caching and queues — and pushed the novelty into the parts that genuinely needed it: the matching logic, the seller payout flow, and the moderation pipeline. Every domain has an explicit owner module, an explicit set of invariants, and an explicit failure mode. There is no ambient state, no cross-module reach-in, and no service that the founders cannot describe in two sentences.
- 03
Payments, KYC and seller onboarding
Stripe Connect carries payments and payouts; Sumsub carries KYC. Both are wrapped in a thin internal API surface so a future migration is a config change, not a rewrite. Seller onboarding is a single state machine — invitation, identity verification, listing approval, first transaction — and every transition emits an event the operations team can replay or roll back. The product was designed to allow the founders to run the first 50 sellers themselves without engineering involvement, and that is exactly what happened in the first month after launch.
- 04
Operations from day one
We shipped Datadog, Sentry, structured logs, and a small operations dashboard from week three of the build, not after launch. The runbook covers the five things that statistically break a marketplace in its first 90 days — payment failures, KYC stalls, listing abuse, payout delays, and search degradation — and each of those has a documented detection path and a recovery procedure. After handover, the in-house engineer was operating the platform unaided within two weeks.
03
Selected artifacts
A small spread from the engagement.
fig. 02 — artifact 1
fig. 03 — artifact 2
fig. 04 — artifact 3
fig. 05 — artifact 4
fig. 06 — artifact 5
04
Outcome
The numbers we agreed to ship against.
M02real code in production
Week 3
First merge to main
M03team owned within 2 months
Full
Handover with runbooks
They built our marketplace from zero in a way that genuinely surprised us. Strategy was sharp — and the engineering kept pace.
Have a project that looks like this?
Send a short brief — we'll reply with concrete next steps. New engagements are limited each quarter.