A product customers use.
New Yolk customer figures from July 31, 2026. These dated aggregates describe the platform's scale, not the impact of an individual feature.
- 12k+
- monthly active customers
- 17k+
- unique paying customers
- $15M+
- completed customer deposits
The $15M+ figure is the total value of deposits customers completed through the product. It is not revenue, sales, GMV, audited cash, or cash collected in a bank account.
The engineering behind the product.
Customer applications, staff workflows and financial records belong to one product. The work spans the shared architecture, settlement model, operational tools, integrations and delivery, with explicit decisions about how each part can fail and recover.
One product, used from both sides of the business.
Customer web and mobile applications, staff workflows and a shared model of accounts, products and transactions.
Share the rules for the product, while designing the customer and staff journeys separately. A mobile confirmation needs a clear next action; an approval screen also needs authority, provenance and an audit trail.
Tradeoff and supporting evidence
Shared code reduces duplicated rules, but does not make client releases simultaneous. The server still has to account for installed mobile versions and preserve historical records as the model evolves.
Inspected application and package boundaries: Farm, CRM and Expo consume the shared API and domain packages. This is a responsibility and code-structure map, not a deployment topology.
Keep the money correct as the product changes.
Product-specific rates, conserved funding, delayed approvals and reversals tied to the original transaction.
Commit the economic transition atomically, retain its source and allocation, and make the receipt explain the result. Use precise decimal arithmetic and database constraints for conserved amounts.
Tradeoff and supporting evidence
Historical ambiguity cannot always be repaired automatically. A reversal without a sufficient original receipt must stop, and a changed quote can require another confirmation. That friction is preferable to inventing a financial history.
Inspected settlement, funding-conservation and reversal implementations and their PostgreSQL fixtures cover partial fulfillment, refund obligations, replay and rollback. The example below is synthetic, not a customer record or an executed payout.
Make operational actions deliberate and accountable.
Lead intake and distribution, ownership checks, approval workflows and reports with meaningful attribution.
Make preview, authorization, mutation and reporting describe the same operation. Enforce record ownership on the server and keep customer activity distinct from staff-attributed work.
Tradeoff and supporting evidence
An optimistic interface still needs a conflict path. Preserving the reviewed allocation means asking staff to refresh when it becomes stale, and report definitions need to remain consistent across the table and export.
Inspected lead allocation and reporting code, committed staff release notes, and PostgreSQL fixtures for exact distribution, replay and ownership rejection. No private customer or staff data is reproduced here.
A committed transaction and a delivered message are different facts.
Transactional outbox, bounded delivery retries and a deliberate limit on workflow orchestration.
Make the database commit the source of truth for the business event, then deliver its side effects independently. Treat an uncertain provider outcome as uncertain instead of claiming universal exactly-once delivery.
Tradeoff and supporting evidence
The outbox adds dispatch state, retry policy and operational follow-up. It provides an inspectable recovery path, but cannot erase every provider-side ambiguity.
Inspected transactional enqueue and leased dispatcher code, outbox database tests and the recorded workflow retirement decision. This describes the implementation boundary, not an uptime or delivery-rate claim.
Shipping includes the version people actually have.
Native sessions, customer languages, release-aware updates and verification of real failure paths.
Verify the database transition, the user-facing workflow and the delivery channel separately. Keep review-build evidence distinct from a production or store-release claim.
Tradeoff and supporting evidence
A correct server change may still require a native update, device testing and store availability. Those are delivery constraints to manage explicitly, rather than hide behind a successful build.
Inspected mobile release-policy code and documentation, locale configuration, API error classification and historical Android QA. No new mobile release, production verification or performance measurement was performed for this case study.
Engineering examples reviewed against source on September 20, 2026. Illustrations use synthetic data. They explain implementation decisions, not a newly verified production rollout or a measured business improvement.
Read Dan's full engineering case study