[{"data":1,"prerenderedAt":687},["ShallowReactive",2],{"case-study-operational-integrity-for-cash-ledgers":3,"case-study-related-operational-integrity-for-cash-ledgers":123},{"id":4,"title":5,"body":6,"client":96,"description":97,"diagram":98,"extension":99,"kind":100,"meta":101,"navigation":102,"order":103,"outcome":104,"path":105,"pillar":106,"productUrl":107,"sector":108,"seo":109,"services":110,"status":107,"stem":113,"technologies":114,"years":121,"__hash__":122},"caseStudies\u002Fcase-studies\u002Foperational-integrity-for-cash-ledgers.md","Operational Integrity for Multi-Location Cash Ledgers",{"type":7,"value":8,"toc":86},"minimark",[9,14,18,22,51,55,72,76,79,83],[10,11,13],"h2",{"id":12},"challenge","Challenge",[15,16,17],"p",{},"Cash moves constantly between branches through couriers and transfers. Every entry needed independent verification, branch systems had to feed a central ledger over connections that weren't always reliable, and the approval process had to prevent collusion between staff at the same location.",[10,19,21],{"id":20},"approach","Approach",[23,24,25,33,39,45],"ul",{},[26,27,28,32],"li",{},[29,30,31],"strong",{},"Encode separation of duties, not just roles."," Approvers must belong to the entry's location, a second approval from the same location is blocked unless explicitly permitted, and entries are approved only once a configurable threshold is met.",[26,34,35,38],{},[29,36,37],{},"Sync from the edge, safely."," A connector at each site batches new entries, retries after failures and marks entries as sent only once the central ledger has them.",[26,40,41,44],{},[29,42,43],{},"Resume, don't replay."," The central ledger consumes an event stream and resumes from the last ingested transaction after any interruption.",[26,46,47,50],{},[29,48,49],{},"Make the state visible."," Dashboards update live as entries move through verification.",[10,52,54],{"id":53},"implementation","Implementation",[23,56,57,60,63,66,69],{},[26,58,59],{},"Modules for transfers, couriers, locations, check-offs with reconciliation, petty cash, encashments, overages and balances.",[26,61,62],{},"A verification queue for unverified entries with send-for-approval and approve actions, plus approver notifications.",[26,64,65],{},"An activity audit log covering every operation.",[26,67,68],{},"Reporting with CSV export and search.",[26,70,71],{},"A branch connector service and scheduled maintenance tasks.",[10,73,75],{"id":74},"outcome","Outcome",[15,77,78],{},"Cash movements across locations are recorded in one place, approvals are segregated by location and every action is auditable. Branch data keeps flowing through connectivity problems instead of being lost or double-sent.",[10,80,82],{"id":81},"technical-perspective","Technical perspective",[15,84,85],{},"The interesting constraints weren't technical scale; they were organizational. Approval rules had to model who is allowed to check whom, and multi-site sync had to tolerate days offline without losing or duplicating a single entry.",{"title":87,"searchDepth":88,"depth":88,"links":89},"",3,[90,92,93,94,95],{"id":12,"depth":91,"text":13},2,{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"A payments business operating many branch and agent locations","A central cash ledger with location-scoped approvals, a full audit trail and branch synchronization that survives unreliable connections.","ledger","md","client",{},true,5,"Cash movements across locations land in one central ledger, with separation of duties enforced in software and every action audited.","\u002Fcase-studies\u002Foperational-integrity-for-cash-ledgers","modernize",null,"Treasury operations",{"title":5,"description":97},[111,112],"Custom Software Development","Systems Integration","case-studies\u002Foperational-integrity-for-cash-ledgers",[115,116,117,118,119,120],"Java","Play Framework","Apache Kafka","Akka Streams","WebSockets","SQL Server","2019 – 2026","6UJm4y7VnqtMKhSrk8yjPM8lOXbVH3oOrb4CzNZuxNU",[124,220,318,409,499,599],{"id":125,"title":126,"body":127,"client":198,"description":199,"diagram":200,"extension":99,"kind":100,"meta":201,"navigation":102,"order":202,"outcome":203,"path":204,"pillar":205,"productUrl":107,"sector":206,"seo":207,"services":208,"status":107,"stem":210,"technologies":211,"years":218,"__hash__":219},"caseStudies\u002Fcase-studies\u002Fconnecting-legacy-accounting-to-modern-commerce.md","Connecting Legacy Accounting to Modern Commerce",{"type":7,"value":128,"toc":191},[129,131,134,136,162,164,181,183,186,188],[10,130,13],{"id":12},[15,132,133],{},"The business ran on QuickBooks Desktop. Thousands of parts existed only inside an on-premises company file: no categories, no images, no web presence. Customers search for parts the way they talk, with misspellings and partial part numbers, and every web order had to land back in QuickBooks as a sales order without anyone typing it in twice.",[10,135,21],{"id":20},[23,137,138,144,150,156],{},[26,139,140,143],{},[29,141,142],{},"Use the integration QuickBooks Desktop actually supports."," The QuickBooks Web Connector polls a SOAP service we built and exchanges qbXML. Large item queries are paged with iterators so a sync never tries to swallow the whole catalog at once.",[26,145,146,149],{},[29,147,148],{},"Let AI help, with guardrails."," A locally hosted language model proposes a category, subcategory, vehicle type and tags for each item, with a confidence score. Low-confidence results are flagged for a person to review instead of being trusted blindly.",[26,151,152,155],{},[29,153,154],{},"Protect the sync from the model."," Concurrency limits, adaptive timeouts, a circuit breaker and exponential back-off mean a slow or unavailable model degrades categorization, not order flow.",[26,157,158,161],{},[29,159,160],{},"Search for intent, not exact strings."," Fuzzy matching handles typos and part numbers; vector search over local embeddings handles meaning.",[10,163,54],{"id":53},[23,165,166,169,172,175,178],{},[26,167,168],{},"A Web Connector SOAP service with session handling and qbXML models for items, inventory, customers and sales orders.",[26,170,171],{},"Two-way order flow: web orders are written to QuickBooks as sales orders, matched by reference number and marked as web-originated.",[26,173,174],{},"A queued, batched categorization pipeline with confidence scoring and review flags.",[26,176,177],{},"Hybrid search (fuzzy + semantic) and a retrieval-augmented assistant that knows stock levels and hands off to customer service when it can't help.",[26,179,180],{},"An image pipeline with validation, de-duplication by content hash and a blocklist.",[10,182,75],{"id":74},[15,184,185],{},"The accounting catalog became a categorized storefront that tolerates the way customers actually type (\"transmision\", \"alernator\"). Orders reach QuickBooks Desktop on the Web Connector's normal sync cycle, with no re-keying.",[10,187,82],{"id":81},[15,189,190],{},"The Web Connector is a polling protocol driven from the customer's own machine, so sessions, iterators and pending requests must survive between polls. Putting a language model anywhere near that loop meant designing for the model being slow or absent, so the business never waits on AI to take an order.",{"title":87,"searchDepth":88,"depth":88,"links":192},[193,194,195,196,197],{"id":12,"depth":91,"text":13},{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"A regional distributor of truck and industrial parts","How we turned an on-premises QuickBooks Desktop catalog into a searchable web storefront, with orders flowing back into accounting automatically and AI categorization that knows when to ask for help.","qbwc",{},1,"Thousands of accounting-only items became a categorized, typo-tolerant storefront, and web orders now reach QuickBooks Desktop without re-keying.","\u002Fcase-studies\u002Fconnecting-legacy-accounting-to-modern-commerce","connect","Distribution",{"title":126,"description":199},[112,209,111],"AI & Automation","case-studies\u002Fconnecting-legacy-accounting-to-modern-commerce",[212,213,214,115,116,215,216,217],"QuickBooks Desktop","QuickBooks Web Connector","qbXML \u002F SOAP","PostgreSQL","pgvector","Local LLM","2025 – present","MYuTC9Mh1tniQdLqAxYG3AbT3b3bgcSDov-pPzwVcBY",{"id":221,"title":222,"body":223,"client":299,"description":300,"diagram":301,"extension":99,"kind":100,"meta":302,"navigation":102,"order":91,"outcome":303,"path":304,"pillar":305,"productUrl":107,"sector":306,"seo":307,"services":308,"status":107,"stem":311,"technologies":312,"years":316,"__hash__":317},"caseStudies\u002Fcase-studies\u002Freliable-payment-and-fulfillment-workflows.md","Engineering Reliable Payment & Fulfillment Workflows",{"type":7,"value":224,"toc":292},[225,227,230,232,258,260,277,279,282,284],[10,226,13],{"id":12},[15,228,229],{},"3D Secure 2 sends its result back through the cardholder's browser, which is something an attacker controls. A forged or replayed callback, or two requests racing each other, could mark an order paid or fulfil it twice. For gift cards that's unrecoverable: once a redeemable code is delivered, it's cash.",[10,231,21],{"id":20},[23,233,234,240,246,252],{},[26,235,236,239],{},[29,237,238],{},"Treat the browser as advisory."," Only the server-to-server payment response is accepted as proof of payment.",[26,241,242,245],{},[29,243,244],{},"Bind the response to the transaction."," It must be approved and match the transaction identifier, the amount (compared as fixed-point, never floating-point) and the ISO 4217 currency. Anything else fails closed with a machine-readable reason.",[26,247,248,251],{},[29,249,250],{},"Let the database pick one winner."," Every state change is a single conditional update, so exactly one request can move a transaction forward across threads and instances.",[26,253,254,257],{},[29,255,256],{},"Check again before acting."," Fulfillment re-reads payment status from the database, and a configurable kill switch holds paid gift cards without stopping checkout.",[10,259,54],{"id":53},[23,261,262,265,268,271,274],{},[26,263,264],{},"An explicit transaction state machine: initiated → verifying → pending → completed \u002F failed \u002F expired.",[26,266,267],{},"A verification layer for payment responses and atomic compare-and-set state transitions.",[26,269,270],{},"Hardened 3DS2 callback handling: first write wins, the amount never comes from the browser, and a transaction can only complete through the flow that created it.",[26,272,273],{},"A fulfillment guard and fail-closed issuance switch; provider payloads containing redeemable links are never logged.",[26,275,276],{},"Failure tracking, blocklists and background tasks that expire abandoned payments.",[10,278,75],{"id":74},[15,280,281],{},"Forged, replayed and concurrent completions cannot produce a payment or a fulfillment. Operations can pause gift card issuance instantly while customers keep paying bills and shopping. The changes shipped as a single audited containment release.",[10,283,82],{"id":81},[15,285,286,287,291],{},"The weakness wasn't a missing feature; it was trust in data that only ",[288,289,290],"em",{},"looked"," authoritative, combined with read-then-write races. The fix had to be retrofitted into a live checkout serving several flows (shop, bills, reservations) without breaking any of them.",{"title":87,"searchDepth":88,"depth":88,"links":293},[294,295,296,297,298],{"id":12,"depth":91,"text":13},{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"A regional consumer financial-services platform","Hardening a live card checkout so that forged, replayed or concurrent 3D Secure callbacks can never mark an order paid — or deliver a gift card twice.","payments",{},"Replayed, forged and concurrent completions cannot produce a payment or a fulfillment, and gift card issuance can be frozen without stopping checkout.","\u002Fcase-studies\u002Freliable-payment-and-fulfillment-workflows","secure-scale","Financial services",{"title":222,"description":300},[309,310],"Payments & Fintech","Performance \u002F Production Engineering","case-studies\u002Freliable-payment-and-fulfillment-workflows",[313,314,115,116,120,315],"3D Secure 2","Card payment gateway API","Akka","2020 – present","ERgU-FeJ0P2ENhXQKCe4cmDHHQGJuYVHP9waedu7J9c",{"id":319,"title":320,"body":321,"client":299,"description":392,"diagram":393,"extension":99,"kind":100,"meta":394,"navigation":102,"order":88,"outcome":395,"path":396,"pillar":397,"productUrl":107,"sector":398,"seo":399,"services":400,"status":107,"stem":403,"technologies":404,"years":218,"__hash__":408},"caseStudies\u002Fcase-studies\u002Fbuilding-a-multi-vendor-marketplace.md","Adding a Multi-Vendor Marketplace to an Existing Platform",{"type":7,"value":322,"toc":385},[323,325,328,330,356,358,375,377,380,382],[10,324,13],{"id":12},[15,326,327],{},"The platform already owned customer accounts, carts, card payments and gift cards. It needed multi-seller catalogs and inventory — but replacing its core with an off-the-shelf commerce product would have meant migrating everything that already worked. And stock had to stay correct even when one side of the integration was briefly unreachable.",[10,329,21],{"id":20},[23,331,332,338,344,350],{},[26,333,334,337],{},[29,335,336],{},"Keep one system of record."," The existing application remains the \"marketplace brain\" for sellers, carts, orders and payments. A headless commerce engine is used purely as an internal catalog and stock service, reachable only server-to-server.",[26,339,340,343],{},[29,341,342],{},"Isolate sellers structurally."," Each seller gets its own channel and stock location.",[26,345,346,349],{},[29,347,348],{},"Make checkout predictable."," Price and availability are snapshotted into the cart, so totals don't shift mid-checkout.",[26,351,352,355],{},[29,353,354],{},"Decouple stock from payment."," Stock is deducted after payment through queued jobs, so the commerce engine never needs to know about payments.",[10,357,54],{"id":53},[23,359,360,363,366,369,372],{},[26,361,362],{},"A GraphQL client for the commerce engine's catalog and stock operations.",[26,364,365],{},"A seller lifecycle: application → admin approval (provisioning a channel and stock location) → suspension with recorded reason → reactivation, plus listing and profile review.",[26,367,368],{},"A stock-sync worker that groups adjustments per seller, retries with exponential back-off and surfaces failures in an admin queue with manual retry.",[26,370,371],{},"Mixed carts that split marketplace and gift card items over the existing card payment.",[26,373,374],{},"Seller payouts, statements, charges, pickup locations and return workflows across buyer, seller and admin views.",[10,376,75],{"id":74},[15,378,379],{},"Sellers are onboarded, moderated and paid inside the platform customers already use. Inventory reconciles across transient failures instead of silently drifting.",[10,381,82],{"id":81},[15,383,384],{},"Splitting ownership is the hard part: orders and payments live in one system, stock in another. That makes the integration eventually consistent by nature, so retries, idempotency and failures an operator can see and act on are design requirements, not afterthoughts.",{"title":87,"searchDepth":88,"depth":88,"links":386},[387,388,389,390,391],{"id":12,"depth":91,"text":13},{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"Bringing third-party sellers, catalogs and stock into a live financial-services platform — without surrendering the system of record to a commerce engine.","marketplace",{},"Sellers can be onboarded, moderated and paid inside the existing platform, and stock reconciles even when the commerce engine is briefly unavailable.","\u002Fcase-studies\u002Fbuilding-a-multi-vendor-marketplace","build","Commerce",{"title":320,"description":392},[401,112,402],"Marketplace \u002F Commerce Platform","Architecture & Technical Consulting","case-studies\u002Fbuilding-a-multi-vendor-marketplace",[405,406,115,116,120,407],"Vendure (headless commerce)","GraphQL","Background workers","31vt29yx0lIf_4QdBeYynL10Rnr-9e8lMRamQeE23u0",{"id":410,"title":411,"body":412,"client":480,"description":481,"diagram":482,"extension":99,"kind":100,"meta":483,"navigation":102,"order":484,"outcome":485,"path":486,"pillar":205,"productUrl":107,"sector":487,"seo":488,"services":489,"status":107,"stem":490,"technologies":491,"years":497,"__hash__":498},"caseStudies\u002Fcase-studies\u002Fbill-payment-and-remittance-api.md","One API for Many Billers",{"type":7,"value":413,"toc":473},[414,416,419,421,447,449,463,465,468,470],[10,415,13],{"id":12},[15,417,418],{},"Every biller spoke a different protocol — REST, SOAP or file exchange — with its own reference formats, settlement rules and security requirements. Partners needed one consistent way to make payments, payouts, refunds and top-ups. Cash-in and cash-out at agent locations had to be impossible to brute-force.",[10,420,21],{"id":20},[23,422,423,429,435,441],{},[26,424,425,428],{},[29,426,427],{},"Normalize the model, not just the transport."," One documented API exposes payments, payouts, refunds, recharges, fees, commissions and exchange rates consistently, regardless of which biller sits behind it.",[26,430,431,434],{},[29,432,433],{},"Meet each partner's security bar."," Mutual TLS where required, and signed, encrypted messages (JWS\u002FJWE) for partners that demand message-level security.",[26,436,437,440],{},[29,438,439],{},"Design cash operations to resist guessing."," One-time codes are stored only as hashes, compared in constant time, expire, and are bound to the account, biller and transaction type. Attempts are limited, with time-boxed lockouts.",[26,442,443,446],{},[29,444,445],{},"Reject duplicates at the door."," Repeated payment and payout requests are detected per client, biller and account.",[10,448,54],{"id":53},[23,450,451,454,457,460],{},[26,452,453],{},"Partner endpoints for payments, payouts, refunds, top-ups, fees, commissions, promotions, accounts, billers and webhooks.",[26,455,456],{},"Biller adapters for REST and SOAP services, including a WS-Security SOAP integration and an mTLS client.",[26,458,459],{},"A cash-in \u002F cash-out service with code generation, account validation, lockouts, scheduled expiry and partner webhook notifications.",[26,461,462],{},"Event publishing to Kafka, caching, and background processing for biller master files.",[10,464,75],{"id":74},[15,466,467],{},"Partners integrate once and reach many billers. Agent cash operations are protected by single-use, expiring codes and bounded attempts.",[10,469,82],{"id":81},[15,471,472],{},"Each integration brings its own protocol, cryptography and failure semantics. Moving money means idempotency and auditability have to hold even when a downstream biller times out halfway through a request.",{"title":87,"searchDepth":88,"depth":88,"links":474},[475,476,477,478,479],{"id":12,"depth":91,"text":13},{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"A regional payments middleware business","A partner-facing payments API that puts utilities, mobile carriers, top-up providers and a mobile-money partner behind one consistent, secure interface.","biller",{},4,"Many heterogeneous billers sit behind a single partner API, and agent cash operations use single-use, expiring codes with bounded attempts.","\u002Fcase-studies\u002Fbill-payment-and-remittance-api","Payments",{"title":411,"description":481},[309,112],"case-studies\u002Fbill-payment-and-remittance-api",[492,493,494,495,115,116,117,496,120],"REST","SOAP \u002F WS-Security","mTLS","JWE \u002F JWS","Redis","2021 – 2026","_vQLE8zFIeqS7AEWedylBbhCDIphm6Wl7J-uwmsvnGo",{"id":500,"title":501,"body":502,"client":576,"description":577,"diagram":578,"extension":99,"kind":579,"meta":580,"navigation":102,"order":581,"outcome":582,"path":583,"pillar":397,"productUrl":584,"sector":585,"seo":586,"services":587,"status":588,"stem":589,"technologies":590,"years":218,"__hash__":598},"caseStudies\u002Fcase-studies\u002Fbuilding-invoiceur.md","Building and Launching Invoiceur",{"type":7,"value":503,"toc":569},[504,506,509,511,537,539,559,561,564,566],[10,505,13],{"id":12},[15,507,508],{},"Independent professionals want polished invoices without adopting accounting software — and many don't want their client list living on someone else's server. Adding AI to a product that handles money introduces a specific risk: a model that invents a client, a price or a total.",[10,510,21],{"id":20},[23,512,513,519,525,531],{},[26,514,515,518],{},[29,516,517],{},"Offline-first, no account."," Data lives on the customer's devices. Optional sync uses the customer's own private iCloud database.",[26,520,521,524],{},[29,522,523],{},"AI extracts; code calculates."," Apple Intelligence runs on-device and only extracts what the customer described. Amounts, due dates, client matching and totals are handled by deterministic Invoiceur code.",[26,526,527,530],{},[29,528,529],{},"Ground every draft."," Names and numbers the customer didn't say are flagged, ambiguous clients go to a review screen, and output is always a draft. Nothing is sent automatically.",[26,532,533,536],{},[29,534,535],{},"Claims follow evidence."," Marketing is limited to features that pass verification, tracked in a claims register.",[10,538,54],{"id":53},[23,540,541,544,547,550,553],{},[26,542,543],{},"Invoice creation and editing with currency-correct totals, per-invoice currency and unique numbering.",[26,545,546],{},"Multiple business profiles with separate numbering, currency and branding; client management; full and partial payment tracking; overdue status.",[26,548,549],{},"An insights dashboard, line-item suggestions from invoice history, and three PDF layouts that print payments and balance due.",[26,551,552],{},"Keyboard-first workflows on Mac and iPad.",[26,554,555,556],{},"\"Describe an invoice in your own words\" drafting, processed on-device. ",[288,557,558],{},"Requires Apple Intelligence on a supported iPhone, iPad or Mac running iOS 26, iPadOS 26 or macOS 26 or later.",[10,560,75],{"id":74},[15,562,563],{},"Invoiceur is available on the App Store for Mac, iPhone and iPad from a single SwiftUI codebase. Its on-device model integration tests pass alongside deterministic test suites for every calculation path.",[10,565,82],{"id":81},[15,567,568],{},"The hard part was letting a language model help without letting it near the arithmetic — and keeping one SwiftData and CloudKit codebase behaving correctly across three platforms. It's the same discipline we bring to client systems: put probabilistic components behind deterministic guarantees.",{"title":87,"searchDepth":88,"depth":88,"links":570},[571,572,573,574,575],{"id":12,"depth":91,"text":13},{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"Nerdla product","Designing, engineering and shipping a native invoicing app for Mac, iPhone and iPad — including on-device AI that is never allowed to touch the money.","invoiceur","product",{},6,"A native, offline-first invoicing app on the App Store for Mac, iPhone and iPad, with AI-assisted drafting that keeps every amount deterministic.","\u002Fcase-studies\u002Fbuilding-invoiceur","https:\u002F\u002Finvoiceur.app","Productivity software",{"title":501,"description":577},[111,209],"Available on the App Store","case-studies\u002Fbuilding-invoiceur",[591,592,593,594,595,596,597],"Swift","SwiftUI","SwiftData","CloudKit","Apple Foundation Models","StoreKit 2","PDFKit","GEqnc3ACx0vkT7r2Y3-LdQH5DHClMYqvgQNxQTpyMdg",{"id":600,"title":601,"body":602,"client":576,"description":670,"diagram":671,"extension":99,"kind":579,"meta":672,"navigation":102,"order":673,"outcome":674,"path":675,"pillar":305,"productUrl":676,"sector":398,"seo":677,"services":678,"status":679,"stem":680,"technologies":681,"years":685,"__hash__":686},"caseStudies\u002Fcase-studies\u002Fbuilding-permint.md","Building Permint's Access Commerce Platform",{"type":7,"value":603,"toc":663},[604,606,609,611,637,639,653,655,658,660],[10,605,13],{"id":12},[15,607,608],{},"Studios, organizers and service businesses sell limited capacity — classes, events, multi-visit passes — and want to be paid directly. Every pass has to be impossible to forge and redeemable exactly once, at the door, on a phone, even when many people buy the last spots at the same moment.",[10,610,21],{"id":20},[23,612,613,619,625,631],{},[26,614,615,618],{},[29,616,617],{},"Merchants get paid directly."," Stripe Connect charges go to each merchant's own account, and an offering can't be published until that account can accept payments.",[26,620,621,624],{},[29,622,623],{},"Reserve before you charge."," Inventory is reserved under row locks before checkout begins, the server sets the price, and the checkout session expires with the reservation.",[26,626,627,630],{},[29,628,629],{},"Fulfil only from verified webhooks."," Signed webhooks are processed exactly once through an event ledger in a single transaction, and a reconciliation job recovers anything missed.",[26,632,633,636],{},[29,634,635],{},"Passes are cryptographically signed."," Each pass is a signed entitlement; redemption is atomic, idempotent and scoped to the merchant. Refunds revoke passes, and disputes suspend them until resolved.",[10,638,54],{"id":53},[23,640,641,644,647,650],{},[26,642,643],{},"Checkout, purchase-lifecycle and reconciliation services, plus a transactional email outbox with retries.",[26,645,646],{},"Strict per-merchant data isolation, CSRF\u002FCSP\u002FHSTS protections, rate limits and production secret enforcement.",[26,648,649],{},"A dependency-free embeddable widget so merchants can sell from their own websites.",[26,651,652],{},"A SwiftUI iOS app for organizers: dashboard, offerings, sales and QR validation that verifies pass signatures.",[10,654,75],{"id":74},[15,656,657],{},"In documented concurrency tests, twelve simultaneous checkouts against a capacity of three produced exactly three sales, ten simultaneous redemptions of one pass produced exactly one, and duplicate webhooks fulfilled exactly once. Permint is preparing for public launch.",[10,659,82],{"id":81},[15,661,662],{},"Almost every hard problem here is about concurrency and retries: reservations, webhook duplication and ordering, simultaneous redemptions. The same guarantees then have to hold across the web dashboard, the embedded widget and the mobile app.",{"title":87,"searchDepth":88,"depth":88,"links":664},[665,666,667,668,669],{"id":12,"depth":91,"text":13},{"id":20,"depth":91,"text":21},{"id":53,"depth":91,"text":54},{"id":74,"depth":91,"text":75},{"id":81,"depth":91,"text":82},"Engineering a platform where businesses sell limited-capacity passes and validate them by QR code — with exactly-once fulfillment and passes that can't be forged.","permint",{},7,"Under concurrency tests, capacity can't be oversold, duplicate webhooks fulfil exactly once and a pass redeems exactly once.","\u002Fcase-studies\u002Fbuilding-permint","https:\u002F\u002Fpermint.app",{"title":601,"description":670},[309,401,111],"Launching soon","case-studies\u002Fbuilding-permint",[682,683,115,116,215,684,591,592],"Stripe Connect","Signed passes (ES256)","Web Components","2026 – present","TW4T1pQBsodUKWffAq-WZYgeOG_WuR_Gzgmv4HzcKt4",1792463091679]