As co-founder and CTO, I am the sole engineer across the product. I work from business inputs through customer journeys, architecture, web and mobile applications, integrations and operation.
Customer figures from July 31, 2026. Completed deposits are not revenue. Source and definitions
01 / Product and architecture
One product, used from both sides of the business.
New Yolk connects a customer-facing farming product with the people operating it. Customers manage assets, maintenance, product rewards and wallet activity. Staff work through customer records, lead assignment, deposits, approvals and reporting. A customer action can become an operational task, and a staff decision has to appear correctly in the customer's account.
My responsibility spans those surfaces as co-founder, CTO and sole engineer. The implementation combines Next.js web applications and an Expo / React Native app with shared TypeScript API, validation and business-logic packages, backed by PostgreSQL. The shared layer gives the clients a common contract while leaving each interface room to serve its own users.
What supports this account
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.
The decision
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.
The tradeoff
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.
Three interfaces, shared product rules.
Customer webAccounts, assets, wallet and historyNext.js · React
Mobile appCustomer tasks with native session behaviorExpo · React Native
Staff CRMIntake, assignment, approvals and reportingNext.js · React
A simplified map of code responsibilities. External integrations and hosting details are omitted.
02 / Balances, settlement and history
Keep the money correct as the product changes.
A displayed total hides several different things: Wallet USD, rewards denominated in a product's commodity, a pending purchase and an external refund obligation. Treating them as interchangeable makes the interface simpler at the cost of losing what actually happened. The same commodity can also have different valid rates for different products.
The model keeps that provenance. Funding quotes identify their sources and rates; settlement records the allocation that was actually applied. When inventory changes between a request and its approval, the operation can account for the fulfilled portion and the remainder. Product reward compensation, an internal funding return and an external refund are separate outcomes.
Corrections also have to respect time. A prepaid rent reversal binds the original receipt and purchased term rather than recomputing an old transaction from today's values. Retirement rewards get their own history entries without paying those rewards again. These are changes to the data model and the customer's explanation of it together.
What supports this account
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.
The decision
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.
The tradeoff
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.
When approval cannot fulfill the whole request.
Illustrative $30 request, with $20 applied and a $10 external refund obligation.
Applied to the product
$20
Refund required
$10
Total accounted for
$30
The receipt preserves the split. Recording the refund obligation does not mean the external refund has been paid.
03 / Staff workflows and reporting
Make operational actions deliberate and accountable.
The CRM is part of the product, not just an admin view of its database. Staff need to find a customer, decide who owns the next action, submit a transaction and understand its status. Small ambiguities here can become duplicate customer records, competing assignments or misleading performance figures.
Lead distribution supports an even split, exact quantities or a group queue, with an allocation preview before confirmation. The server rechecks the actor's current permissions and the records being assigned. If ownership changes while someone is reviewing, they must refresh instead of silently applying a different allocation. Existing customer intake checks eligibility and links by matching email without overwriting the profile.
Reporting needs equally explicit definitions. The monthly retention view distinguishes external purchases from reinvestment and excludes customer self-service purchases from agent performance. The Excel export retains the authorized team scope even when the visible table is filtered. A number is useful only if the operator knows what it includes.
What supports this account
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.
The decision
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.
The tradeoff
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.
Review the allocation before changing ownership.
Synthetic example: 100 leads split across three eligible agents.
34Agent A
33Agent B
33Agent C
If a record or permission changes after the preview, refresh the allocation. Retrying an accepted request must not add another assignment event.
04 / Integrations and failure boundaries
A committed transaction and a delivered message are different facts.
A business operation can change records and trigger notifications or external delivery. Doing all of that as a chain of independently retried steps creates a dangerous gap: the customer state can be committed while the next step fails, or a retry can repeat an economic effect.
The chosen boundary keeps the financial change and its outbox event in one database transaction. A separate dispatcher claims a bounded batch using leases, then tracks delivery, retry and terminal failure. Delivery can recover without rerunning the original purchase or approval.
An experimental deposit workflow was removed because durable execution did not supply the missing transaction and idempotency guarantees. The workflow package remains dormant. The useful engineering decision was to keep the business operation correct first, then consider orchestration where it adds value after that boundary.
What supports this account
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.
The decision
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.
The tradeoff
The outbox adds dispatch state, retry policy and operational follow-up. It provides an inspectable recovery path, but cannot erase every provider-side ambiguity.
Separate business state from delivery state.
Commit togetherEconomic change + outbox event, in one transaction
Claim delivery workBounded batch, lease and ownership check
Record the outcomeDelivered, retry, or terminal failure
A delivery retry does not execute the customer's financial operation again.
05 / Mobile, verification and operation
Shipping includes the version people actually have.
Web and mobile share product rules, but their operating conditions differ. An installed app can be several releases behind. It can lose connectivity, return from the background or ask the device to unlock while preserving an unfinished purchase. Customer interfaces also support English and Iraqi Arabic, including right-to-left layout.
The mobile update controller separates source availability from an installable release. It checks after sign-in and device unlock, supports postponing an optional reminder and lets offline failures leave the customer in the app. An announcement requires evidence that the replacement is available in the official store. Merging mobile code does not update installed phones.
Verification follows those boundaries. The repository includes disposable PostgreSQL tests for concurrency, conservation and rollback, alongside browser and device review records. API observability distinguishes expected business rejections from operational failures and restricts logged reasons to a bounded vocabulary. The aim is to make both a failed operation and the evidence needed to investigate it understandable.
What supports this account
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.
The decision
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.
The tradeoff
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.
Source, device and store are separate checkpoints.
Implementation checkedTypes, behavior and database invariants
Workflow exercisedBrowser or native review build, with explicit evidence
Replacement availableVerified official-store version before announcing an update
The September Android QA record describes a review build. It does not establish iPhone behavior or publication of the next release.
Three interaction close-ups.
These smaller examples show how the broader decisions reach the interface: a missing response, the sources behind a purchase and a return to an unfinished task. The walkthrough and funding values are illustrative.
A lost response must not become a second withdrawal.
A withdrawal can reach the server even when its response never reaches the phone. An app restart makes that uncertainty harder to recover from.
Save the request on the device before sending it. After an uncertain result, retry the same request identity. The server checks for an existing result and returns its receipt; a changed request cannot reuse that identity.
The tradeoff
The app has to show an unresolved request until it can reconcile it. That is more work than showing a generic error, but it preserves the difference between a failed request and a missing response.
What the evidence establishes
The inspected mobile implementation restores pending requests after restart. The server implementation returns the existing receipt for a matching retry.
Follow a lost response
Synthetic walkthrough · 1 / 4
Ready to send
PhoneRequest saved on deviceDEMO-104
ServerNo request recorded yet0 recorded requests
The device saves request DEMO-104 before sending. If local storage fails, it does not send the request.
ReceiptAwaiting request
An explanation of the recovery design. No account, network request or money movement.
Show what will pay before asking for confirmation.
A total balance does not explain which funds are spendable, which product supplies them, or what remains after a purchase.
Keep wallet funds and product rewards distinct. Preview the funding sources, conversion rates and remaining balances. Bind confirmation to that quoted allocation, then show the settled receipt in the same structure.
The tradeoff
A changed allocation requires another confirmation. The extra step matters because the customer is approving where the money comes from as well as the total.
What the evidence establishes
The inspected funding component supports both preview and settled states, including each source's debit and remaining balance. The maintenance flow submits the quoted funding fingerprint.
One $60 allocation, visible before confirmation.Synthetic values · USD equivalents
Illustrative funding sources for a $60 purchase
Source
Before
Used
After
Product rewards
$80.00
$40.00
$40.00
Wallet funds
$60.00
$20.00
$40.00
Amount to confirm$60.00
The real product also shows native units and their conversion rates. This simplified illustration explains the allocation; it is not a customer receipt.
Preview the sources
Confirm that allocation
Read the settled receipt
Returning to the app should preserve the task.
Customers need to return to an existing session without repeatedly requesting an email code. A long-lived session also needs protection when the device changes hands.
Separate the account session from device unlock. Use native authentication on cold launch and after a longer background interval, while preserving the screen behind the lock. Keep retry and sign-out available when unlock or connectivity fails.
The tradeoff
Protecting the main screen is insufficient if a purchase dialog still appears in the app switcher. The dialog window needs the same privacy treatment.
What the evidence establishes
A September 10 Android review-build record covers unlock, passcode fallback, offline recovery, sign-out and app-switcher privacy with synthetic data. It does not establish iPhone behavior or store availability.
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.
Where the numbers come from.
SOURCE · REVIEW DATE · DEFINITION
Customer figures
Operator-approved product and customer totals from July 31, 2026.
Production version
New Yolk Farm V2 confirmed in production on August 8, 2026.
Next review
Recheck these public figures by November 8, 2026.
$15M+ in plain English
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.
Have a product with similar challenges?
I work across product decisions, customer applications and the systems behind them. Send me the context and the kind of responsibility you need.