Software engineer
Peter Wilkins
Functional backend engineer for complex regulated domains.
I turn complex domains into simple, reliable software: payment systems, billing workflows, immutable data models, executable rules, local-first tools and AI-augmented engineering systems.
My strongest work is usually at the boundary between domain understanding and architecture: finding the durable facts, separating concerns, making trade-offs explicit, and keeping systems understandable as they grow.
What I Bring
Complexity into working systems
Domain modelling
I like finding the real nouns, facts, lifecycles and constraints in a domain before locking in implementation.
Functional design
Clojure, immutable data and explicit boundaries have shaped how I split problems into simpler parts.
Regulated systems
Finance, energy and healthcare work taught me to care about correctness, auditability, schema evolution and operational safety.
AI leverage
I use agents to move faster, but keep architecture, product judgement and acceptance criteria human-led.
Professional Experience
Backend systems in finance, energy, healthcare and SaaS
JUXT
Software Engineer / Consultant
Consultant building cloud-native backend systems for large financial organisations using Clojure and functional programming.
- Worked on Funding Circle payment workflows involving Direct Debits, Faster Payments and customer communications.
- Built services for regulated financial environments where correctness, resilience and operational safety mattered.
- Delivered backend services across Clojure, Python and Kotlin with Kubernetes, Terraform, AWS and Docker.
Design note
The useful thread through this work was not just implementation. It was understanding the business process, identifying the stable domain facts, and building services that could change safely in regulated environments.
OVO Energy
Software Engineer
Worked across payments and billing modernisation, including event-driven architecture and schema evolution.
- Developed payment services supporting Direct Debits, Faster Payments and customer communications.
- Helped redesign billing around asynchronous event streams rather than tightly coupled push workflows.
- Contributed to schema evolution strategies that reduced deployment risk and simplified long-term maintenance.
Design note
The key design move was reducing coupling: downstream systems should consume work when they are ready, and schema changes should be survivable rather than dramatic.
Polecat Intelligence
Software Engineer
Built core components of an intelligence platform using Clojure, Datomic, GraphQL, Kafka and Elasticsearch.
- Designed and built a taxonomy management system using Clojure and Datomic.
- Developed a GraphQL API that mapped naturally onto Datomic's immutable data model.
- Used Datomic's temporal query capabilities to identify changes efficiently for downstream processing.
Design note
This role shaped a lot of my taste for immutable data, temporal models and query interfaces that follow the shape of the domain instead of fighting it.
Dickies
Software Developer
Backend development for a large e-commerce platform.
Mayden
Software Developer
Developed patient-management software for NHS mental health services.
Architecture Themes
Recurring design decisions
- Local-first before cloud sync where user trust, offline work or data loss matters.
- Append-only events and immutable records where recovery, auditability or derived status matters.
- Small deterministic cores with flexible outer workflows.
- Functional boundaries and explicit data shapes for complicated domains.
- AI as reviewer, planner, operator and research partner, not just as a code generator.
- Human-in-the-loop decisions where automation would be risky or premature.
Selected Public Work
Recent projects as architecture evidence
The value in these projects is less the feature list and more the design decisions: where the boundary sits, what gets made deterministic, what stays local, what becomes a shared recipe, and where human judgement remains part of the system.
Inspectable automation
Commandbook
- Problem
- AI assistants are useful, but broad device access and hidden prompt logic make automation difficult to trust.
- Design decision
- Model commands as shared, inspectable recipes with named inputs, outputs, side effects, dry-run behaviour and trust expectations. Resumable coffee-grinder runs can pause for missing facts, human choices, permissions or platform failures.
- Why it matters
- Shows how to turn assistant behaviour into a portable command layer rather than a one-off chat transcript.
Physical product workflow
Shiny Art Shop
- Problem
- Custom physical artwork needs a friendly preview and quote flow, while production has real-world state, payment gates and human review.
- Design decision
- Model each order as a Project whose status is derived from facts and events. Separate customer, workshop, admin, payment and system commands. Use provider-swappable preview generation, with deterministic ImageMagick rendering as a stable comparison path for AI image experiments.
- Why it matters
- Shows product modelling, state-machine thinking and an early human-agent feedback loop for physical production.
Executable rules
RegenOS
- Problem
- Land restoration grants, evidence requirements and delivery tasks are often treated as paperwork rather than executable work.
- Design decision
- Model grants as structured tasks, eligibility rules, evidence requirements, claims and lifecycle gates. Keep country-specific schemes as data rather than hard-coding one government process.
- Why it matters
- Shows computational-law thinking: rules should be inspectable, explainable and connected to real evidence.
AI speech pipeline
WhisperWayland
- Problem
- Voice dictation needs low-friction capture, fast feedback and good transcripts across noisy real-world inputs.
- Design decision
- Treat transcription as a pipeline: capture, VAD, audio conditioning, streaming chunks, provider racing and text cleanup are separable stages with measurable trade-offs.
- Why it matters
- Shows AI used as a system component with latency, cost and accuracy constraints, not just as a code generator.
Other recent work
JobDone
Local-first operational memory for work: captures stay local until confirmation, confirmed entries are immutable, and sync is treated as a replica rather than the user's source of truth.
Continuum Core
A source-log and resume-brief layer for continuity of thought: the user should not have to maintain the filing system before the system can help them re-enter context.
Foil Board Toolkit
A parametric generator rather than a clone library: study public design trends, but produce original inspectable board definitions, geometry reports and generated review artifacts.
CNC Workshop Tools
Conservative digital-fabrication tooling: prove geometry and toolpaths in simulation, keep manufacturing assumptions explicit, and separate visual generation from machine-ready validation.
AI Engineering
Human-agent engineering
Most of my recent work was built in collaboration with AI agents. I do not treat agents as magic code generators or autonomous replacements for engineering judgement. The useful pattern is symbiosis: agents accelerate research, implementation, test generation and review; I provide product direction, architectural taste, domain judgement, acceptance criteria and the decision about what is actually worth building.
I could not move this quickly without AI. The agents would not produce coherent products without human direction. The value is in the working relationship.
Engineering Philosophy
Simple enough to reason about
My engineering style is strongly influenced by Rich Hickey's emphasis on simplicity, explicit design and separating concerns. I enjoy software that makes difficult domains understandable rather than hiding them behind layers of accidental complexity.
Good AI tooling makes this more important, not less. When implementation gets faster, the limiting factor becomes judgement: choosing the right surface area, knowing what not to build, and keeping the system coherent.
Technical Skills
Tools I use to build these systems
- Main languages
- Clojure, Scala, Kotlin, Python, JavaScript, SQL
- Functional and data systems
- Datomic, Kafka, event sourcing, immutable records, schema evolution
- Cloud and platform
- AWS, Kubernetes, Terraform, Docker, Linux
- Databases and APIs
- PostgreSQL, GraphQL, Elasticsearch, REST
- AI engineering
- Agent workflows, LLM review loops, transcript pipelines, AI-assisted prototyping
Contact
Get in touch
Email peter.wilkins2@protonmail.com or see recent public work at github.com/peter-wilkins.