Software Architect & Tech Lead · PostNL Digital Lab · 2022–2025
Fast Checkout — product architecture and technical leadership at PostNL
Three years inside PostNL's Digital Lab turning prototypes and ambiguous product requirements into a transactional checkout product connecting e-commerce platforms, shipping and payments — as architect, tech lead and hands-on engineer.
Fast Checkout is a product born inside PostNL's Digital Lab to reduce friction in e-commerce checkout: connecting webshops, shipping and payment into a single accelerated flow.
I joined through Capgemini as Software Architect and Tech Lead, and spent three years turning prototypes and business requirements into a scalable transactional product. This case is deliberately limited by confidentiality: the way of working and the shape of the problems are mine to tell — the product internals are not.
Context #s1
A Digital Lab exists to answer a hard question: can this promising prototype become a real product? Fast Checkout started exactly there — a validated idea for accelerating checkout, shipping and payment flows on major e-commerce platforms, and a long list of open questions about integrations, security, scale and operability.
The work was not to implement a fixed specification. It was to co-discover the product with product managers, designers and client stakeholders while building the platform underneath it — which is why this project shaped how I work with ambiguity today.
| Duration | Aug 2022 – Dec 2025 (three and a half years) |
| Role | Software Architect and Tech Lead, hands-on |
| Team | 5 people reporting to me |
| Starting point | Digital Lab prototypes and business requirements |
| End point | A transactional product running in production on AWS |
| Integrations | E-commerce platforms and payment providers |
| Stakeholders | Product, design, frontend, plugins, platform architecture, client decision-makers and third parties |
My role #s2
- Software Architect — owned the high-level design and its evolution: boundaries, data, integrations, security and infrastructure.
- Tech Lead — led a team of 5: mentoring, roadmap, prioritisation and quality gates.
- Hands-on engineer — implementation and reviews stayed part of the job; decisions were validated in code, not in slides.
- Interlocutor — direct engagement with product, client stakeholders, frontend and plugin teams, platform architecture and third parties.
Problems addressed #s3
- Ambiguous product requirements — translating evolving business hypotheses into stable system boundaries and technical flows.
- Platform integrations — connecting different e-commerce platforms, each with its own plugin model and constraints.
- Payment integrations — wiring payment providers into flows where reliability is non-negotiable.
- Transactional flows — orders, shipping and payment steps that must not be lost or duplicated under failure.
- Security and isolation — protecting flows that touch money and personal data across organisational boundaries.
- Cloud architecture — an AWS platform (ECS, queues, API Gateway, RDS) defined as code with Terraform, built for operability and progressive scaling.
- Multi-team coordination — keeping product, frontend, backend, plugin and platform work aligned across releases.
Decisions that reduced risk #s4
In a product that touches money, most of the value of the architecture is not in what it makes possible, but in what it stops from going wrong. These are the decisions that removed the most risk and complexity.
- Infrastructure as code with Terraform — reproducible environments instead of hand-tuned config that drifts. A new environment stops being a project and becomes an
apply. - Queue-based flows to decouple the transactional steps: failures stay isolated and retryable instead of taking down the whole operation.
- TypeScript end to end — one language across frontend, backend and integrations, with shared contracts rather than hand-duplicated ones at each end.
- End-to-end traceability from day one: when something fails inside a payment flow, the question is not whether you can reconstruct what happened, but how long it takes.
- Explicit boundaries per integration — every e-commerce platform and every payment provider has its own rules and its own failure modes, and isolating them keeps one platform's quirk from becoming a special case scattered across the system.
Technologies #s5
TypeScript end to end: Next.js on the frontend, NestJS services on the backend, PostgreSQL with Prisma for data, and AWS infrastructure (ECS Fargate, SQS, API Gateway, Cognito, RDS) defined with Terraform. CI/CD ran on Azure DevOps with end-to-end traceability, autoscaling and queue-based workflows.
What this case demonstrates #s6
- Translating commercial and product needs into product capabilities and architecture.
- End-to-end ownership: from requirement conversations to code running in production.
- Technical leadership that stays hands-on instead of drifting into diagrams.
- Complex integrations delivered across several organisations and teams.
- Product decisions with architectural impact — and architectural decisions with product impact.
- The ability to operate inside a large organisation without losing delivery speed.