00 / 05

Cover

Liam Ramsden — Drawing Set

LR.

Sheet 00 — Cover

Liam Ramsden

Web Developer · Mobile Engineer

Front-end and back-end web by day. Alongside it, I design, build and ship native iOS/Android apps end-to-end — including a production field-operations platform used daily by trades teams on site.

Manchester, UK — 53.4808° N, 2.2426° W

View Fieldwork Get In Touch
Scroll

Sheet 01 — Profile

Web developer by day. The rest of the time, I'm shipping native mobile apps end-to-end — architecture, sync logic, and the App Store submission itself.

Day to day I build front-end and back-end web products. Alongside that I've been the sole iOS/Android developer on a production field-operations platform for the construction trade — no hand-off between "the mobile team" and "the backend team," just me designing the client-side architecture, writing the sync logic that keeps a site engineer's phone correct when the signal drops, and shipping the result to both app stores myself. That app is live and in daily use. I'm currently building a couple more mobile apps alongside the day job.

Based
Manchester, UK
Day job
Web Development · Front & Back-end
Also shipping
Native iOS & Android
Available for
Full-time roles & freelance builds

Sheet 02 — Capabilities

Legend — no percentages, just what each toolset is building.

Front-end & Back-end Web

The day job.

  • HTML5
  • CSS3
  • JavaScript
  • Python
  • MySQL
  • C#

Mobile — Production

A live field-operations platform, plus more apps in progress.

  • Swift
  • SwiftUI
  • UIKit
  • Core Data
  • Kotlin
  • Android

Systems & Sync

The unglamorous part that has to be right.

  • Offline-first architecture
  • Background sync coordination
  • Concurrency debugging

Control Systems

Earlier production experience — industrial telecoms & data-centre cooling units.

  • Logic Gates
  • PLC Logic

Live from the field

A sync gate, in miniature

Two sync coordinators — one triggered from the app in the foreground, one running as a background task — used to write to the same local database at once. It only ever showed up on devices with real data to collide over. The fix: a shared gate both coordinators pass through before touching the store, so one waits its turn instead of racing. The full story is in the Fieldwork case study below — this is the same idea, animated, with far fewer moving parts.

Foreground sync Background sync Shared gate

Sheet 03 — Fieldwork

Selected builds, in the field.

A

Case Study — Anonymised, NDA · In production

Field-operations platform

iOS + Android · construction & trades industry · sole developer, end to end

  • 500k+records reconciled per full sync
  • 2platforms, one architecture
  • 0separate mobile team — solo, end to end

Problem

Two independent sync processes — one triggered from the app in the foreground, one running as a background task — could write to the same local database at once. It only surfaced on devices with enough real data to collide over, so it passed QA clean and then corrupted state in the field.

Diagnosis

Reproduced on-device with concurrency debugging enabled, not in the simulator. Traced it to two coordinators sharing the same sync managers with no mutual exclusion between them — confirmed by forcing a foreground/background overlap and watching the crash logs line up.

Fix

A shared gate both coordinators pass through before touching the store, with priority levels so a full re-sync can still preempt routine background work instead of queuing behind it. Verified clean on device across cold-start and background-to-foreground transitions.

  • Core Data / Room
  • Swift & Kotlin Concurrency
  • Offline-first sync
  • WebSocket chat
  • TUS chunked uploads
B

Personal Project

Bug Defense

iOS · Swift, SwiftUI, SpriteKit

A tower-defense game in the spirit of Bloons TD, themed around IT infrastructure fighting off bugs. Towers are upgradeable kit along a defended path; the excuse to build it was learning SpriteKit properly outside of work hours.

  • SpriteKit
  • Game architecture
C

Client Work — Phoenix Joinery

Small-business site, start to finish

Took a joinery business off a Facebook-only presence and onto its own domain: a responsive site to showcase past work, plus a dedicated business email so client calls and enquiries stopped mixing with a personal inbox. Still maintained with ongoing updates.

"Helped my business have its own domain and a responsive website to display previous clients' work... helps with regular updates on the site when called — will keep using this service." — Gary Stevenson, Phoenix Joinery

Also in the field

  • Airsys — multi-language display support for industrial control units, replacing English-only defaults for non-English-speaking markets.

Sheet 04 — Method

How I work.

  1. 01

    Solo, end to end

    When there's no separate mobile team to hand a spec to, I own it end to end — client-side architecture, sync logic, and the bugs that show up once it's in production.

  2. 02

    Offline-first, by default

    Field-operations software can't assume a signal. Every feature is designed around what happens when the network isn't there, not treated as an edge case afterwards.

  3. 03

    Debug from the device, not the simulator

    The concurrency and sync issues that matter only show up with real data and real background execution — most of my hardest bugs have been found and verified on-device.

  4. 04

    Keep building

    Front-end and back-end web day-to-day now, while continuing to ship and grow native mobile apps alongside it.

Sheet 05 — Contact

Have a project, or a role, in mind?

Reach out directly — I read every message myself.

Location

Manchester, United Kingdom

Elsewhere

Twitter Instagram