Arukh HaShulchan Yomi · Startup Mensch · Standard
Arukh HaShulchan, Orach Chaim 314:13-19
Hook
The dominant mantra of the modern technology ecosystem is a cliché: "Move fast and break things." Founders are celebrated for bypassing gatekeepers, scraping proprietary databases, and reverse-engineering competitors’ software. We are told that disruption is inherently virtuous, and that asking for permission is a death sentence for early-stage growth.
But as your startup matures from a scrappy MVP to an enterprise-grade platform, this "breaking" mentality transitions from a competitive advantage to a catastrophic liability.
When you bypass a competitor’s API limit, scrape their data, or build a business model on top of an unauthorized system integration, are you engaging in brilliant growth hacking, or are you committing intellectual and ethical theft? When you sunset a legacy product—effectively bricking the hardware or software your early customers paid for—are you optimizing your resource allocation, or are you violating an implicit contract of utility?
The tension between creative destruction and outright vandalism is not a new product management dilemma. It is a fundamental question of property rights, resource stewardship, and systemic integrity.
[THE FOUNDER'S TENSION]
│
┌────────────────────────┴────────────────────────┐
▼ ▼
[Creative Disruption] [Ethical Vandalism]
- Agile Workarounds - Broken Integrations
- Data Extraction - Predatory Lock-in
- Rapid Iteration - Deceptive Vaporware
To navigate this, we turn to the laws of Shabbat as codified in the Arukh HaShulchan, Orach Chaim 314:13-19. Written by Rabbi Yechiel Michel Epstein in the late 19th century, this text dissects the mechanics of Boneh (building) and Soter (demolishing) as they apply to vessels (Kelim).
Specifically, it examines when you are permitted to break open a sealed container to access the goods inside, and when doing so crosses the line into creating a new functional tool or permanently destroying property.
Applying this text to modern business reveals a sophisticated framework for growth hacking, product sunsetting, and platform interoperability. It teaches us how to extract value from existing market structures without destroying the very ecosystems we rely on to survive.
Full Experience in the App
Listen. Chat. Go deeper.
Audio playback, interactive chevruta, Hebrew tools, and every daily learning track — only in Derekh Learning.
Text Snapshot
ערוך השולחן, אורח חיים שס״ד:י״ג-י״ט
יג ...כלל גדול אמרו: אין בניין וסתירה בכלים. ומכל מקום, אם עושה פתח יפה – הוי כמתקן כלי, ואסור משום מכה בפטיש או בונה... יד במה דברים אמורים? במוסתקי, שהוא כלי שנשבר ומדבקין שבריו בזפת או בסיד... אבל מותר להפקיע חבלים שעל גבי סלים... טו ומותר להפקיע ולחתוך המגופה של חבית... ובלבד שלא יתכוין לעשות לה פתח יפה שיהיה נוח להשתמש בה תמיד...
Arukh HaShulchan, Orach Chaim 314:13-15
13 ...A great principle was stated: There is no concept of building or destroying when it comes to vessels. Nevertheless, if one creates a beautiful, functional opening (petach yafah), it is considered fixing a vessel, which is forbidden under the category of "striking the final blow" (makeh b'patish) or "building"... 14 To what does this apply? To a mustaki [a broken vessel whose shards are glued together with pitch or plaster]... But it is permitted to untie or cut the ropes that are bound around baskets [to access the food within]... 15 And it is permitted to break or cut the cover of a barrel... provided that he does not intend to create a beautiful opening that would make it convenient for continuous use...
Analysis
To build a high-growth startup, you must constantly interface with other companies' products, platforms, and data. The Arukh HaShulchan provides three profound decision rules that govern how we interact with these external systems, how we build our own software, and how we manage customer lock-in.
┌─────────────────────────────────────────────────────────────────────────┐
│ THE THREE HALAKHIC METAPHORS │
├─────────────────────────┬─────────────────────────┬─────────────────────┤
│ Halakhic Concept │ Software Analog │ Business Metric │
├─────────────────────────┼─────────────────────────┼─────────────────────┤
│ 1. Breaking the Vessel │ API Scraping & │ Churn-to-Extraction │
│ (Ein Binyan B'Kelim) │ Growth Hacking │ Ratio (CER) │
├─────────────────────────┼─────────────────────────┼─────────────────────┤
│ 2. The Beautiful Opening│ Vaporware & │ Feature Completeness │
│ (Petach Yafah) │ Deceptive MVPs │ Delta (FCD) │
├─────────────────────────┼─────────────────────────┼─────────────────────┤
│ 3. The Mustaki Seal │ Platform Lock-in & │ Data Portability │
│ (Adhesive Shards) │ Predatory Moats │ Drag (DPD) │
└─────────────────────────┴─────────────────────────┴─────────────────────┘
Insight 1: The "Vessel-Breaking" Rule — Distinguishing Creative Extraction from Systemic Destruction
In paragraph 13, Rabbi Epstein cites the famous Talmudic dictum from Shabbat 146a: "Ein binyan v'sotira b'kelim"—the laws of building and destroying do not apply to portable vessels (kelim), only to permanent structures (ohel or binyan).
He clarifies that you are permitted to break open a barrel to get the food inside because your intent is purely consumptive (le'achol), not constructive. You are not "destroying" the barrel in a halakhic sense because it is a vessel, and you are not "building" anything new; you are simply bypassing a temporary barrier to access utility.
In software engineering and growth hacking, this is the ultimate justification for interoperability, scraping, and unauthorized integrations.
When a startup scrapes public web data or builds an API wrapper around a legacy competitor's platform to help users migrate their data, it is "breaking the vessel to extract the food." The competitor's platform is the vessel; the user's data is the food.
However, the Arukh HaShulchan introduces a critical constraint: you cannot destroy the vessel if it constitutes a permanent structure, or if your act of breaking it permanently ruins its core utility for others.
If you write a scraping script that hits a competitor’s servers so hard that it causes a Denial of Service (DoS), you are not just "breaking a vessel to eat the food." You have crossed into destructive vandalism (soter).
The Decision Rule
You may bypass, wrapper, or scrape an external system to extract underlying utility (e.g., data, user assets) only if your method of extraction does not degrade, crash, or permanently damage the host system’s infrastructure. Your extraction must be surgical, preserving the host's integrity.
[EXTERNAL TARGET SYSTEM]
│
┌───────────────────────┴───────────────────────┐
▼ ▼
[Surgical Extraction] [Systemic Degradation]
- Respects rate limits - Spams API / causes DoS
- Extracts user-owned data - Steals proprietary IP
- Preserves host integrity - Corrupts host database
│ │
▼ ▼
(HALAKHICALLY PERMITTED) (HALAKHICALLY FORBIDDEN)
This aligns with the talmudic discussion in Bava Kamma 60b regarding the ethics of saving oneself at the expense of another's property. While you may sometimes use another's property in emergencies, you must pay for any damage caused.
In business, if your growth hack costs your competitor real server dollars or degrades their performance, you have crossed from "Mensch" to predator.
Insight 2: The "Beautiful Opening" (Petach Yafah) vs. "Crude Breach" Rule — The Ethics of MVPs and Vaporware
In paragraph 15, the Arukh HaShulchan permits breaking the cover of a barrel, "provided that he does not intend to create a beautiful opening (petach yafah) that would make it convenient for continuous use."
If you make a clean, professional, reusable opening, you are no longer just opening a container; you are creating a new vessel (or modifying one to have a new permanent feature), which is a violation of Makeh B'Patish (striking the final blow to complete a tool). If you make a crude, jagged breach just to get the contents out once, it is permitted.
This distinction between a crude breach and a beautiful opening is a masterful metaphor for product development, specifically the boundary between an MVP (Minimum Viable Product) and Vaporware.
[PRODUCT DEVELOPMENT STRATEGY]
│
┌───────────────────────┴───────────────────────┐
▼ ▼
[The Crude Breach] [The Beautiful Opening]
- Honest MVP - Vaporware / Deceptive Demo
- Explicitly temporary - Framed as fully polished
- Solves immediate problem - Conceals structural gaps
- No systemic deception - Violates market trust
│ │
▼ ▼
(ETHICAL HUSTLE) (DECEPTIVE FRAUD)
An MVP is a "crude breach." It is a rough, unpolished workaround designed to solve an immediate customer problem. It isn't pretty, and it isn't meant for permanent enterprise architecture.
As long as you are honest with your customers that this is a beta, a hack, or a manual process behind a sleek landing page (a "Wizard of Oz" MVP), you are acting ethically. You are breaking the barrel to deliver the food immediately.
The ethical breach occurs when you sell a "crude breach" but market it as a "beautiful opening" (petach yafah). This is the world of deceptive vaporware: selling a highly polished, automated enterprise solution to a client when, in reality, you have twenty interns in a low-cost region manually copy-pasting data behind the scenes.
You are representing a temporary, fragile hack as a permanent, engineered asset.
By doing so, you violate the prohibition of Gneivat Da'at (theft of the mind/deception), as derived from Chullin 94a, which forbids creating a false impression in the marketplace.
The Decision Rule
Do not sell a manual workaround or a fragile integration as a finished, automated product. If your product's back-end is a "crude breach" (manual, temporary, hacked), your sales team must not pitch it as a "beautiful opening" (automated, robust, permanent). Honesty in product capability is a non-negotiable ROI protection metric.
Insight 3: The "Mustaki" Rule — The Ethics of Platform Lock-in and Vendor Trapdoors
In paragraph 14, Rabbi Epstein discusses a mustaki—a vessel that was broken and then glued back together with pitch or plaster. Because the vessel’s integrity is entirely dependent on the adhesive, breaking this seal is considered a severe act of destruction, or conversely, re-sealing it is considered a major act of building.
The Arukh HaShulchan forbids breaking a mustaki because the "fix" is so integrated into the vessel that breaking it is akin to breaking the vessel itself, unlike a standard barrel where the lid is distinct from the body.
In the enterprise software and hardware worlds, the mustaki represents predatory vendor lock-in.
[PLATFORM ARCHITECTURE COMPLIANCE]
│
┌───────────────────────┴───────────────────────┐
▼ ▼
[Standard Barrel (Open)] [Mustaki (Predatory)]
- Standard CSV/JSON export - Proprietary file formats
- Open API access - Exorbitant egress fees
- Simple contractual exit - Contractual "trapdoors"
│ │
▼ ▼
(MENSCH PLATFORM) (PREDATORY MOAT)
Some founders build "moats" not by creating superior products, but by deliberately fusing their software to the client's data in a way that makes extraction destructive. They glue the shards together with "pitch and plaster"—proprietary file formats, exorbitant egress fees, and contractual trapdoors.
If a customer wants to leave, they cannot simply open the barrel; they have to shatter their entire business operations to extract their own data.
The Torah demands that we do not build systems that hold our customers hostage. While building a defensible business is legitimate, building a business where the exit cost is artificially engineered to be ruinous is the digital equivalent of a mustaki.
This is closely linked to the prohibition of Ona'ah (exploitation/overreaching) found in Leviticus 25:14, which the Sages in Bava Metzia 51a expanded to include the exploitation of a buyer's lack of options or asymmetrical bargaining power.
The Decision Rule
Your customer retention strategy (moat) must be built on the value of your services, not on the hostage-taking of customer data. If a customer decides to churn, the exit path must be clean. You must provide a standard data export (e.g., CSV, JSON) without charging punitive "egress fees" or intentionally corrupting the data structure upon departure.
Policy Move: The API and Data Extraction Governance Protocol
To translate these three halakhic insights into operational realities, your startup must implement an API and Data Extraction Governance Protocol (ADEGP). This policy governs how your engineering team interacts with external platforms (scraping/integrations) and how your product team designs customer exit options.
[A.D.E.G.P. DECISION TREE]
│
┌────────────────────────┴────────────────────────┐
▼ ▼
[External Integrations] [Internal Offboarding]
- Respect robots.txt - Clear data export
- Rate limits <= 60% capacity - Zero egress fees
- No credential harvesting - No "mustaki" lock-in
1. External Data Extraction (The "Vessel-Breaking" Policy)
When our company scrapes, crawls, or integrates with third-party platforms without an explicit partnership agreement, the engineering team must adhere to the following rules:
- The 60% Rate-Limit Cap: We will never hit an external API or web server at a rate that exceeds 60% of their documented rate limit, or 60% of a standard user's capacity if undocumented. This ensures we do not degrade their system's performance (Soter).
- No Credential Harvesting: We will not ask users for their raw passwords to third-party services to scrape data on their behalf. We must use OAuth or standard export files. Bypassing authentication walls through deceptive means is equivalent to breaking a permanent, professional seal.
- Robots.txt Compliance: We will strictly respect
robots.txtfiles. If a competitor explicitly marks their vessel as "closed" to automated crawlers, bypassing this via rotating proxies to scrape proprietary IP is classified as theft.
2. Product Architecture and Exit Rights (The "Anti-Mustaki" Policy)
When our product team designs our database schemas, data storage, and billing structures, the following rules apply:
- The 1-Click Export Mandate: Every customer, regardless of tier, must have access to a self-service "Export All Data" button in their settings panel. The export must be in a machine-readable, standard format (JSON or CSV).
- Zero Egress Fees for Churn: We will not charge fees for data retrieval or account deletion. The cost of data transfer must be absorbed as a cost of doing business, not weaponized as a churn-prevention mechanism.
- No Proprietary File Lock-In: We will not save customer-generated assets in a proprietary format that can only be opened or edited using our software, unless there is a free, open-source viewer available to the public.
3. Sales Integrity and MVP Disclosure (The "Crude Breach" Policy)
When our sales and product marketing teams bring early-stage features or MVPs to market:
- The Beta Flag Rule: Any feature that relies on manual back-end processing (human-in-the-loop) rather than scalable software engineering must be explicitly labeled as "Beta," "Preview," or "Early Access."
- The Service Level Agreement (SLA) Alignment: We will not sign enterprise SLAs for features that are currently built as "crude breaches." If the feature is manual, the SLA must reflect human processing times, not instantaneous API response times.
The Metric: Integrity-to-Hustle Ratio (IHR)
To measure compliance with this policy, the board will track the Integrity-to-Hustle Ratio (IHR) on a quarterly basis.
$$\text{IHR} = \frac{\text{Revenue Gen. from Open/Compliant APIs} + \text{Self-Service Export Users}}{\text{Total Revenue} + \text{Total Active Users}}$$
A target IHR of > 0.85 indicates that your growth is driven by genuine value creation and open ecosystem participation, rather than predatory lock-in or fragile, unauthorized extraction hacks that expose the company to litigation and technical debt.
Board-Level Question
Context for the Founder
As a startup scales, there is often intense pressure from venture capital board members to "build a moat." Frequently, the easiest way to build a moat is to make your product sticky by making it incredibly painful for customers to leave.
If your VP of Product or Chief Technology Officer comes to a board meeting boasting about high customer retention, you need to know why they are staying. Are they staying because they love your product (value retention), or are they staying because your engineering team has built a mustaki—a complex, tangled web of proprietary formats and data traps that makes leaving operationally impossible?
[BOARD-LEVEL EVALUATION MATRIX]
│
┌──────────────────────┴──────────────────────┐
▼ ▼
[Value Moat (Good)] [Friction Moat (Bad)]
- High NPS - High NPS but high churn fear
- Seamless API integrations - Fragile, undocumented hacks
- Clean data offboarding - Punitive egress pricing
- Sustainable enterprise value - Hidden technical debt
The latter is a "friction moat." It looks great on short-term SaaS metrics (low logo churn), but it is a ticking time bomb. It invites antitrust scrutiny, destroys brand equity, and creates a culture of engineering complacency.
Furthermore, if your engineering team is relying on fragile, unauthorized workarounds of competitors' systems to deliver your core value proposition, your business is built on a "crude breach" that a single API update from your competitor could obliterate overnight.
The Strategic Question to Ask Your Board and Executive Team:
"If our top three enterprise customers decided to migrate to our direct competitor tomorrow, how many hours of engineering support would we have to provide to extract their data, and would our platform require them to pay a financial or operational penalty to access their own intellectual property?
Furthermore, is our core product's utility dependent on unauthorized, fragile workarounds of other platforms' walls that could be patched in a single deployment, or are we building our value on open, sustainable, and legally defensible architectures?"
Expected Outcomes of This Inquiry:
- Technical Debt Exposure: You will force your CTO to map out exactly how many "fragile workarounds" (crude breaches) are currently keeping your product afloat, allowing you to price the risk of competitor API changes.
- Chime-In on Churn Risk: You will identify whether your low churn rate is a vanity metric hiding deep customer resentment, allowing you to proactively improve the product before a disruptor with an "easy migration tool" eats your market share.
- Regulatory Preparedness: You will ensure your company is fully prepared for emerging data-portability regulations (such as GDPR Article 20 or CCPA), transforming ethical compliance into a regulatory shield.
Takeaway
The Arukh HaShulchan Arukh HaShulchan, Orach Chaim 314:13 does not demand that we never break a seal or that we never build workarounds. It recognizes that to access the "food," we must sometimes open the "barrel."
But it draws a razor-sharp line between the clean, purposeful opening of a vessel to extract immediate utility and the permanent, deceptive, or destructive manipulation of systems.
In the startup grind, your hustle must have boundaries:
- Break the barrel, but do not destroy the warehouse. Scraping and integrating are fine; crashing systems and stealing proprietary IP are not.
- Be honest about your hacks. Build "crude breaches" (MVPs) to test the market, but never lie and sell them as "beautiful openings" (finished enterprise software).
- Do not build a mustaki platform. Build your business moat on the brilliance of your product, not on the hostage-taking of your customers' data.
Ethics is not a tax on your growth; it is the structural engineering that keeps your startup from collapsing when the winds of the market shift. Build clean, break surgically, and scale with integrity.
derekhlearning.com