Arukh HaShulchan, Orach Chaim 313:14-21

Hook

Every founder is a professional liar when it comes to time. We look our lead engineers in the eye and say, "Just duct-tape this integration together for the enterprise demo on Friday. We’ll rewrite it properly next sprint."

We look our investors in the eye and say, "Our platform is completely modular; we can spin up a custom instance for this client in forty-eight hours."

But in the quiet of your own mind, you know the truth: that "temporary" workaround is already hardening into the permanent foundation of your product. The quick-and-dirty script you deployed to bypass a database bottleneck is now a load-bearing pillar of your infrastructure. The makeshift operational manual your customer success team uses to manually copy-paste data between legacy systems—because the API has been "down for maintenance" for six months—is now a permanent line item in your burn rate.

In software and in company building, nothing is more permanent than a temporary solution.

This isn't just an engineering bottleneck or a product management headache; it is a fundamental ethical failure. When we disguise fragile, temporary bypasses as robust, permanent structures, we deceive our customers, exploit our technical talent, and inflate our valuation on a foundation of structural sand. We are selling a finished, engineered vessel while delivering a pile of loosely stacked components held together by wishful thinking and caffeinated night shifts.

How do we draw the line between a legitimate, modular MVP (Minimum Viable Product) and an unethical, unstable workaround? How do we balance the operational necessity of shipping fast with the ethical mandate of delivering structural truth?

The answer lies in a highly technical, centuries-old halakhic debate regarding the mechanics of assembly on the Sabbath. In his masterwork, the Arukh HaShulchan, Rabbi Yechiel Michel Epstein analyzes the laws of Boneh (building) and Soter (demolishing) as they apply not to physical buildings, but to kelim—vessels, utensils, and modular tools.

His insights provide a brilliant framework for modern founders navigating technical debt, product truth, and the ethical boundaries of the temporary workaround.

---

Text Snapshot

"כל שאינו תקוע בחוזק, אף על פי שהוא מחובר, אין בו משום בניין..." "Anything that is not tightly fastened, even though it is connected, does not fall under the category of building..." — Arukh HaShulchan, Orach Chaim 313:14

"אם החזירן ותקע אותן בחוזק... חייב חטאת" "If he returned them and fastened them tightly... he is liable for a sin offering." — Arukh HaShulchan, Orach Chaim 313:15

"דכל כלי העשוי לפרק ולהחזיר תמיד, אין בזה משום תיקון כלי" "For any vessel that is designed to be disassembled and reassembled constantly, there is no issue of repairing a vessel." — Arukh HaShulchan, Orach Chaim 313:17

---

Analysis

Insight 1: The Danger of "Teka" (Tight Fastening) — When the Temporary Hardens Into the Permanent

The core tension in the halakhic analysis of assembling vessels on Shabbat centers on the concept of teka—the act of fastening components together tightly or permanently.

According to Arukh HaShulchan, Orach Chaim 313:14, if components are connected loosely (shafui), the assembly does not constitute "building" (Boneh) because it lacks the intention and the physical reality of permanence. However, the moment you fasten those parts together with force (teka), you have crossed a critical threshold: you have transformed a collection of independent parts into a single, permanent entity. If you do this on Shabbat, you are liable for a major transgression:

"אם החזירן ותקע אותן בחוזק... חייב חטאת" (If he returned them and fastened them tightly... he is liable for a sin offering) — Arukh HaShulchan, Orach Chaim 313:15.

In the startup ecosystem, this is the precise moment of ethical hazard for a founder. A "temporary workaround" is halakhically and operationally equivalent to a loose connection (shafui). It is designed to be easily disassembled, swapped out, and replaced. It is a bypass, not a foundation.

The ethical transgression occurs when we allow this loose, unvetted connection to harden into a teka connection—a permanent, load-bearing part of our system—without the corresponding testing, documentation, and architectural consent.

When you let a temporary patch sit in your codebase for eighteen months because "it works well enough," you have performed an unauthorized teka. You are presenting a product to your customers as a finished, professionally engineered vessel, but under the hood, it is a series of loose parts that have rusted together.

This is not merely a technical debt problem; it is a fairness issue. Your customers are paying for structural integrity. Your investors are pricing your company based on scalable technology. If your platform's core functionality relies on "temporary" scripts that your team is terrified to touch, you are operating in a state of structural deception.

