Engineering Independence: How One Founder Conquered the "Onboarding Tax" with Local Infrastructure as Code

Executive Overview

The transition from the predictable security of an established enterprise to the high-stakes, tabula rasa reality of a technology startup is often characterized by a violent acceleration of time. For engineers accustomed to navigating well-trodden corporate pathways, the sudden freedom—and simultaneous exposure—of a completely blank slate can be jarring. When veteran software architect and developer practices specialist found himself suddenly made redundant from a position where he defined patterns and practices for a high-performance team, he faced this exact crossroads.

Rather than immediately succumbing to the anxious impulse to aggressively churn out lines of business logic on a freshly provisioned laptop, he chose a path rooted in rigorous discipline: true craftsmanship rejects the illusion of hurried progress.

Drawing from years of hard-won wisdom in cloud architecture—where manual console clicking ("click-ops") is universally recognized as a technical debt time-bomb—the founder identified a glaring blind spot in the modern developer workstation lifecycle. If relying on Infrastructure as Code (IaC) is an absolute imperative for cloud environments to ensure auditability, consistency, and disaster recovery, why do software teams still treat local developer environments like the Wild West of manual installers and rogue command-line scripts?

This insight catalyzed the creation of rig, a lightweight, POSIX-compliant developer toolchain dispatcher and provisioning system built entirely for /bin/sh. Designed to separate hardware from the environment using IaC principles, rig eliminates what the industry has long accepted as an unavoidable hidden cost: the "Onboarding Tax." By treating the local machine as a reproducible artifact rather than a fragile collection of tribal knowledge and wiki pages, this approach reduces multi-week onboarding nightmares and hardware failure recovery times to mere minutes.

This article explores the systemic inefficiencies of traditional developer onboarding, the architectural philosophy behind local environment IaC, the mechanics of rig, and how this foundational engineering discipline sets the stage for sustainable startup growth and human-centric artificial intelligence integration.

Detailed Chronology: From Corporate Redundancy to Startup Genesis

The Violent Acceleration of the Blank Slate

The journey began with an abrupt corporate redundancy. Having spent years refining patterns, practices, and high-performance team workflows within a structured enterprise, the author was suddenly cast out into the open market. The safety net of legacy systems, established CI/CD pipelines, and standardized corporate hardware was gone overnight.

When a replacement refurbished laptop finally arrived after a frustrating initial delay—requiring an immediate return, wipe, and a week-long wait for repairs—the psychological urge to rush was palpable. The immediate temptation was to tear through software installations, configure local environments on the fly, and begin hammering out application code to prove immediate startup velocity.

However, decades of engineering discipline intervened. The author recognized that yielding to the pressure of artificial urgency creates foundational instability. Just as rushing a cloud architecture deployment without automation leads to un-auditable technical debt, rushing a local developer environment sets up systemic drift, environment fragmentation, and hidden bugs that inevitably surface weeks down the line.

Forging the Philosophy in the Fires of Knowledge Transfer

The conviction to spend the crucial first week of the startup writing zero business logic did not emerge from a theoretical textbook or an abstract blog post. It was forged in the grueling trenches of the author’s final four months at their previous corporate role.

During this period, the primary responsibility was executing a comprehensive Knowledge Transfer (KT) to an incoming team of talented engineers. Despite their technical competence, these incoming developers were entirely unfamiliar with the company’s intricate ecosystem. Furthermore, none of the legacy team members would remain to guide them through the inevitable edge cases.

The mandate was monumental: condense ten years of deep, institutional system knowledge into a compressed, high-pressure onboarding window.

As the KT process unfolded, a critical bottleneck revealed itself. While architectural concepts and high-level system designs could be communicated through diagrams and documentation, the real friction lived entirely within the developer laptop environment.

On paper, human resources and standard onboarding metrics claimed that a new developer could be "up and running" in approximately one week. In reality, this was a dangerous surface-layer illusion. For months after that initial week, the new hires continually slammed into silent, productivity-killing roadblocks.

Day after day, the author found themselves playing tech-support triage:

• "Oh, you need to configure your SSH config this way to access that staging cluster."
• "Right, I forgot—you need this custom shell script to establish an AWS SSM tunnel to bypass the corporate gateway."

Onboarding was revealed to be not a single, decisive event, but a slow, agonizing, manual drip-feed of wiki pages, obsolete shell scripts, and fragile tribal knowledge. It was "wiki-ops" at its absolute worst. Tasks that should have been executed in minutes dragged on for weeks, sapping the morale of incoming engineers and grinding the productivity of veteran peers to a halt as they were forced to constantly context-switch to debug local paths and missing dependencies.

Supporting Context & Metrics: The Architectural Anatomy of rig

To eradicate the Onboarding Tax permanently and ensure that future hardware failures or team expansions would not result in operational paralysis, the author spent their first several days building rig.

Etymology and Design Constraints

Deriving its name from the nautical verb to equip a vessel with sails, standing tackle, and running gear, rig is engineered to be a minimalist, highly efficient toolchain dispatcher. To guarantee execution across virtually any POSIX-compliant environment without triggering dependency hell, the entire system is written strictly for /bin/sh. This intentional architectural choice ensures that it runs with zero pre-requisites across macOS, diverse Linux distributions, and containerized CI/CD runners.

(Note: While fully architected for multi-platform support, the author notes that Linux configurations—such as distribution-specific brew packages—are currently being finalized as Linux testing environments are fully integrated.)

Frictionless Installation and Dynamic Environment Injection

