Delivered work
Eighteen projects I carried out and put into production. Each page tells a real story: the starting context, the technical constraint that made it hard, what I built and how it fitted into what was already there. No client is named, and none should be identifiable.
What you came here to check
People look at delivered work for a simple reason: to check that someone has already built something comparable to what they have in mind. A statement of skill is easy to write; a delivered project comes with its constraints, its trade-offs and the places where the elegant solution had to be dropped. That is the material these pages hold.
So you will find the past here, not promises. Each page describes something that exists, went live and was used. If you would rather know what I can take on today, independently of what I have already built, the expertise section is there for that: it describes skills I can bring to bear, where this one describes deliveries.
How the section is organised
The eighteen projects group by type of work. Commerce and catalogue: rebuild of a fashion shop, multilingual cosmetics shop, multi-supplier B2B catalogue, B2B site in eleven languages, per-customer configurable margins, product personalisation studio. Hospitality and point of sale: order-at-table by QR code, bridge to a cloud till system, menu syncing to delivery platforms.
Automation and feeds: automated PDF quotes, Google Merchant feed for a B2B catalogue, running a Turkish marketplace, a complete Shopify application. Property and media: listing collection, social distribution from a CRM, automated video generation. And booking: appointment booking for an aesthetic clinic, tourist transport reservation.
What a project page contains, and what it does not
Every page follows the same shape: the starting situation, the point that was genuinely hard, the solution chosen and why that one rather than another, then what the result changed in the team's daily work. Technologies are named — platform, language, kind of API — because that is the information that lets you judge.
What you will not find: no company name, no brand, no site address. That is not coyness. A developer who publishes a client list also publishes, without meaning to, a map of their technical dependencies and sometimes of their weaknesses. Projects are therefore described by their nature and their sector, never by their owner.
Nor will you find growth percentages or revenue figures. Measured results belong to the clients, not to me, and I do not publish numbers I could not prove.
For a quick sense of the work
-
Fashion e-commerce rebuild
Taking over an existing shop with its catalogue, its variations and its order history.
-
Multi-supplier B2B catalogue
Aggregating several suppliers' catalogues into a single shop, with availability rules specific to each.
-
Bridge to a cloud till system
Linking online orders to a point of sale till system, in both directions.
-
B2B site in eleven languages
A trade catalogue in eleven languages, with the URL and hreflang handling that comes with it.
Frequently asked questions
Why is no client named?
Were these projects done alone or in a team?
Can I see the code or a demo?
A project close to mine isn't listed, is that a problem?
Which platforms were these built on?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.