The ethical founder must establish a hard boundary: if a connection is built as a temporary workaround (shafui), it must have an explicit, hard-coded expiration date. If it is to become permanent (teka), it must undergo the full, rigorous process of architectural review, testing, and formal integration. You cannot allow a temporary bypass to become a permanent foundation by default.

Insight 2: The Truth of Modularity — "Designed to be Disassembled"

Startups love to throw around the word "modular." We sell "plug-and-play" integrations, "highly configurable" workflows, and "extensible" APIs. But there is a massive ethical difference between a product that is truly designed for modularity and a product that is simply broken and requires constant manual re-assembly to function.

The Arukh HaShulchan addresses this distinction with remarkable precision. He explains that if a vessel is explicitly designed from its very inception to be repeatedly taken apart and put back together as part of its normal operation, assembling it does not violate the Sabbath:

"דכל כלי העשוי לפרק ולהחזיר תמיד, אין בזה משום תיקון כלי" (For any vessel that is designed to be disassembled and reassembled constantly, there is no issue of repairing a vessel) — Arukh HaShulchan, Orach Chaim 313:17.

Why? Because the disassembly and reassembly are native to the vessel’s identity. The parts are designed to fit together seamlessly without requiring professional tools, force, or permanent modification. The modularity is a feature, not a bug.

Now contrast this with a system that is not designed to be disassembled, but is constantly patched, broken apart, and stitched back together out of operational desperation. If your customer success team has to manually run database queries or custom scripts every time a new client onboard because your "modular" system doesn't actually talk to its own database, you are not running a modular platform. You are running a broken machine that requires constant, manual, structural repair (tikkun kli).

The ethical lesson here is one of absolute transparency regarding your product’s true architecture.

If you sell a "modular platform," but deploying a new module requires your engineering team to write custom, tightly coupled code for three weeks, you are lying about your product’s nature. You are selling a system that is "designed to be disassembled and reassembled constantly" when, in reality, every assembly requires a team of engineers with sledgehammers and welding torches.

True modularity requires structural truth. If your product requires custom, manual intervention to work, own that. Do not sell the illusion of a self-assembling machine when you are actually selling a bucket of parts and a hidden army of assembly workers.

Insight 3: Ethical Demolition — "Soter" on the Path to Scale

In Jewish law, the act of demolishing (Soter) is one of the 39 forbidden creative acts on Shabbat. However, the Talmud in Shabbat 31b establishes a vital principle: demolition is only biblically prohibited if it is done "on condition to rebuild" (על מנת לבנות). If you demolish something purely for the sake of destruction, it is considered destructive acts (mekalkel), which are rabbinically forbidden but do not carry the same biblical weight.

The Arukh HaShulchan carries this logic into the domain of vessels. If you are dismantling a vessel to improve it, to clean it, or to prepare it for a better, more permanent reconstruction, that act of dismantling is part of the creative process of building.

In the startup journey, you will inevitably reach a point where your early-stage architecture, your initial operational processes, or your early sales pipelines can no longer support your scale. You have to tear them down. This is the startup equivalent of Soter (demolition).

The ethical challenge here is how we manage this demolition. Many founders engage in "destructive demolition." They panic, scrap their entire codebase, fire entire departments, or abandon core customer segments without a clear, engineered blueprint for what comes next. They destroy value, burn out their teams, and leave their existing customers stranded in the ruins of a half-demolished product.

The Arukh HaShulchan teaches us that demolition is only ethically and creatively justified if it is done strictly on the condition to rebuild (al menat livnot):

"כל סותר על מנת לבנות... הוא מלאכה גמורה" (Any demolition on the condition to rebuild... is a complete, purposeful labor) — Arukh HaShulchan, Orach Chaim 313:20.

When you decide to deprecate a feature, refactor a codebase, or restructure an organization, you have an ethical obligation to your stakeholders to ensure that the demolition is tightly coupled with a concrete, funded, and realistic plan for reconstruction.

You cannot ethically justify tearing down a customer's stable (albeit legacy) workflow just because your engineers want to play with a newer framework, unless you have a guaranteed, seamless path to the rebuilt solution.

Demolition without a blueprint for reconstruction is not innovation; it is operational vandalism.

---

Policy Move

The "Shafui" Protocol: The Workaround & Technical Debt Registry

