Scope and ownership
I joined as the first engineer, initially handling development on my own. I remain responsible for technical direction, architecture and production delivery, working directly with the business owner to turn commercial rules and operational workflows into software.
I now guide another engineer who develops the staff workspace and customer portal. I clarify requirements, design the architecture, break work into tasks and assign them. I guide implementation, develop core platform capabilities and integrate their contributions with shared accounts, data access and deployment. This includes resolving shared database migration conflicts and keeping application changes compatible across releases. As requirements evolve, I revisit priorities and architecture, assign the next tasks and merge contributions into the platform.
The platform brings together four applications:
| Application | Delivered workflows |
|---|---|
| Storefront | Retail and B2B purchasing, account balances, checkout and fulfilment |
| Administration | Catalog, promotions, settlement, customer accounts and signing requests |
| Staff workspace | Tasks, shared resources, customer records and forms |
| Customer portal | Personal records, forms and account settings |
This case describes the current implementation. Examples and diagrams are abstracted to protect client information.
Transaction correctness
Checkout combines several decisions that must remain consistent under concurrent requests. I implemented ordered product-row locks followed by a fresh availability query, server-side pricing, and guarded balance updates. Unpaid orders act as stock reservations; physical stock changes when payment is finalized.
Balance mutations go through a shared module that updates the wallet and records the movement in one database transaction. Payment, cancellation and expiry use conditional transitions on pending balance reservations, so competing requests cannot independently consume or release the same funds.
The payer and the person placing an order are modelled separately for B2B accounts. This lets purchasing permissions and spending limits coexist with billing to a parent account, while preserving who performed each transaction.
Settlement and reconciliation
I built commission accrual, payout eligibility and refund adjustments as distinct steps. Payout paths claim eligible records inside the same transaction as the balance credit; refund adjustments use the original calculation inputs. This preserves the basis of the amount as rules and transaction states change.
Daily reconciliation independently checks ledger arithmetic, balance continuity, held funds and the related orders, refunds and settlement records. A balance constraint can reject an invalid total, but cannot prove that every business event was recorded. Comparing these records provides a separate way to detect discrepancies.
Shared accounts, restricted data access
The applications share an account system while retaining different access rights. I implemented application permissions alongside separate PostgreSQL roles, restricted grants and row-level security for customer-service data.
Customer queries run with an identity taken from the verified session and scoped to the database transaction. This avoids carrying identity between requests when a connection is reused. Staff views and exports of protected customer records write access-log entries before returning the data.
Integration tests run under restricted database roles to verify both permitted access and denial: one customer cannot read another customer’s records, and an application cannot query unrelated data just because it shares the database.
Electronic document signing
I delivered a signing workflow with versioned templates, configurable fields, expiring signer links and generated PDFs. The system checks the document hash before accepting a signature, serializes competing updates to a signing request, and records consent and completion events in a hash-linked audit trail.
The completed PDF and its document fingerprint provide a reference for later review, connecting the signed content to the recorded workflow.
Operating and testing the platform
Shared TypeScript packages keep transaction rules and validation consistent across the applications. Scheduled jobs record execution history and failures, with database-backed claims to coordinate runs. The test suite includes balance operations, payout guards, access isolation, signing validation and database migrations in disposable PostgreSQL containers.
My responsibility includes these operational controls as well as the customer-facing product: a completed workflow needs a clear outcome, a traceable record and a way to investigate when they disagree.