Selected experience

Work grounded in real systems.

The experience behind Hypnoshroom spans long-lived Scala services, independently built web products and the testing and production work needed to keep software useful.

A transparent starting point

Hypnoshroom maybe new. The experience behind it is not.

The examples below describe professional and independently delivered engineering experience. They are not presented as Hypnoshroom client case studies, and no client result is being claimed without evidence or permission.

Selected work

Three areas of applied experience.

The common thread is software that already has users, constraints and consequences when a change goes wrong.

Scala & backend systems

Evolving long-lived Scala services

Professional experience · HMRC domain

Around eight years of experience working with Scala services in an established public-sector domain, where changes need to respect existing behaviour, integrations and operational constraints.

Representative work

Maintaining and extending Scala 2.13 and Play Framework applications
Working with REST APIs, Play JSON, MongoDB and hmrc-mongo
Managing sbt and multi-project builds, dependencies and compiler configuration
Writing unit, integration and acceptance tests around changed behaviour
Investigating live issues through logs, monitoring and production evidence
Considering safe routes from long-lived Scala 2 systems towards Scala 3

What this experience brings

This experience informs a cautious approach to mature systems: understand why the code looks the way it does, protect important behaviour and separate necessary change from optional cleanup.

Modern product development

Taking a web product from idea to production

Independent product engineering

Hands-on experience designing, building and deploying SaaS-style applications as a solo developer, including the product decisions and operational details around the code.

Representative work

Building full-stack applications with TypeScript, Nuxt 3 and Vue
Implementing authentication and account flows with Auth0
Designing database-backed features with Supabase and PostgreSQL
Integrating external and geolocation APIs behind application boundaries
Working through permissions, configuration and environment separation
Deploying to Vercel and considering runtime, load and concurrency behaviour

What this experience brings

The useful experience is not only assembling a technology stack. It is making trade-offs across the interface, server, data model, authentication and deployment path while keeping the product small enough to own.

Quality & production delivery

Keeping changes reviewable and operable

Applied across backend and product work

Testing, delivery and production support are treated as part of engineering rather than activities added after implementation is complete.

Representative work

Using ScalaTest, JUnit, Mockito, Cucumber and Selenium where appropriate
Balancing focused unit tests with integration and acceptance evidence
Working with Git, GitHub, Jenkins, CI/CD pipelines and Docker
Debugging live behaviour using Grafana, Kibana, Splunk and CloudWatch
Improving code through bounded refactoring and dependency cleanup
Recording decisions and leaving work understandable for the team taking it forward

What this experience brings

The aim is pragmatic confidence: feedback that helps engineers make decisions, releases that can be understood and software that does not depend on one person retaining all of the context.

Continuous learning

Staying current. Adopt deliberately.

Software keeps moving. Languages, frameworks, build tools and delivery platforms change, and staying useful means keeping up with the parts of that change that affect real systems.

That does not mean replacing working technology whenever something new appears. New approaches are read about, tested and weighed against support, maintainability, migration cost and the people who will own the result.

Follow the ecosystems: Keep track of relevant language releases, framework direction, dependency support and changing production practices.
Learn by building: Use small experiments and independently built products to understand how a tool behaves beyond its introductory example.
Modernise with a reason: Adopt newer technology when it improves support, delivery, reliability or ownership—not simply because it is fashionable.

In an engagement

Experience that shortens the path to useful work.

Previous experience does not remove the need to understand a new system. It helps identify the right questions, recognise familiar risks and avoid treating every problem as if it starts from a blank page.

Established systems are familiar territory: The work can begin with an existing codebase, incomplete documentation and constraints that cannot simply be redesigned away.
Decisions are followed across boundaries: Types, application logic, APIs, persistence, tests and production behaviour are considered together when the problem crosses them.
Advice stays close to implementation: Recommendations are grounded in buildable, testable software and the realities of how a team will deliver and own the next change.

Explore ways to work together View technical expertise

Start a conversation

Something difficult holding the product back?

A feature that needs shipping, an ageing service that needs attention, or a deployment that has become harder than the code. Talk to us about your problems.

Discuss your project