Marketplace software that holds up when both sides grow
Willowark builds the transactional core of marketplaces and multi-sided platforms: payments and payouts, the ledger that has to reconcile, search and ranking that matches demand to the supply you have, seller onboarding, and the trust and safety machinery that keeps a few bad actors from becoming everyone's problem. The problem we remove is a growth curve outrunning an architecture that was correct at ten thousand transactions.
We start at the money, because it is the part that cannot be approximately right. Transactions are modeled as immutable events with double-entry postings rather than mutable status columns. Write paths are idempotent, so a retried webhook never double-pays a seller, and reconciliation runs against the processor rather than trusting internal state. Around that we build the surfaces you operate on: payout scheduling with holds and reserves, a disputes workbench, seller statements that match the bank, and admin tooling that does not require querying production.
A first engagement typically begins with the part that is already costing money: a payout reconciliation that closes a week late, a ranking change nobody can measure, or a fraud pattern that outgrew the shared inbox. We work inside your codebase and release process, under the constraint that a marketplace never stops transacting, so changes to the ledger or payment path ship behind flags with a parallel run against the old path before cutover. Release pressure from category launches and acquisition spend shapes the sequence; we take the underbuilt system so your team can keep shipping growth.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“Payouts are right most of the time, and the exceptions eat a person's week.”
Most of the time is the problem. We rebuild the payout path on an immutable ledger with idempotent writes and a state machine that models holds, reserves, reversals, and returned transfers as real states rather than flags. Reconciliation against the processor runs automatically and routes only genuine breaks to a workbench.
“Search is our conversion problem and we cannot see why anything ranks.”
We make ranking observable before making it better: log the query, the candidate set, the feature values, and the outcome, so a result you disagree with can be explained. From there we work the indexing pipeline, relevance tuning against real judgments, and experiments measuring purchase rate and supply utilization.
“Fraud found us and our tooling is a database query and a Slack channel.”
We build the actual function: risk scoring at signup, listing, and checkout from velocity, device, payment, and graph signals; review queues with case management; and actioning with an audit trail. Rules stay editable by your risk team rather than needing a deploy.
“Every new category means a schema change and something breaks.”
That is a data modeling problem with a known answer. We separate the transactional spine identical across categories — orders, payments, ledger entries, messaging — from category-specific attributes, which get a typed, versioned schema per vertical instead of a wider table. Launching a category becomes configuration.
“Our sellers cannot tell what they were paid for, and support answers it by hand.”
Seller statements should be generated from the ledger, not assembled by a person. We build statement and earnings views that trace every payout to the orders, fees, refunds, and adjustments behind it, matching the bank to the cent, with exports in the formats sellers' accountants want. Support then links to a statement rather than reconstructing one.
How this industry actually runs
The operation as we usually find it.
A marketplace has two customers and one product, and the two want opposite things. Growth is never symmetric, so you are always short on one side, and the work that fixes supply is not the work that fixes demand. Take rate is the business model, so every system touching payments touches revenue directly: processing fees, chargebacks, failed and returned payouts, tax handling and 1099-K thresholds, and the float between capture and disbursement. Trust and safety starts as a shared inbox and becomes a real function the first time fraud finds you, usually the month you start spending on acquisition. Search is the whole demand-side experience, and ranking is where the business model becomes visible, with relevance, quality signals, and promoted placement pulling on one result set.
Product, integrations, and the AI feature behind them
Components:
- Your product (web, mobile, API)
- Backend services (queues, jobs, evals)
- AI feature (retrieval, review gates)
- Data & integrations (warehouse, third parties)
Connections:
- Your product to Backend services (API)
- Backend services to AI feature (structured calls)
- Backend services to Data & integrations
What we build
Starting projects that fit Marketplaces & Platforms.
- Ledger and payout engines with double-entry postings, idempotent writes, and automated reconciliation
- Payments integration: split payments, escrow and holds, multi-party disbursement, disputes, tax data
- Search and ranking infrastructure — indexing pipelines, relevance tuning, faceting, experiment framework
- Trust and safety tooling: risk scoring, velocity and device signals, review queues, audited actioning
- Seller onboarding and catalog ingestion with identity verification, import validation, inventory sync
- Data model work for category expansion, so a new vertical is a schema rather than a migration
- Seller statements and earnings reporting generated from the ledger, with exports that match the bank
- Admin and operations tooling — refunds, adjustments, manual review — so nobody queries production to fix an order
Capabilities we bring
Working in Marketplaces & Platforms?
Tell us the line.
What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.
Common questions
What Marketplaces & Platforms teams ask first.
Can you work on our payments stack without expanding our compliance scope?
That is the design goal. We tokenize at the edge, keep card data out of every system that does not require it, and segregate the services that do. Willowark holds no certifications of its own and claims none; we engineer to your control set.
Have you built systems that handle money at volume?
Yes. We worked with American Express on global loyalty and rewards, migrating legacy systems to event-driven microservices in Go across point tracking and the ledger, through to war-room production deployments. Points are money there, with the requirements a marketplace ledger has: idempotency, reconstructable history, balances that reconcile.
We already have engineers. Where does an outside team fit?
On the discipline your team has no room to specialize in. Marketplace engineers are typically consumed by growth work and category launches, which leaves the ledger, the payout state machine, ranking infrastructure, and risk tooling underbuilt until something goes wrong.
Should we build our own ledger or use a payments provider's balance features?
Usually both, at different layers. A provider like Stripe Connect or Adyen handles moving money, compliance scope, and payouts to bank accounts well, and rebuilding that is rarely worth it. What the provider does not hold is your business logic: fees, holds, reserves, promotions, adjustments, and the balance you show a seller before funds settle. That belongs in a ledger you own, reconciled against the provider. Typically we recommend building that layer thin and keeping the provider as the source of truth for actual transfers.
Can you replace our payout system without pausing payouts?
That is how it has to be done, since a marketplace cannot stop paying sellers while the plumbing changes. The usual approach is a parallel run: the new ledger consumes the same events as the old system and produces its own balances, and we compare the two over several payout cycles before anything routes through it. Discrepancies get investigated one by one, because some of them will be bugs in the old system. Cutover typically happens per cohort of sellers, with rollback ready, rather than all at once.
Strategy. Software. Systems.
Engineering for Marketplaces & Platforms.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.