The problem, the technical challenge and what was built.
A development portfolio should explain how the work functions and what it changed — not rely on visual mockups alone.
A development portfolio should explain how the work functions and what it changed — not rely on visual mockups alone.
A lot of our work is delivered white label, under an agency's brand, so we cannot show screenshots or name the client. What we can do is explain the problem, the technical decisions and what changed as a result — which is the part worth reading anyway.
Each one covers the operational problem the client arrived with, the architecture we chose and why, what was built, and the outcome in their terms rather than ours.
A membership website for payroll professionals, with member benefits and book sales, kept in step with the client’s CRM by a bespoke two-way API integration.
An API-connected membership platform handling publications, events and a two-way CRM sync — thousands of profiles and hundreds of transactions a week.
Bespoke ecommerce for a luxury coffee supplier — one-off purchases and recurring bulk orders, with accounts, history and simplified repeat ordering.
Five separate legacy CMS sites, five databases and five themes, consolidated into a single multilingual multisite CMS platform.
A subscription research platform serving over 3,000 subscribers across 160+ countries, with daily content and recurring monthly payments.
An industrial-scale ordering portal migrated off a legacy platform, with client authentication, advanced search and form-to-CRM integration.
Course booking and online payment for the training arm of a charity that runs an island ambulance service.
A bespoke configuration module built on top of a standard ecommerce platform, so customers can order hand-made furniture built to their own measurements.
A multisite platform serving several regional websites from one build, each with its own content and language.
That is usually the most useful place to start the conversation.