Financial services
Compliance-aware platforms, ledger systems, and back-office modernisation.
Chapter 01 — The studio
Software, written with intent.
Write, Record & Play is a small independent studio engineering dependable digital systems. We write specifications, record decisions, and ship software that keeps playing long after the launch week is over.
EST. STUDIOBASED REMOTEWRITING-FIRST
v.2026.06 — engaged
Platform engineering·Distributed systems·Interface design·Mobile applications·Data infrastructure·Product modernisation
Chapter 02 — Who we are
A studio assembled around discipline.
We are engineers, designers, and writers who believe software is a long conversation. Our work begins with a memo and ends with a system you can maintain confidently — without ceremony, without surprises.
We keep teams small on purpose. Every engagement is staffed by senior practitioners with end-to-end accountability. No layers, no theatre.
Chapter 03 — What we do
Six practices,
one studio.
We resist the urge to specialise into a single deliverable. Most projects need two or three of these practices working in concert.
- 01
Platform engineering
Backbones for product teams — APIs, services, identity, observability, the parts that do not get tweeted about.
- 02
Web applications
Considered front-ends built on modern frameworks, with motion, accessibility and performance held to the same standard.
- 03
Mobile applications
Native and cross-platform mobile work for teams who want their product to belong on the device.
- 04
Cloud infrastructure
Pragmatic infrastructure design, migrations, and modernisation — treated as a deliverable, not an afterthought.
- 05
Data engineering
Pipelines, warehouses, and the unglamorous plumbing that turns raw events into reliable reports.
- 06
Product design
Interface design and design systems built in code, refined in review, and documented as part of the work.
Chapter 04 — Technology
A deliberate stack, not a buffet.
We keep a focused toolkit and reach for the same proven set across most engagements. Familiarity compounds; novelty is a tax.
Languages
- TypeScript
- Python
- Go
- Swift
- Kotlin
- Rust
Frameworks
- React
- Next.js
- TanStack
- Node.js
- FastAPI
- SwiftUI
Cloud
- AWS
- Google Cloud
- Cloudflare
- Vercel
- Fly.io
Data
- Postgres
- ClickHouse
- Kafka
- dbt
- BigQuery
- DuckDB
Tooling
- Terraform
- Pulumi
- GitHub Actions
- Docker
- Nix
Practice
- Design systems
- Accessibility
- Observability
- Threat modelling
Chapter 05 — How we work
Five movements
in every project.
Our process is the same regardless of stack or industry. The medium changes; the rigour does not.
- I
Discovery
A written brief that captures intent, constraints, and risks before timelines are fixed.
- II
Architecture
Decisions recorded as design documents, with diagrams and trade-offs spelled out.
- III
Build
Small reviewed pull requests, paired sessions, and weekly written progress notes.
- IV
Hardening
Performance budgets, accessibility audits, observability dashboards, and migration drills.
- V
Handover
Runbooks, recorded walkthroughs, and a maintenance window with the receiving team.
Chapter 06 — Industries
Where we play.
We pick work where reliability matters and where decisions need to stand up to scrutiny months and years after they're made.
Health technology
Clinician-facing tooling, patient experience, and integration with established record systems.
Manufacturing
Operational dashboards, telemetry, and tooling for the factory floor and supply chain.
Media & publishing
Editorial platforms, content infrastructure, and reader-side performance.
Education
Course platforms, assessment systems, and tools that respect the attention of learners.
Public sector
Service design and accessible, durable web platforms for institutions.
Chapter 07 — Why us
Reasons that
hold up.
- Senior by default
- Every engagement is staffed with engineers who have shipped and maintained production systems for years, not quarters.
- Writing as a tool
- Memos, design docs, and decision logs are part of the work — not overhead added at the end.
- Small surface area
- Few clients at any time. The studio's attention is a finite resource, treated as such.
- Long horizons
- We optimise for the system you'll live with in two years, not the demo you'll show next week.
Chapter 08 — Project approach
Decisions on paper, before they cost anything.
We separate the cheap parts of a project — thinking, writing, sketching — from the expensive ones. By the time a line of production code is committed, the shape of the system has already been argued over, written down, and reviewed.
- — Weekly written status notes
- — Reviewable design documents per subsystem
- — Risk register maintained from kickoff to handover
- — Decision log accessible to the entire client team
Chapter 09 — Values
What we
keep coming
back to.
Plain language
We write to be understood. If a sentence needs a glossary, it gets rewritten.
Maintainable craft
Beautiful code that no one can maintain is a liability. We optimise for the team that inherits it.
Honest estimates
We name the unknowns and give ranges, not single numbers we don't believe.
Quiet confidence
We don't oversell. The work either holds up under load or it doesn't.
Chapter 10 — In the field
The unglamorous work runs the world. We're fine with that.
Chapter 11 — Questions
Asked often,
answered briefly.
- What kinds of projects do you take on?
- Long-form engineering work: web platforms, internal tools, data infrastructure, mobile applications, and product modernisation engagements.
- How do engagements usually start?
- With a written discovery brief. We translate ambiguous goals into a scoped statement of work before any code is written.
- Do you work with existing in-house teams?
- Yes. We embed alongside product, design, and engineering teams, contributing to the same repositories, rituals, and review processes.
- Where is the studio based?
- We operate as a distributed studio with collaborators across multiple time zones and one shared writing-first culture.
- How long is a typical engagement?
- Most projects run between three and twelve months. Shorter discovery work is common; we avoid open-ended staffing.
- What does collaboration look like day to day?
- Asynchronous writing, scheduled deep-work sessions, and short focused calls. We default to written context so decisions are searchable.
Chapter 12 — Contact
Start with a
written note.
New work begins in writing. Send us a paragraph or two about what you're building and the constraints you're working under.
- [email protected]
- Studio
- writerecordplay.com
- Hours
- Monday – Friday · written replies within two business days