<h2>1. Start with the real failure mode</h2><p>Excel/VBA automation: from macro script to reliable architecture is worth discussing when it is tied to a concrete constraint. The focus here is automation. I write down the symptom, expected behavior, data volume and verification method before changing code. This prevents a local fix from creating a harder problem elsewhere.</p><p>Business software benefits from boring reliability: explicit state, small components, traceable errors and a clear boundary between UI, domain rules and storage.</p><h2>2. Design the data path first</h2><p>Map the path from input to validation, persistence, synchronization and rendering. Each step should be able to fail without leaving ambiguous state. Stable identifiers and timestamps are more useful than assumptions about call order.</p><h2>3. Keep the contract small</h2><pre><code>If JobExists(entryId) Then Exit Sub</code></pre><p>The snippet is intentionally small. Infrastructure should be replaceable while domain rules remain testable without a screen or vendor SDK.</p><h2>4. Test hostile conditions</h2><p>Try slow networks, retries, duplicates, simultaneous edits, Arabic text, narrow screens, large lists, process restarts and temporary server failure. These cases expose architecture quality much faster than the happy path.</p><h2>5. Measure before optimizing</h2><p>Track response time, query count, errors, rendered items and repeated work. Optimize a known cost. A viewport query or a missing database index is often more valuable than adding an opaque cache.</p><h3>Production checklist</h3><ul><li>Correct before fast.</li><li>Retry-safe writes.</li><li>Authorization enforced server-side.</li><li>Logs that explain incidents.</li><li>UI density that prioritizes useful content.</li></ul><h2>6. The production rule</h2><p>Keep a solution when its behavior is predictable, observable and documented. Add one non-regression test for the critical scenario before moving on.</p>