Everything described so far — the trust, the governance model, the automation focus — isn’t just meant to describe one company. It’s meant to be a method other people could use too, if they’re facing a similar problem: no capital to start with, real skills and tools, and a desire to build something that stays owned by the people who build it.
I’m intending to pioneer this method myself, through EduBot and Pizza, as they develop — pairing automation expertise with subject-matter expertise, building and owning as much of the value chain as practical, and governing the result in a way designed to resist being sold out or eroded over time. None of this is a track record yet. It’s an attempt, in progress, that you’re welcome to watch — and if it works, to copy.
Open-source and makerspace communities are a particularly natural fit for this. These communities already know how to pool tools, skills, and volunteer labor toward a shared project. The bootstrap method described on this site is one way that kind of collective effort could convert into something permanent — owned by the people who built it, rather than staying informal, or eventually dissolving, or getting acquired by someone who didn’t build it.
One specific possibility worth naming: many makerspaces struggle to cover rent on membership income alone. A makerspace and an EOT-style company could share the same physical plant — the same building, and in some cases the same equipment — used for members' personal projects during some hours, and product production runs during others. This could go further than simple space-sharing: some equipment or processes are complex or genuinely risky to operate, and training every interested member to run them safely may not be worth the overhead or risk. An EOT-style operation embedded in the same space could instead perform that work on a member’s behalf — the maker brings the idea and design, the EOT-side operators (who already run the equipment daily as part of production work) handle the machine — which is a fairly natural extension of the automation-expert/SME-pairing pattern this project already relies on elsewhere.
There’s also a specific, timely reason this path is worth serious consideration right now. Software hiring — especially entry-level and generalist roles — has gotten measurably harder over the past couple of years, and a meaningful share of that is tied to AI tools now doing the kind of routine work that used to train junior engineers. If you’re caught in that squeeze, or you can see something similar coming in your own field, this path doesn’t require someone to hire you. It requires tools, skill, and a willingness to build something yourself — ideally alongside others in the same position.
(I have a stronger, more personal view of where this is heading — why I think this round of automation is different from past waves, and why I don’t think today’s job market squeeze is temporary. That’s a longer argument, grounded in 50 years of hands-on experience across the exact technologies converging right now. Read it here: Why I think this time is different — but I want to be clear that’s my own reasoned opinion, not a settled fact, and this page’s core point stands without it.)
This same pattern — automation expertise paired with domain expertise — shows up in Repeating automation patterns and Pairing automation experts with subject-matter experts, and in Vertical Integration: Owning the Whole Chain as a related strategy once a project is underway. And if this method ever does spread beyond one company, Toward a network of mutual support describes a far-off possibility for what could come after that.