Backend Developer | Node.js, TypeScript, Go

Regulated Product Backend - Certified Computation Core (NDA)

About the Project

Backend for a consumer product operating in a regulated market (client under NDA). The service is built around a deterministic computation core: an RNG-driven engine whose outputs must follow a precisely specified statistical distribution, together with the rule and payout tables that evaluate each result. It exposes a transaction API to the operator platform, which owns accounts, sessions and balances. The defining constraint here is compliance rather than load. Before release the computation core must be independently verified and certified by an external regulator: its statistical target has to be reproduced within tolerance across large-scale simulation runs, and the certified binary must remain byte-identical for the lifetime of the certificate, with the regulator able to re-request its hash at any time. Architecture is therefore driven by determinism, auditability and change isolation rather than by throughput.

• GameDev

Responsibilities

I am the only backend developer on this project, alongside a frontend developer and a design team. I started with test infrastructure for existing services - large-scale simulation suites verifying statistical output, plus re-verification of the underlying models - and now build these backends end to end: the computation core, the platform-facing API, and the verification suite. My main architectural contribution solved a certification problem. The regulator certifies a hash of the compiled binary and can re-request it at any time; any change after certification invalidates that hash and forces costly recertification, which in practice froze the whole backend. I split the service into two binaries: a minimal certified binary holding only the computation core, and the main backend binary that owns everything else and drives the certified process over STDIN/STDOUT. The certified artefact stays byte-identical while the rest of the backend evolves freely.

Multi-tenant Customer Support Chat Platform

About the Project

A multi-tenant customer support chat platform, built first for the company's own products and then offered to external companies. It has two sides. The operator side is a full CRM where operators, supervisors and admins work: an incoming dialog queue, active and archived conversations, complete message history for both authenticated users and guests, per-operator and per-queue statistics with charts, and document generation. The client side is an embeddable widget any site can integrate, plus a Telegram channel fronted by an AI bot that answers questions it has been trained on and escalates to a human operator when it cannot. A dialog then enters the queue, an operator claims it and it becomes active, and on resolution it moves to the archive. In production the platform has handled over a thousand concurrent chat clients, with message history in the millions.

• Customer Support

Responsibilities

I worked mainly on the backend, with some frontend work on the Vue.js client. The backend was split between a legacy AdonisJS application and a newer NestJS one, and throughout my time on the project I incrementally migrated functionality from the old stack to the new one while continuing to ship features. Much of the code predated me and had been written fast, so a large share of my work was refactoring and optimising it - caching to take load off the database, rewriting problem areas outright. One heavily used query went from 1.5s to 600ms. I also built the integration with the AI bot, including handoff to a live operator, and a separate Telegram client that ingested manager–customer conversations into the chat database. My main contribution was reworking dialog assignment. Automatic distribution broke once operators moved to remote work: unstable connections meant dialogs went to operators who could not pick them up. I replaced it with a pull-based queue where operators claim dialo

Load Calculator - 3D Cargo Load Planning

About the Project

Load Calculator is a cargo load planning tool on a global freight logistics platform. A shipper enters the goods they need to move - boxes, pallets, pipes, drums, irregular items - with dimensions, weights and constraints, and the service computes how to arrange that cargo across one or more containers as efficiently as possible: maximising space utilisation while respecting size, weight distribution and stacking rules. The result is an exact layout giving the position and orientation of every item, which the front end renders as an interactive 3D visualisation of the packed container. Freight forwarders, shippers and logistics teams use it to work out how many containers a shipment actually needs, and what it will cost, before booking. The product is fundamentally a computational geometry and bin-packing problem, so essentially all backend work here is algorithmic rather than CRUD.

• Logistics
• Transportation
• Supply Chain

Responsibilities

I was one of two backend developers on the product, working with the team lead, alongside two frontend developers and a QA engineer. I implemented new features from the company's product roadmap and optimised existing ones. Because the product is a packing engine, effectively all of that work was algorithmic - geometry, placement strategy, query optimisation - rather than conventional API development. My main piece of work was rewriting pallet placement. The existing implementation was a very large body of code that had become hard to reason about and was slow, and after working through it we decided to reimplement the algorithm from scratch while keeping the original in place as a fallback. This was one of my first features on the project, so I was learning a large and complex codebase and replacing one of its core paths at the same time. Generating a fully loaded pallet container went from roughly 10 minutes to about 1.5 minutes.

Crypto Trading & Payments Ecosystem (NDA)

About the Project

A connected set of cryptocurrency products serving traders and investors (all under NDA): a trading exchange, an instant exchange service, wallets and a payment gateway, sharing accounts, balances and market data between them. The domain constraints shaped the architecture throughout. Balance and transaction data has to stay consistent under concurrent access, money movements must be atomic, and market and portfolio data has to reach the user with very low latency - a trading screen is unusable if reads lag behind. Load was also highly uneven: launches and periods of market activity produced sharp spikes rather than steady traffic, so these systems were built and repeatedly reworked for two things at once - correctness under concurrency, and survival under sudden demand. Much of the engineering effort went into the data layer rather than into the API surface, because that is where both of those constraints are actually decided.

