I modernise the systems businesses can’t afford to break.

Replacing Dataverse without losing anyone’s access

The first project I took on at Linfox was redesigning the customer portal, starting with a new authorisation model. I rebuilt authentication and authorisation around PostgreSQL on AWS RDS. Every existing user had to keep the same sign-in and the same access to customer records on the day we switched.

• 10,000+ records migrated with zero data loss and no change to how users sign in.
• Sign-in over 50% faster on average for 3,000+ users after removing the intermediate API layer. Sign-in API calls dropped from about 7–8 seconds to 3–4.
• Users can be set up directly in the portal, with no matching record needed in Dataverse.

Orders that go from the portal straight into the TMS

The other half of the redesign: customers create an order in the portal and it is created in Blue Yonder, the transport management system. I worked with the portal team on the ordering interface, the status that comes back once the order exists, and what customers see when it fails.

1. 1

   Customer creates the order in the portal

2. 2

   Portal validates and submits it

3. 3

   Integration layer forwards itBuilt and run by another team.

4. 4

   Order created in Blue YonderStatus and any errors shown back in the portal.

• Ordering interface. Order creation in the portal, with request payloads validated by Zod before they leave it.
• Status back in the portal. Once Blue Yonder has the order, its status shows where the customer created it.
• Failures explained. When an order is rejected downstream, the portal shows why and what to change.

An order assistant that explains failures instead of guessing

I’m prototyping an assistant for the customer portal that drafts new orders from a user’s history and explains why an order failed and how to fix it.

• Data on demand. A Lambda function queries order data when it’s needed and passes it to a Snowflake Cortex agent, avoiding the cost of syncing everything into Snowflake.
• Same access rules as the portal. The assistant reuses the existing visibility logic, so it can only see orders the user can already see.
• Predictable answers. Known error types map to pre-written explanations and fixes, rather than asking the model to interpret raw system errors.

An internal tool for master data changes

Updating service IDs and locations used to take a developer up to an hour per request. I built a role-restricted internal tool so the development team can make the change in under five minutes.

Automating order handoff to a shipping provider

I built and run a TypeScript service for a small cross-border e-commerce business. It turns Shopify orders into YunExpress shipments, with a dashboard for the people packing them. It processes 100+ orders a month.

1. 1

   Pick up new Shopify ordersOn a schedule, from a saved cursor.

2. 2

   Choose the route and build customs dataFrom validated rules, not code.

3. 3

   Create the YunExpress waybillSigned API request.

4. 4

   Operator reviews and marks it fulfilledDeliberately manual, so a person decides when a customer is told it shipped.

• No duplicate waybills. Manual and scheduled runs once created two waybills for one order. Now the Shopify order name is YunExpress’s customer order number, so YunExpress itself rejects a second submission, on top of per-order state in SQLite.
• Failures wait for a fix, not endless retries. After three attempts an order is parked until someone edits it in Shopify, for example adding a missing phone number, which queues it again automatically.
• Shipping rules as data. Routes are picked by country, state and the checkout shipping method. Customs lines are merged by product category, converted to USD, capped at what the customer paid, and include IOSS for EU orders.