Skip to content
Workshop
← All work
Finance, premium servicesJanuary–July 2026Remote contract work through Nearform, with Staff-level responsibility for the mobile app, CRM and back end

Sole owner of the app and CRM for a UK digital bank's premium services

Through Nearform I was the only engineer on the premium-services mobile app, CRM and back end of a UK digital bank. The product team now updates the content of five screens without a developer.

Monument (UK digital bank), via Nearform · official job title: Product Platform Engineer

System diagram

Monument: one owner from the mobile app to the back endSystem diagram. The Expo/React Native mobile app and the Next.js CRM connect to the Fastify back end through an OpenAPI and Zod definition. Contentful supplies the content. The CRM signs in through the bank's own login system. I also built the release pipelines. I was solely responsible for all of it.SOLE OWNERMobile appExpo · React NativeCRMNext.jsBank sign-inOpenAPI + Zod → generated calls+ shared TypeScript packagesBack endFastifyContentfulcontent managementRelease and checksGitHub ActionsEASPlaywrightMaestroRelease pipelines

According to a CoinDesk article from March 2026, the bank whose premium services I worked on had more than 100,000 customers.

CoinDesk, March 2026 ↗ — This public figure is about the company or product, not my personal result.

The situation

Monument renewed the lifestyle services it offers premium customers in its mobile app. The team running those services needed a customer management system (a CRM). The product team wanted to change content without waiting for a new app version.

What made it hard?

I had to rebuild five banking screens on my own. Every change had to stay traceable, and the product team had to be able to work without me.

What was I responsible for?

  • I was the only engineer responsible for the Expo/React Native mobile app, the Next.js CRM, the Fastify back end and the shared TypeScript packages, at Staff level.
  • I generated the code that connects the mobile app and the CRM to the server from OpenAPI and Zod definitions.
  • I set up the Contentful content management system and its permissions, and designed the Intercom workflows.
  • I built the release pipelines and set up the environments.
  • I used AI tools to sharpen the requirements, then checked item by item that every requirement had a test. I reviewed each change separately and checked it with targeted tests.

Key decisions

  • Alternative

    Data shapes described separately in the app and on the server

    Choice

    One Zod definition, with the server calls generated from it

    Consequence

    If the app expects something different from what the server sends, the checks flag it before release.

  • Alternative

    One round of checks

    Choice

    Two separate rounds for login, data handling and data migration

    Consequence

    A release could slip by a day.

  • Alternative

    A separate login for the CRM

    Choice

    The bank's existing access management

    Consequence

    I did not have to write a login of my own.

Results

  • The home screen, chat, discovery, personalisation, the buttons that lead to services, the terms and the content filters can all be updated from the content system, without releasing new code.
  • The mobile app and the CRM receive their data in a fixed, checked format. They do not have to follow the internal structure of the content system.
  • Before each release I checked the changes in a preview and tested that the mobile app and the CRM still worked together. The system does not let conflicting releases start at the same time.

When this matters to you

  • If you want your team to change content or rules themselves, without booking a developer every week, this is how it can work.
  • If you handle regulated or sensitive data, a release you can trace back is a basic requirement.

Links