Setting up a fully standardized, production-ready developer workstation is reduced to an intuitive, two-step operation:

# Clone the repository
git clone https://github.com/your-user/rig.git
cd rig && ./rig install

Upon execution, rig safely injects a single, clean, easily auditable hook into the developer’s shell profile (.zshrc or .bashrc), demarcated clearly by a # rig-tools comment:

eval "$("/path/to/rig-tools/rig" env)" # rig-tools

Rather than baking static paths and environment variables directly into the shell profile—which creates update nightmares down the road—this single line dynamically evaluates the environment returned by rig. As the underlying developer tooling evolves, the shell adapts seamlessly without requiring manual profile re-installations.

Elective vs. Prescriptive: Rejecting the Corporate Straightjacket

A common critique in enterprise workstation management is the reliance on heavyweight configuration managers like Chef, Puppet, or rigid enterprise Mobile Device Management (MDM) profiles. While these tools aim for compliance, they often lock developers into sterile, authoritarian boxes. They dictate exact local machine behaviors, strip away individual engineering preferences, and foster a stifling developer experience (DX) that frustrates top-tier talent.

rig deliberately takes the opposite philosophical stance: it is elective, not prescriptive.

By leveraging a modular domain architecture—cleanly separating language runtimes from operational tools—and adhering strictly to XDG Base Directory standards (storing persistent, non-clobbering key-value states in ~/.config/rig/config), rig acts as a high-performance launchpad rather than a restrictive straightjacket.

It guarantees that every developer shares an identical, reliable baseline environment for core company projects, while leaving them completely free to customize their editors, local directory structures, and shell preferences.

Core CLI Interface and Capabilities

The functional scope of rig is exposed through a clean, self-documenting command-line interface:

Usage: rig <command> [options]

Commands:
  install
      Initiate the install script for the current platform
  update
      Update installed packages and toolchains
  doctor
      Verify environment health and configuration drift
  tool <-l|tool>
      Configure/Install provided tool.
      Use "rig tool -l" to list available tools.
      Current: 1password, aws, colima, gcloud, git, localstack, obsidian,
               orbstack, tmux, vim

  lang <-l|lang>
      Configure/Install provided language support.
      Use "rig lang -l" to list available languages
      Current: java

  env
      Print environment include for use in shell scripts.
      NOTE: This will be added by 'install' to your environment, e.g.
            eval "$("/home/your-name/devel/rig-tools/rig" env)"

  config [-n] <key> [new-value]
      Get the current value or update the existing value with [new-value] if
      provided. The '-n' flag when present will not clobber existing values.

  help
      Show this help

Config Values:
  SKIP_INCLUDE  When 'true', install/update/doctor commands will not attempt
                to modify the shell environment. Defaults to false.

Through commands like rig doctor (which verifies that the local environment has not drifted from the desired state), rig update, and modular language/tool hooks, workstation maintenance is transformed from a multi-day engineering drain into a background task taking less than five minutes.

Official Statements & Engineering Philosophy

Reflecting on the psychological and operational shift from enterprise employee to independent founder, the philosophy driving rig can be distilled into a few core tenets held by modern infrastructure pioneers:

"True craftsmanship rejects the illusion of hurried progress. If ‘click-ops’ is an unpardonable sin in cloud infrastructure, then clicking through manual installers and executing rogue shell commands on your local machine should be viewed with the exact same level of architectural disdain."

This mindset bridges the gap between personal productivity and enterprise scalability. By treating the local machine as code, the author established an ironclad operational invariant: Hardware is ephemeral; environment configuration is immutable code.

If a laptop physically fails, suffers catastrophic data corruption, or is lost while traveling, the recovery protocol no longer involves panicked calls to IT or digging through outdated internal wikis. The engineer simply procures replacement hardware, executes rig install, and is fully operational—writing, testing, and shipping code—in under five minutes.

Coupled with strict operational discipline regarding version control—encapsulated by the startup rule: "If you didn’t commit and push your code to a branch, you didn’t work today"—the founder achieved an effective zero-downtime developer productivity baseline by the end of week one.

Future Outlook: The "Anti-AI AI Strategy" and Documentation-First Contracts

With the local infrastructure foundation securely codified and automated via rig, the author’s attention has pivoted toward solving another systemic corporate bottleneck: institutional knowledge retention and documentation architecture.

In upcoming engineering releases, the author plans to unveil what they term an "Anti-AI AI Strategy." In an era where artificial intelligence tools are frequently deployed to replace human creativity or generate oceans of unvetted boilerplate, this strategy aims to invert the paradigm. The core philosophy asserts that true value stems from human creativity, but the human mind must be empowered with precise, high-fidelity tooling to perform at its peak.

The upcoming initiative centers on establishing a universal contract for software projects that enforces a documentation-first development lifecycle. Key components of this upcoming roadmap include:

1. Centralized Architectural Pipelines: Standardizing documentation generation directly into shared corporate cloud drives (e.g., Google Drive Architecture repositories) as a mandatory component of the CI/CD and pull request lifecycle.
2. Dual-Purpose Documentation: Structuring documents so they serve a dual purpose: perfectly readable and intuitive for human engineers, while simultaneously structured to provide Gemini Notebooks and advanced LLMs with hyper-accurate, contextual awareness of the system actors interact with.

By applying the rigorous, automated discipline of Infrastructure as Code to the local machine first, this startup has proven that taking a deliberate pause to build internal tooling pays exponential dividends. As the technology landscape continues to accelerate, the architects who build sustainable foundations will consistently outpace those trapped running manual installers in the dark.