An engineering studio that treats software as durable infrastructure.
Weekday Offender Limited is a small, independent practice. We build software the way careful drafts are drawn — clearly, honestly, and with the expectation that someone else will read it later.
A studio, not an agency.
Weekday Offender Limited is registered in the United Kingdom as an independent engineering practice. We operate as a studio: engagements are led by the people who write the code, engineers speak directly with the people who use what we build, and technical judgement is not diluted by intermediaries.
We are deliberately small. That is a permanent choice, not a stage on the way to becoming something larger. It lets us stay accountable, invested in the systems we ship, and honest about work that is outside our range.
To build software that outlasts its launch.
The systems that quietly run a business for years are worth more than the ones that impress in a demo. Our mission is to build software with that longer horizon in mind — code that a future colleague can read, infrastructure that a smaller team can operate, and interfaces that respect the time of the people using them.
Software as considered work, not disposable output.
We work towards a version of the industry where software is treated with the same care as any other piece of engineering: drawn before it is built, reviewed before it is shipped, and maintained after it is in use. Nothing in that description is novel — it is simply what we would like the default to be.
How we conduct ourselves inside an engagement.
- DirectnessWe say what we think about a design, a risk, or a decision. We would rather be uncomfortable in a meeting than sorry in production.
- Written recordDecisions, trade-offs and scope changes are documented in writing so they survive turnover on either side.
- FocusOne engineer works on one problem at a time. We do not try to compensate for shallow attention with more people.
- Slowness where it mattersWe invest disproportionate time in the parts of a system that are hardest to change later.
- RefusalWe turn down work we cannot do well. It costs more to disappoint a client than to decline politely.
Deliberately narrow. Deliberately deep.
We keep our toolkit small on purpose. A short list of languages, runtimes, data stores and cloud primitives lets us reason confidently about what will happen in production, and lets us fix problems quickly when they occur. New tools enter the toolkit slowly, and only when they solve a real problem we have hit repeatedly.
Where possible we choose portable, standards-based solutions over vendor-specific shortcuts. That occasionally costs us a small amount of initial speed, and consistently saves clients from being trapped by a decision we made on their behalf.
Quality is a property of the process, not a phase at the end.
Applied at the editor level so that entire categories of error never reach review.
Unit, integration and targeted end-to-end tests, sized to the risk of each subsystem.
Every change that reaches production is reviewed by a second engineer.
Structured logs, metrics and traces are shipped with the code, not added afterwards.
Fewer meetings, better artefacts.
We prefer written communication for anything that has consequences. Meetings are used for decisions, not for status. Weekly progress is summarised in a short, honest note that a client can forward to a colleague who was not in the room. Ad-hoc messages are answered within the working day, and out-of-hours contact is reserved for genuine incidents.
Incremental, evidence-driven, and open about scope.
- PHASE 01Framing
A written brief we both sign off on before code is written.
- PHASE 02Architecture note
A short document describing the shape of the system and the key decisions.
- PHASE 03Delivery increments
Two to four week slices, each ending in something running in a real environment.
- PHASE 04Weekly review
A written summary of what changed, what we learned, and what we recommend next.
- PHASE 05Hardening
A dedicated pass on failure modes, performance and access before meaningful use.
- PHASE 06Handover or operation
Documented handover to your team, or continued operation by us under agreed terms.
Reasonable defaults, applied without ceremony.
Every engagement is covered by a mutual non-disclosure agreement. Client credentials are stored in a dedicated secrets manager and are only accessible to the individuals working on that engagement. We do not copy production data to local machines unless the work explicitly requires it, and we destroy such copies when they are no longer needed.
Access to production systems is scoped, time-limited and logged. Changes to production are made through the same review process as any other change, regardless of urgency. When an engagement ends, our access ends with it.
We would rather work with fewer clients for longer.
Most of the systems worth building take longer than a single project to mature. Where it makes sense, we continue to work with clients after the first delivery — extending, operating and gradually reshaping the system as the business it serves changes. Long collaborations let us make decisions with a longer horizon in mind, and they keep the knowledge about the system close to the code.