Alexander Urquico

General description

Software engineer working on offline-first mobile applications and the integrations that connect them to an enterprise resource planning system.

The operating environment is the deciding constraint. These applications run in warehouse aisles, retail counters and delivery bays, where network coverage is intermittent and the operator cannot wait for it. Every entry is therefore written to an on-device database first; transmission to the ERP is a separate, deliberate action taken by the operator, and every submission is designed to be safe if repeated.

Responsibility on each system spans database schema, API contract, application architecture, security review and production release, together with the architecture and hand-over documentation held in the repository.

Systems

Each subsection states the operating problem, the design decisions taken, and the reasoning behind them. Endpoint names, host addresses and credentials are withheld; the systems are internal company property.

2.1Inventory management

An offline-first inventory platform deployed to 120 branches and used across warehouse, distribution, audit and retail operations. It reduced the full count-to-posted cycle — counting through to posting in the ERP — from about one week of manual tallying to within two days. Operators scan barcodes to count stock, move it between locations and approve transfers between stores. The role returned at sign-in determines which home screen loads and which workflows exist at all, so a branch clerk and a warehouse picker never encounter each other's tools.

• Barcode counting, with a manual-search fallback that is written to a log. Barcodes are damaged in ordinary use; recording each fallback makes the pattern of unscannable stock visible rather than invisible.
• Receiving, store-to-store transfer, batch picking and transfer approval, with batch and expiry tracking throughout.
• Reporting to PDF and Excel, including variance against configured inventory limits.
• Layering enforced by rule: presentation code never reaches the database directly.

2.2Deposit slip uploader

Closes the interval between a branch depositing cash and the finance department seeing evidence of it. The operator photographs the deposit slip; on-device text recognition reads the bank, reference number, amount and date; the operator confirms the fields rather than typing them. No system preceded it: head office could not verify a deposit until the physical slips reached them. Capture and submission now happen at the branch on the day of deposit, across roughly 240 slips a day.

• Recognition runs wholly on the handset; the photograph is not transmitted anywhere to be interpreted.
• Up to three slips per submission, as a day's takings are frequently banked more than once.
• Images are downscaled and compressed before upload, for branches on constrained connections.
• Server address is configured per device, so branches on differing hosts run one build.

2.3Warehouse transfer

A ground-up replacement for the transfer module of a legacy desktop application, intended for pickers who are on foot in the aisles while the workstation is not. Discovery was carried out before any replacement was proposed: the existing system was audited, its actual behaviour documented, and two defects identified.

1. Over-transfer. A quantity check validated against the requested quantity rather than the remaining quantity. A partially picked line could therefore be picked again, beyond its total.
2. Duplicate documents. The submission path could post twice for one physical movement. On a slow connection, a second tap produced a second stock document.

2.3.1Design decisions

• Writes are made through the ERP's supported service layer, never by direct SQL, so business rules and vendor support remain intact.
• Submissions are written to a staging outbox bearing a submission key; a worker posts each key onward exactly once.
• Reads are served by stored procedures, so listing stock does not consume an ERP licence seat.
• The operator scans once to establish position, then enters the quantity. Scanning every unit is defensible on paper and abandoned by the second hour of a shift.

Authentication is complete end to end against live company data: picker directory, first-use PIN enrolment, sign-in, lockout on repeated failure, and supervisor-gated administration. Picking and submission are implemented against a mock repository behind the same interface, ready for changeover.

Operator interface plates

Screen sequences for each system, reconstructed from the shipping interfaces. Advance through a sequence with the controls beneath the description.

Capability matrix

Ordered by depth of production use rather than by familiarity.

Engineering practice

5.1Read the system before rewriting it

What already exists is audited, and its actual behaviour written down, before any replacement is proposed. On occasion the honest finding is that a small number of targeted corrections is preferable to a new codebase, and recording that finding is worth more than winning a larger project.

5.2Design for the failure case

Intermittent networks, repeated taps and half-finished work are the ordinary condition in the field, not the exception. Local-first writes, staging outboxes and idempotent submission cost considerably less than reconciling corrupted data afterwards.

5.3Leave it serviceable

Each system carries an architecture document, an endpoint contract and a current status file in its repository, sufficient for another engineer to continue the work without a briefing.

Service information

Open to software engineering positions across mobile and backend work. Available to discuss any system in this document in detail, including the parts that did not work at the first attempt.

Appendix A — Revision history