-
Discovery pull request
Access, constraints, pain themes. Output: a problem statement in engineering language — not a sales slide.
-
Diagnostic branch
Hotspots, architecture sketches, interviews. Output: ranked backlog with effort and risk tags.
-
Pilot merge
One high-leverage area improved end-to-end so the organisation feels the method before scaling it.
-
Pattern rollout
Standards, pipelines, and coaching. Your engineers own the diffs; we refuse mysterious drive-by rewrites.
-
Steady-state retainers
Optional architecture reviews and hard refactors so craft does not slide forever to “later.”
SYNTAX LTD
Software that reads as clearly as it runs.
Architecture, code quality, and engineering practice for teams tired of clever chaos. 136 Dark Lane, Batley
# specification
What we optimise for — as a readable contract.
| Signal | Meaning | We push toward | We push against |
|---|---|---|---|
clarity |
A new engineer can change a module without folklore | Named seams, ADRs, tests as docs | “Ask Sarah, she knows” |
change-cost |
How expensive a safe edit is | Small PRs, characterisation tests | Fear-driven freezes |
boundary |
Where ownership and failure stop | Contracts, contexts, APIs | Shared databases by accident |
feedback |
Time from idea to evidence | CI under 10 minutes, progressive delivery | Weekend cutovers as culture |
debt |
Interest paid every sprint | Ranked hotspots, scheduled paydown | Infinite “later” |
# /modules
Capability tree — expand a node to read the export.
Services are nested like a parse tree. Open what you need; leave the rest collapsed.
module architecture
Current-state mapping, quality-attribute workshops, options with trade-offs, incremental migration paths, and ADRs your team will keep.
- Service & module dependency sketches
- Target shapes without big-bang rewrite fantasy
- Non-functional requirements made testable
- Decision records with consequences attached
module remediation
Hotspot analysis, characterisation tests, modularisation, API clean-ups, and debt backlogs ranked by business drag — not by engineer annoyance alone.
- Change-frequency × defect heatmaps
- Safe seams before structural moves
- Contract tests at team boundaries
- Paydown plans that fit sprint reality
module practice
Review playbooks, design critiques, CI gates sized to risk, pairing models, and onboarding paths so craft survives headcount growth.
- Review culture that teaches
- Definition of done in engineering language
- Trunk-friendly habits over branch theatre
- Critique formats for non-trivial designs
module domain
Event modelling, bounded contexts, API style guides, error models, and documentation that matches the running system — so business language and code stop arguing.
- Ubiquitous language workshops
- Context maps tied to ownership
- Versioning & deprecation policies
- Error catalogues developers can handle
module migration
Strangler patterns, dual-run strategies, feature flags, observability checklists, and honest stakeholder communication for complex change.
- Expand/contract sequences
- Rollback criteria written before go-live
- Rehearsals that find real gaps
- Cutover narratives without mythology
# lint.config
Rules we enforce on every engagement.
# RFC-0001
Engagement protocol (proposed standard).
# /diffs
Before → after — what clearer syntax changed.
saas-monolith modular-boundaries
− before
- Every feature touched everything
- Onboarding measured in months
- Change failure climbing quietly
- Fear of adjacent code
+ after
- Domain modules with clear seams
- Characterisation tests on payments
- Billing extraction without big-bang
- Lead time improved via safer edits
We mapped domains, protected the critical path with tests, then modularised inside the monolith before any service split.
distributed-spaghetti contract-first
− before
- 22 services, one shared database
- Sync call fog
- “Just add another service”
- No coherent mental model
+ after
- Accidental distribution collapsed
- Async contracts where they mattered
- ADRs stopping reflex splits
- Operational noise reduced
Microservices were not the problem — missing boundaries were. We fixed language and ownership first.
review-culture teachable-prs
− before
- Rubber stamps or bikesheds
- Style-only comments
- Taste wars in threads
- Defects escaping to prod
+ after
- Behaviour & risk checklists
- Weekly design critiques
- Teaching moments in review
- More defects caught pre-merge
Process without craft is bureaucracy. Craft without review is folklore. We installed both.
# LEXICON.md
Shared language we install with client teams.
- Hotspot
- A module that changes often and fails often — pay debt here first.
- Seam
- A place you can change behaviour without rewriting the universe.
- Characterisation test
- A test that locks current behaviour so refactoring does not guess.
- ADR
- Architecture Decision Record — why we chose A over B, with consequences.
- Strangler
- Replace legacy gradually by routing new work through a new path.
- Ubiquitous language
- The same words in conversation, tickets, and code — no translation tax.
- Feedback budget
- Maximum acceptable time from commit to useful signal in CI or prod.
- Ordinary excellence
- Systems changeable by good engineers — not only by heroes.
# office-hours.md
Who this practice is for — and when to call.
Book us when…
- Velocity is up but understanding is down
- Migrations keep slipping a quarter
- Onboarding takes a season
- Reviews argue taste, not risk
- Production is the only integration test
Skip us when…
- You want a slide deck and no repository access
- The goal is headcount theatre, not outcomes
- Leadership will not protect paydown time
- You need a body shop for tickets only
0 codebases touched
0 years in craft
0 teams coached
0 patience for “don’t touch it”
# diagnostics
Frequent compile errors from first conversations.
error TS-BUYER: Do you only advise?
Both. Architecture leadership plus hands-on code in your repos under your review process.
error TS-STACK: Which languages?
Mainstream backend and full-stack ecosystems. Craft transfers; we meet you in your stack.
error TS-MID: Can you join a migration in flight?
Yes — especially to reduce thrash and sequence remaining risk honestly.
error TS-METRIC: How do you measure success?
Lead time, change fail rate, onboarding time, hotspot churn, incident themes — not vanity points.
# contact.sh
Send the codebase story you are tired of retelling.
$ cat address.txt
SYNTAX LTD136 Dark Lane
Batley
$ echo $EMAIL
$ ./send-brief.sh --interactive