April 30th, 2022 Building a company around a toy requires embracing the toyness (and thinking beyond Excel) By Jeffrey M. Barber

So, progress is going slow as I’m on the pathless path wandering.

It’s fantastic to wander, but I realized after reading How Tech Loses Out that I’m an anti-salesman and negative marketer. This section caused a bit of reflection:

So initially, your technical people are actually negative marketing. They recommend that people do not use your product, because they know how it was built. And like yeah, don’t, don’t buy it. So initially, the marketing skills of a company are actually negative.

There are a few issues that make life tough to launch the business with things in rough shape (at least from my perspective as the sausage maker), but I’m also grateful because I’m not bound by the prison of expectations (service is currently in early-access preview mode). However, I’ve considered what would the path be like to start raising funds and hiring people to go wider faster. Ultimately, I’m a true believer, and I’m not fully proselytizing for a variety of reasons.

I want to be clear that I’m not yet ready to hire let alone take on investors or partners (yet), but I have to think about the fundamental game that I’m playing. Right now, Adama is thin and light in many areas. I’m working towards shipping an online hearts game that was built with the online WYSIWYG editor. Once I launch the skeleton of the IDE, I can shop the ideas around more freely.

Since Adama was built around reactivity, the language provides a hybrid engine which could sit under the love child of Access or Excel, so I could pivot into very practical applications with the server-less platform. The dimensions of growth are plentiful and beautiful, and the number of domains possible with low latency compute centric storage feel infinite.

There are however some hard walls. For instance, a key benefit of Adama is that there is no disk or network access which means you deal with less problems. It’s a closed box (almost like a database) which is absolutely fantastic for privacy, but for the majority of applications this can be a disappointment for the dream of a complete backend-as-a-service. This requires some kind of future solution.

We are allowed to dream, so the question is how to extend Adama without sacrificing the spirit. This requires getting concrete about the game being played within the model posed by Adama. So, let’s dream beyond a handful of fun card games.

RxHTML

The meta problem of the IDE is the web framework problem. In a nutshell, the web browser is great but unwieldy. This heavy handed nature is the source behind every single web framework out there, and I feel that pain acutely. This is the basis for investing in yet another template language called RxHTML. The key differentiator of this new template language is that it is 100% XML and binds HTML directly to a reactive data tree.

This reactive data tree is precisely the output of Adama, but something interesting is happening as I pursue this. The reactivity is making the web browser into a more classical dumb terminal with all complexity on the server. For the rare bit of front-end complexity, the best thing to do is to wrap it within a Web Component. I’m looking at Shoelace as the perfect companion library to do things like color picking.

Pulling this thread may allow me to take the IDE into a meta place around “no code” or “low code” where all you have to really master is Adama (which can be greatly accelerated by various editors). Perhaps, “mastering Adama” is a stretch for that market, but I can also take an Excel workbook and transcribe the bulk of it to an Adama sheet and a JSON document. This is exciting in a way, and this is another vertical to explore.

Remote calls

The biggest gap in Adama is the isolation. A canonical example of something that I’d like Adama to support is a notification via SMS, Discord, or any of the phone provider notification systems. This requires contending with failures modes both of the self-inflicted kind (too many calls), legit errors (remote service down), and abusive errors (user has banned you from invoking this).

Fortunately, Adama has a model to build external calls by treating a remote service as a client, and the missing piece is an internal Agent to act like a client to broker messages between Adama and whatever service. Building this agent within Adama while using Adama as storage is the key for making this great, but this also creates a “how do I bring so many services to Adama” without too much undue burden.

This creates a massive integrator problem as authentication between Adama and various third party services becomes a nightmare of sorts. My strategy here is to focus on things that immediately add value to board games like Discord or device notifications.

Multi-region storage

I’m still toying with various ideas around how to launch with exceptional latency whilst satisfying typical expectations of durability and availability. I’m excited about redpanda as a competitor to Kafka since I’m not a fan of Kafka. I’ve decided that using redpanda is the right approach for half of my problem whilst I trade off availability due to needs of consistency. As a consequence, I’ve decided to pull out the storage protocol as a separate process and design a new globally aware protocol for routing.

One of the things I have yet to contend with is how to handle global documents. Do I want to follow the AWS model and have regions be isolated? I think the AWS model is a giant pain in the ass, so I’m going to design for multi-regional documents such that documents have a temporary home in the closest region to the first user opening it. When the last user disconnects, an archiving process will return the state to the untethered state. This design has some ramifications.

First, I have to decide how to archive state, and I feel like Amazon S3 is perfect for this task. I trust Amazon S3 because I worked there. Second, I need multi-region routing. User A connects to region X and binds document D to region X, and User B connects to region Y and wishes to connect to document D. This requires either a region hop of some kind, and the question is which layer is responsible for it. Since there are only two tiers, I can consider both and these thoughts are feeding into the new storage tier design.

Go to market requirements

Ultimately, I’m thinking about what it means to stop wandering and getting to the market with something. I’m probably a few years off, and my thinking has shifted towards building my vertical supply chain. I like the idea of having a robust storage tier which uses as few of things as possible. I like the idea of staying very close to the web browser to avoid framework churn. Afterall, I have JavaScript from decades ago that still works.

I think once I get RxHTML workable and available within the IDE, I have a minimum toy to launch to drive the feedback cycle. Not only can I launch, but real things could be constructed to start validating various hypotheses beyond board games. It’s exciting, but now I return to the wandering path of pathlessness.