Steve Krouse

Compose update: Aug 2021

Aug 2021 · All Compose Updates

Hello friends,

This is the first update about what's been going on at Compose. In case you forgot, we are making a software development platform for (web) apps with an emphasis on composability, achieved through pure (denotative) functional reactive programming. We like to think of it as a cohesive, even elegant, app development platform.

TL;DR - We're working on a series of demos to validate our biggest assumptions over the next couple months. We hope to have an MVP by the end of 2022. While we're not yet fundraising or hiring, intros are appreciated to investors and prospective team members who are jazzed about our vision for the future of app development.

While we officially incorporated in March 2021, we got distracted for four months with a mostly-unrelated client project. On the bright side, we got experience programming a production web app (40k users) in full-stack Haskell (GHCJS on the frontend). We learned a lot about the functional reactive abstractions that we'd like to build on for Compose, and what will be required for a real-world product.

The Compose of our dreams:

All this, we hope, will allow you to build big (web) apps in small pieces, collaboratively. We imagine programming in bite-sized "tweets" (maybe from your phone one day!) that you can compose into longer "threads" — almost like using Twitter, but instead of only text and images, you're collaboratively constructing an entire application.

We're currently working to validate our two biggest assumptions:

Our first biggest assumption is that our model can, in fact, achieve next-level composability. For example, can you build a user management system that plugs and plays with a user authentication system? Can you add an existing permissioning system? How about plug-and-plays with a blogging system? Can you seamlessly add commenting on the blog posts by importing a commenting module that someone else built?

Unlike in a traditional app, where all persisted state flow through the same server and database, in Compose, each of these separate components of functionality are vertical slices of your app that cut across the entire stack. Thus you should be able to build them separately, and only compose them when necessary. We hope this will enable vastly better organized code and much richer collaboration. We're testing this paradigm by building larger programs in a toy prototype of the platform.

Our second biggest assumption is that sufficiently many other programmers share our vision for the future of app development. In short: would people use Compose? In particular, we have a number of specific questions about how to package our product. For example, is it Haskell vs TypeScript vs another base language? Should we initially launch with a web notebook or a more traditional programming language you can run on locally and use your preferred text editor? What open-source or source-available license will allow us to build a vibrant community but still allow us to capture some of the value we create?

We're going to release a series of prototypes and smoke-and-mirrors demos throughout the next few months to confirm or invalidate our hunches on these and many other questions. For our first post, we've been creating a mockup of a web notebook with Haskell syntax that follows the original Rails demo (a quick blogging platform of just posts and comments). If this fails to resonate with folks, we may move to a TypeScript implementation that works locally with your preferred development environment.

My wife, Sarah Meyohas, makes art with real smoke and mirrors!
My wife, Sarah Meyohas, makes art with real smoke and mirrors!

When I described Compose to my dad he asked, "So will managers buy it because it increases productivity?"

I thought about it. "Well I guess. But really I'm hoping that engineers will just love to use it because the tool will give them joy and that addictive flow feeling, almost like a video game." If we can achieve a lovable tool, we'll find a way to charge for it. A recent relevant PG quote:

In many fields, people don't like to work and resent their employer for making them work harder than they want to. But with programmers it's often reversed. There are lots of programmers who resent their employer for not letting them spend enough time programming.

- Paul Graham (Twitter)

So when will we launch a tool? Paraphrasing Emmanuel Straschnov of Bubble, "The MVP of an app maker needs to allow others to build their MVPs." We aim to have this level of functionality by the end of 2022, but it's unclear which path we'll take to get there. We're hoping that various early prototypes will be useful enough to release on their own before the "full MVP", which would allow us to work more iteratively and in partnership with early users.

If you know angels that really care about developer experience, I'd appreciate intros. I'm looking for partners that really understand and believe in our vision. I'm hoping releasing demos and prototypes will help those folks find us. Not every investor has good taste in programming languages!

Same goes for engineers or designers, yourselves included! We're not explicitly growing the team at the moment, but it's always good to get to know folks who are excited about what we're up to.

More soon!

Steve and Adriaan