Not all those who Wandel are lost

When Gandalf writes to Frodo, asking him to seek out Strider aka Aragorn In JRR Tolkein’s seminal “Fellowship of the Ring”, he leaves a short poem in the footnotes with the immortal line “Not all those who wander are lost”. Little did JRR Tolkien know that I would be using this line to explain our journey to launching Wandel and how we got here. 

When myself and Florian partnered to create Senzo X our plan was to build AI powered serverless applications for ourselves, and on a turn-key basis for other companies. With every application we build, we had two explicit goals beyond the specific success criteria for the application. These goals were that we needed to learn, and to have reusable code we can take to the next project. The payoff would be that after a few projects we would have a library of components that we could take into any project, and significant provable knowledge in how to do this, allowing us to rapidly build scalable applications.

The first application we built with this mindset was an AI powered iOS chat application called HeyBuddy. There were a few players in this space, which gave us an indication that there was a viable market, and we thought we could build something that meets most user’s needs whilst keeping costs down. 

We misjudged the costs. We were able to build and launch an AI powered chatbot, but the costs meant it wasn’t viable, based on our own internal criteria. A few weeks before launch we did a cost analysis and found that we would be making a loss on monthly subscriptions with engaged users. With engaged users being the users most likely to pay we were in a scenario where we had built an application that if people wanted it we couldn’t afford to run. 

It was a scenario where we had to build the core of the application to be in a position to fully model the costs. 

The culprit was the costs of LLM platforms. Due to the stateless nature of LLM services, you have to include the context of a conversation into every prompt for the response to make sense. This means input size for each prompt keeps expanding, and with it the costs. We could limit how much conversation history we appended to the prompt, then the question becomes how far back do you limit it too. If you don’t go back far enough then the user experience is degraded, if you append too much history to each prompt then you make a loss. We know this problem isn’t unique to what we built, but rather a problem of the stateless nature of how LLMs work.

Even with the declining cost of inference from the various LLM providers, and new features like prompt caching, it takes us from making a loss to a small profit. We need more than a small gross profit to justify the time investment we had spent in building this platform. 

If we were venture funded the calculation would be different, as we would have the runway to wait for inference costs to reduce further. We made the decision to stop feature development on HeyBuddy, get it on the App Store as a portfolio app and move on.

It had been six months since starting HeyBuddy, and we had parked it. The question for us was “what was next?”. We explored multiple AI based use cases. After being burnt once already we spent more time looking at the financial viability up front. Most potential use cases fell into one of two categories. Either the use case required significant funding to build a viable business or the underlying LLM costs meant the profit margin was too small for it to be worth our time. 

The one use case that stood out for us was transcription and summarisation. Speech to text transformer models have dramatically improved the state of transcription services over the last few years, reducing cost and improving accuracy. When combined with LLMs for summarisation it becomes a productivity hack enabling you to use your voice for multiple use cases. There is also market validation in this approach by the sheer number of applications, services and tutorials out there that provide this capability. From a financial perspective single shot transcription and summarisation doesn’t have the ever expanding context problem of persona based chat applications. 

We had found a use case that we knew people wanted, and met our financial criteria. On the flip side it’s a crowded market, with a low technical barrier to entry, and we were late to the game. To compound this, Apple announced transcription and summarisation as a feature of the new Apple Notes in the upcoming iOS 18 and Macos Sequoia. Being in a crowded market is fine, if you can differentiate.  We quickly identified a few ways we could potentially differentiate, and got to building. 

It took us approximately 6 weeks to get something up and running internally. We were able to re-use almost 80% of the code from HeyBuddy. Every application or service has a mix of unique requirements and common constraints that are found in the majority of applications. We find the majority of the code required to build an application is used in meeting the common constraints. 

For us that common code included tooling such as infrastructure as code definitions, CI/CD configurations, management scripts and the end to end test harness we built. It included integration code into things like authentication and payments services. We have ancillary applications like a management dashboard which we repurposed quickly. We have a solid Swift app template that allowed us to rapidly get the early prototype iOS application out. 

Our early strategy for Senzo X of building applications that would allow us reuse components in later projects was paying dividends. After the fast start things slowed down. It took us another 6 weeks to get the application into the Apple App Store. 

The challenge with launching into an existing market with multiple competitors is that there is already a market expectation of features that the application should have. The minimum in Minimum Viable Product is not so minimum anymore. After the first 6 weeks we had a product that probably would have been viable in August 2023, but we launched in August 2024. 

We required a higher fidelity product that did more than transcription and summarisation. There was also core foundational work that needed to be done to allow us to build differentiating features out in the future. At launch we had a product that matched the majority of features of competitors, and will allow us to add new features quickly.

Many years ago I worked with a successful startup veteran from the early 90’s who was adamant that the best way to compete in an existing market is to be cheaper, faster and better than the competition. Easy to say, hard to achieve. We’re already 50% cheaper on our annual plan than the majority of our competitors with an equivalent or better product. We have a financial model that allows us to do this without compromising viability and we’ve only just begun.

After a rocky start to Senzo X, and a lesson learned, Wandel is launched, and we are not lost.