To operationalize these insights, your company must implement a concrete policy that prevents temporary, loose connections (shafui) from quietly hardening into permanent, unvetted structures (teka).

We call this The Shafui Protocol.

Policy Objective

To ensure that every temporary operational workaround, hotfix, or manual bypass deployed across product, engineering, or operations is explicitly tracked, given a hard expiration date, and assigned a clear financial and operational owner.

Execution Steps

1. The Workaround Registry (The "Shafui" Log):

   • Every time a team (Engineering, Product, Customer Success, or Operations) deploys a temporary patch, a manual data-entry workaround, or a custom script to bypass a product limitation, they must log it in the Shafui Log.
   • This is not a standard Jira ticket. It is a high-visibility, cross-functional registry.

2. Mandatory Metadata for Every Workaround:

   • The "Teka" Trigger: The exact conditions under which this workaround must be deprecated or replaced with a permanent build (e.g., "When client volume exceeds 50 concurrent users," "When monthly transaction volume hits $100k," or "Hard stop on [Date: 90 days from launch]").
   • The Human Cost Proxy: The exact number of hours per week your team spends manually maintaining, monitoring, or executing this workaround.
   • The Architectural Owner: The designated leader responsible for either tearing down this workaround or securing the resources to build it into a permanent, vetted feature.

3. The Workaround Half-Life Index (WHLI) — Your KPI Proxy:

   • Introduce a new board-level and management-level metric: The Workaround Half-Life Index (WHLI).
   • Formula: $$\text{WHLI} = \frac{\text{Sum of days all active workarounds have remained in production}}{\text{Total number of active workarounds}}$$
   • The Target: Your company's target WHLI must be under 45 days. If the average workaround is sitting in your system for longer than 45 days, it has officially hardened into an unauthorized teka structure.

4. The Automatic Deprecation Rule:

   • If any workaround in the Shafui Log exceeds its "Teka Trigger" or its maximum lifespan (capped at 90 days), the system or process must undergo an immediate review.
   • If it is not replaced or formally prioritized in the immediate sprint, the product team is legally prohibited from shipping any new feature development until the debt is cleared. You do not build a second story on a house supported by rotting temporary scaffolding.

---

Board-Level Question

"Are we scaling a product, or are we scaling a hidden services business disguised as software?"

As a board member or a leadership team, you must look beyond the top-line ARR (Annual Recurring Revenue) and drill into the operational reality of how that revenue is actually being serviced.

Many high-growth SaaS startups appear to have incredible gross margins on paper, but a deep dive into their operational workflows reveals a terrifying truth: the software is broken, and the company is employing a massive, expensive, and stressed-out customer success or operations team to manually act as the "API" between disconnected databases and unstable features.

This is a classic violation of the laws of Kelim (vessels). You are presenting a finished, automated vessel to the market, but behind the scenes, your team is constantly performing manual tikkun kli (repairing and assembling the vessel) on a daily basis just to keep it from collapsing.

Ask your leadership team this specific, uncomfortable question at the next board meeting:

"If we were to completely ban our customer success and operations teams from performing any manual database updates, manual data entry, or custom scripting for forty-eight hours, what percentage of our active customers would experience a critical product failure?"

If the answer is anything higher than 5%, your product is not a scalable, modular vessel. You are running a consulting and services business disguised as software.

You are inflating your valuation based on an illusion of scalability, and you are burning through your venture capital to fund manual labor that should be handled by robust, automated engineering. You must demand a clear roadmap to transition these loose, manual connections into permanent, automated, and architecturally sound features.

---

Takeaway

Halakha does not demand that we only build perfect, permanent structures from day one. It recognizes the utility of the temporary, the modular, and the easily disassembled.

But Torah ethics draws an uncompromising line between the loose connection (shafui) and the permanent bond (teka).

In your startup, speed is your greatest weapon, and the temporary workaround is a legitimate tactical tool. But the moment you let a workaround harden into a permanent foundation without architectural honesty, you have crossed the line from agile execution to structural deceit.

Keep your connections loose when they are meant to be temporary, build them to be easily disassembled when they are meant to be modular, and have the courage to perform an ethical, planned demolition when it is time to rebuild for scale.

Do not build your unicorn on a foundation of duct tape and lies. Build a vessel that can stand the test of truth.