We used to talk about the "minimum-viable-product" or MVP back in the 2000's. I'm not sure where the term comes from (maybe the Agile manifesto?) but the idea is, what is the least you can build to have something that does whatever you're trying to do.
I'd further qualify that it has to be truly useful to the person you're making it for (even if that's yourself). That's important for the "product" part, IMHO.
Like many useful heuristics I've seen the term abused as a way to do a half-assed job, but I do think that it's useful as a test or metric, or a way to get yourself un-stuck.
I'm thinking about the MVP of The Beaver this morning and how I can "scope" the project in a way that it feels more tractable. Something I'm coming to terms with is that if I'm going to make a commercial venture out of the thing I'm going to need help from other people, but it's very tempting to hold-off on that until I have some kind of prototype that they can use to get a taste of the experience. I've written before about why I think that's important.
I suppose that was what the SwyftCard was about, a way to give people a taste of what a complete Swyft computer would feel like using a single printed circuit board compatible with the millions of Apple //e's already out there. Taking that as a clue the first thought that comes to mind is to focus on creating the software side of The Beaver, and an emulator that would allow it to be used on an existing, common computer. Taken to the extreme, it would be delivered via web browser, resulting in virtually universal compatibility.
But how much of The Beaver Experience (TBX) can be conveyed via a web browser? This is a good question because answering it requires reflection on what is most important about TBX, and when I think about that, I think about how I sold myself on the idea.
Setting-aside the hardware, what makes TBX compelling to me is flow. Working with The Beaver provides the benefits of an electronic workspace without the drag caused by contemporary computers. That drag comes in the form of interruptions, unreliability, untrainability and simply being slow computers. The Beaver lets you work, by not getting in the way but also by not trying to do your work for you. The Beaver lets you work and work-out your mind, it lets you get smarter the more you work with it. It lets you get faster, by being fully keyboard-focused and controlled by a handful of keyboard commands that you can commit to muscle memory. It keeps your work safe so you don't need to be preoccupied about loosing it. It provides the dynamism and acceleration of being programmable without requiring you to become a "programmer". It provides a way to share your work without making it impossible to understand what is public and what is private. The bottom line is that when you have time to work with The Beaver, you can get more work done and come-away from the experience healthier.
So how much of this experience could be shoehorned into something that runs in a web browser?
We can't do much about the drag. A browser runs on a computer that has all the interruptions, unreliability, untrainability and slowness we're trying to get away from. It might be possible to achieve some of this by prescribing a process to prepare the computer for the experience, but even if someone tries to configure a contemporary computer this way, there's only so much you can do. If that drag could be overcome, some of the other benefits of the experience are easier to implement, and while not using a custom keyboard will limit some of the ability to attain muscle memory for all of The Beaver's features, something close to it could be possible. Keeping work safe is not as sure as it will be on the real thing, but it could be better than the alternatives, and the dynamism of being able to write and run executable code, etc. inline is achievable as well. Sharing work should also be possible (although it might require an additional interface/translation layer on top of the current Public Library implementation).
Some of the drag could be eliminated by taking a slightly different route, by providing a stand-alone executable instead of something that runs in a browser at the cost of compatibility and distributability. I think this is particularly problematic when it comes to a Beaver display with graphics capability.
A step further would be to make a bootable version of The Beaver software that could be used with contemporary machines. This could be accomplished using something like an existing Linux distro that boots directly into a VM running The Beaver's native software, but this further narrows the number of people who can easily experience it.
It's tough to slide the scale to the sweet-spot with this, and to be honest the more I think about it the more it just feels like compromise. It seems like pursuing the software separately from the hardware makes sense, and that waiting for the hardware to be ready means waiting a long time before I can share the experience, but is the hardware really that "hard"? I could be shielded by the comfort of naivete but I'm not sure that realizing the hardware (at least in a bespoke prototype form) is any harder than realizing the software, and I think that the hardware is a very important part of the experience. I would argue that using The Beaver as a proof-of-concept for the FPGA-based general-purpose computer is maybe more important than The Beaver itself.
So maybe all the practicality of creating an easily distributable software-only version of The Beaver is not as practical as it might seem, when you consider the overarching goals I have for the project. While I genuinely believe that experiencing The Beaver will be pivotal to creating the kind of demand necessary to create a sustainable living out of it, I'm not convinced that there's a shortcut to providing that experience that doesn't involve working the hardware and software together.
Jason J. Gullickson, 2026