Address
Utrecht, Veenendaal

Work Hours
Monday to Friday: 9am to 5pm
Weekend: 10am to 5pm

Six years at Qfact, from 2018 to 2024, on one microservices SaaS platform used daily by thousands of people for complex analysis. I moved from building it to leading four developers on it.

  • ClientQfact, a SaaS platform for complex analysis
  • PeriodSix years at Qfact, 2018 to 2024
  • RoleSoftware engineer, then lead
  • TeamFour developers as direct reports
  • ScaleThousands of daily users
  • Led four developers as direct reports, and hired two people who stayed long term.
  • Introduced measurable sprint velocity where there was none, and owned CI/CD, test automation, demos and the roadmap.
  • Closed off whole classes of user facing bugs with targeted fixes, and they did not come back.

Context

Qfact sells a SaaS platform for complex analysis work. The organisations on it depend on what it tells them, and some of them answer to a regulator for it. I joined as an engineer and left as the lead, which means I was there for the whole arc: the architecture decisions, the consequences of them, and the team that lived with both.

The challenge

A platform that runs for years does not fail loudly. It gets slower, its services grow responsibilities that belong elsewhere, and delivery gets less predictable without anybody being able to say when that started. At the same time it has to stay up and keep taking feature work, because thousands of people are inside it while you are changing it.

What I did

  • Built and owned services across the landscape, in Node.js, TypeScript and Python, from the data layer through the APIs to the Vue.js application on top. Full stack, on a system I was accountable for end to end.
  • Led four developers as direct reports, and hired two people who are still there. Leading shows up years later, in who stayed.
  • Introduced measurable sprint velocity, where there was none, which gave the team a real basis for what fits in a sprint and gave stakeholders a date they could believe.
  • Owned delivery reliability, through test automation and CI/CD, plus the demos, the roadmap and the sprint leadership around them.
  • Led design sessions, and kept the architecture decisions explicit, so choices were made once, with the reasoning visible, rather than settled repeatedly in review.
  • Closed off recurring bug classes, with targeted fixes, and they did not come back.

The outcome

  • A platform thousands of people rely on daily, kept scaling and kept shipping.
  • Four developers led, two long term hires, and a team with a delivery rhythm it could measure.
  • Bugs that had been patched over and over closed at the cause instead.

Technologies used

  • Node.js: Core platform services.
  • TypeScript: The language across those services.
  • Python: The data analysis work.
  • Microservices: The architecture of the whole platform.
  • Event sourcing: Business logic persistence and its audit trail.
  • GraphQL: The API layer over the platform.
  • OAuth 2.0: Authorisation between the platform services and the clients calling into them.
  • MySQL: Relational data and reporting.
  • MongoDB: Document data and read models.
  • Cassandra: The event log.
  • Elasticsearch: Search across platform content.
  • RabbitMQ: Messaging between services.
  • Docker: Service packaging.
  • Kubernetes: Orchestration of the service landscape.
  • CI/CD: The delivery pipelines I owned.
  • Jest: Automated test coverage.
  • Vue.js: The application layer over the platform.
  • SCRUM: How the team worked, and what I led.

Six years on one system teaches you which decisions age well, and I would happily bring that to a platform you already have.