Mazzolini › Approach
How we work
A deliberate, written, unhurried engagement model. Most of the value of operational software is decided long before the code is written; we organize the practice around the conversations that determine it.
Posture
We are a small practice by choice. The work we do is more valuable when it is performed slowly enough to be done correctly, documented carefully, and maintained by the same hands that built it.
The most useful systems we have ever built were the ones in which the simplest credible answer was also the answer we chose.
We prefer small, legible systems to large, clever ones. We prefer plain language to jargon, written decisions to verbal ones, and reversible choices to dramatic ones.
Engagement
Not every engagement follows this shape, but most do. Each stage produces a written artifact that can be read by anyone in the organization and revisited later.
A close look at the workflow as it actually exists: who does what, in which system, in what order, and where the friction lives. We describe the existing operation in writing before proposing any change to it. Many engagements end here, by mutual agreement, with a clear document and no software at all.
A short, written design: the smallest credible system that improves the workflow, the data it will touch, the integrations it will require, the costs of running it, and the ways it can be backed out if it turns out to be wrong. Decisions are documented with their reasons attached.
A scoped pilot in a portion of the workflow, with real data, real users, and clear criteria for whether to extend the system or retire it. We treat the pilot as a question, not a foregone conclusion. If it answers the question poorly, we say so.
Quiet ongoing maintenance: monitoring, periodic review, small extensions, written operating procedures, and the kind of attention that keeps a system useful five years after it shipped. A retainer at this stage is intentionally modest and deliberately boring.
Commitments
These are the standards we keep regardless of engagement size. They are also the standards we ask any future colleague to be willing to meet.
I.
Important choices live in plain documents, with their reasons attached, and remain accessible to whoever inherits the system.
II.
Where possible, we prefer changes that can be quietly undone. We avoid one-way doors when a two-way door is available.
III.
If a non-technical stakeholder cannot understand the system in conversation, we have not finished designing it.
IV.
Good operational software calls attention to itself only when something is genuinely wrong. Silence is a feature.
Next
We respond personally to every inquiry. If we are not the right practice for the work, we will say so and, when we can, suggest a colleague who is.
