When "Clicks, not code" becomes "Clicks, not architecture"

Underengineering is a chronic issue in Salesforce and other no-/low-code platforms. "Clicks, not code" too often becomes "clicks, not architecture."

The same exact pitfalls that drove architectural best practices for code exist for no-/low-code. Flows (Workflows, Zaps, Business Processes...) that grow organically end up as either sprawling monoliths that look like city maps 🗺️ when zoomed out, or a jumble of smaller ones bumping into and duplicating each other.

At first, the organic growth feels like speed. A business requirement pops up and gets slapped straight into the system. The early cracks seem manageable: concepts like reusability and idempotency are learned the hard way, but usually only narrowly applied to whatever logic caused the late nights of troubleshooting and data cleanup. Who has time for tech debt? (Who doesn't? Another post...)

But those quick additions & fixes pile up, and the system starts to sag under its own weight. Everything runs slower, "simple" requirements stop being simple, and no one but the original admin dares touch certain logic 😬. When I've encountered these Rube Goldberg machines, unwinding the mess is often more work than reverse-engineering the original requirements and designing the architecture properly from scratch.

So don't get enamored with that initial feeling of speed that comes from skipping architecting and best practices. The bill always comes due, and it may just be a complete rebuild of the infrastructure your business runs on. After years of investment, can your business really afford that? 💸