• Fintech
• Cryptocurrency

Responsibilities

I worked on the backend across these products - new features, third-party integrations, bug fixing and tests - and built several of them from scratch before other backend developers joined. I also wrote Telegram bots on Node.js. The main emphasis was PostgreSQL. On several products the business logic lived in stored procedures, with heavy use of triggers and transactions. That was a deliberate decision, not a legacy habit: these products did a very large amount of work over table data and had to return it fast, so keeping the logic next to the data removed round trips and let the database do set-based work in a single pass. The hardest part was releases. Launches brought heavy spikes of users, so I was on call through them - shipping hotfixes, scaling vertically and horizontally, adding indexes, rewriting stored procedures to be lighter, cutting the number and size of table reads, and caching wherever possible.

Bucherer - Enterprise E-Commerce Platform

About the Project

Enterprise e-commerce platform for Bucherer, a Swiss luxury watch and jewellery retailer founded in 1888 with over 100 stores, selling across Europe and the United States. A large multi-team system: catalogue and product data for very high-value goods, checkout, order management, and a long tail of regional requirements - selling the same watch in Switzerland, Germany or the US means different tax rules, payment methods and merchant-configured pricing. The platform was built to sustain Black Friday peaks on the order of 100,000 requests per second, with traffic arriving from several regions at once. Average order value is extremely high and stock is scarce, so a failed or incorrect checkout costs far more than it would in ordinary retail: correctness in payments, tax and pricing mattered more than anything else. Bucherer has since been acquired by Rolex.

• E-commerce
• Retail

Responsibilities

I worked on the backend in a team of 11 - backend, frontend, QA, design and PM - while the platform as a whole was built by several teams in parallel. Over roughly a year I delivered small and medium features, bug fixes and a number of third-party integrations: among them a US sales tax service, so American customers saw the applicable tax on an order before paying, and a system that calculated discounts from merchant-defined rules. I also made occasional frontend changes. My main piece of work was replacing the payment provider. The incumbent shipped breaking updates with no notice, which at this price point is untenable - things quietly broke in production. We moved to Saferpay, which covered every payment method the shop needed, but its Node.js library was immature at the time and had to be extended and partly rewritten against the documentation. I built the new integration and removed the old one without interrupting checkout.

illy - Coffee Subscription Commerce, US Market

About the Project

Direct-to-consumer e-commerce platform for illy, the Italian coffee brand, operating internationally. My work centred on its US subscription business: a customer buys a coffee subscription and receives deliveries on a recurring schedule to their door. Subscription commerce is a different problem from ordinary checkout - the order is not a single event but a recurring one, so the system has to hold the plan and its delivery cadence, generate and dispatch orders on schedule, take payment repeatedly against a stored method, and absorb changes, pauses and cancellations mid-cycle without breaking either billing or fulfilment. The US market adds a further layer, since tax and shipping rules differ by state. This ran on the same enterprise e-commerce stack as the group's other international retail platforms.

• E-commerce
• Retail
• Food And Beverages

Responsibilities

I worked on the backend, in a team of six backend developers; the platform involved other teams that I did not work with directly. Unlike my other work at the agency, this was concentrated on a single large delivery rather than spread across many smaller tickets: implementing the US subscription product on the backend - the subscription model itself and the surrounding functionality built specifically for the American market.

E-Commerce Support & Maintenance - Sanitas Troesch, Prescriptionlab

About the Project

Two European e-commerce products maintained in parallel. Sanitas Troesch is Switzerland's market leader for kitchens and bathrooms, part of Saint-Gobain, selling through showrooms across the country alongside its online channel - a catalogue of large configurable goods with delivery and installation, rather than simple SKUs. Prescriptionlab is a French cosmetics brand with a direct-to-consumer store. Both were mature platforms past their build phase, so the engagement was ongoing support, small feature work and bug fixing across backend and frontend, keeping two live commercial sites healthy rather than delivering new systems. Neither needed full-time attention on its own, so they were staffed as a shared workload - two unrelated codebases and two sets of business rules in the same week.

• E-commerce
• Retail
• Interior Design
• Beauty

Responsibilities

I worked across both products as a fullstack developer, in small teams of three to four. This was support and maintenance rather than a greenfield build: bug fixes, small feature implementation, and handling incoming requests against live commercial sites, where a bad change is immediately visible to customers. Frontend work here was support-level rather than new interface development. The valuable part of this work is operational rather than architectural - holding two unrelated codebases at once, getting oriented quickly in code written by other people, and making small changes safely in systems that were already trading.