Prosaurus — Cherry Blossom Development

Prosaurus is an in-house project that serves as both a real-world product and a living demonstration of what Cherry Blossom Development builds. It is a social productivity platform designed for teams, communities and individuals — combining real-time messaging, content sharing, and user management into a single cohesive experience.

The project spans every layer of modern software: a cloud-deployed backend, a responsive web client, a native Android app, and a native iOS app. A fully automated test suite also validates that all three are in working order. Every component is built, deployed, and maintained by the Cherry Blossom Development team.

Visit Prosaurus →

Platform Overview

Web Application

The Prosaurus web app is a single-page application built with Vue 3. It delivers a fully responsive experience in the browser, with real-time updates powered by Socket.IO. Users can manage profiles, participate in group discussions, exchange direct messages, and interact with a customizable dashboard of content widgets.

Vue 3 with Vite
Pinia for state management
Socket.IO for real-time messaging
Deployed as static files via nginx on AWS EC2

Android App

The Android application is built natively in Kotlin using Jetpack Compose for the UI. It connects to the same backend API as the web app, giving users the full Prosaurus experience on their Android devices. Authentication uses encrypted local storage, and all network communication is secured over HTTPS.

Kotlin with Jetpack Compose
Retrofit for type-safe API calls
Coroutines for async operations
EncryptedSharedPreferences for secure token storage
Soon to be available on Google Play

iOS App

An iOS companion to the Android app is technically live in the App store right now, however we are still fixing issues. It shares the same backend API and has feature parity with the Android and web clients, giving Prosaurus users a native experience across all major mobile platforms.

Native Swift development
SwiftUI interface
Shared backend API with Android and web
Coming to the App Store soon

Backend & Infrastructure

All three clients are powered by a single backend API built on Node.js and Express, running inside a Docker container on an AWS EC2 instance. A Redis pub/sub adapter enables Socket.IO to broadcast real-time events across multiple server instances, laying the foundation for horizontal scaling. nginx handles SSL termination and routes traffic between the static frontend and the backend container.

Key backend technologies

Node.js + Express REST API
MariaDB for persistent data storage
Socket.IO with Redis adapter for real-time communication
Docker for containerized backend deployment
nginx as reverse proxy with Let’s Encrypt SSL
AWS EC2 hosting

Automated Testing

Prosaurus includes a dedicated end-to-end test suite that covers both the web, Android and iOS clients. Tests run against an isolated test database with seeded users and known state, so each run is clean and repeatable. The test infrastructure is maintained alongside the product code and is run continuously as new features are developed.

Testing stack

WebdriverIO as the primary test framework
Appium for Android and iPhone device automation
Mocha test runner with structured reporting
Isolated breakroom_test database with schema syncable to production or development environments
Page object model for maintainable, reusable selectors
Tests cover authentication, navigation, real-time messaging, and user management flows (at the moment, we are adding more every day)

Development Philosophy

Why Native Apps?

In the past, we have built apps using various frameworks and we have all had some success with that approach, but also there were drawbacks. One of the main problems with framework based development is that the framework has to adapt to changes in the native code and that can take time. By using the native languages of the applications (Kotlin and Swift) we can avoid this problem altogether.

The other problem with framework based development is that there is an underlaying assumption that iPhone users are the same as Android users and this is absolutely not the case. Each set of users expects different things which makes it tough to have one codebase for all.

Language Choices

Beyond the choices for app development are the decisions for which languages to use for the web application and for the backend itself. As a team, Cherry Blossom Development have used dozens of languages and frameworks over the past 25 years.

While we each have our own preferences, I have made the decision to go with Vue.js on the front end and Express.js on the backend for a couple of reasons:

Simplicity - One of the main concerns with all of the frameworks is complexity. While in many cases the added complexity and abstraction provided in frameworks like Angular and React is good for human development, our theory is that it actually makes automated development more difficult. Our code is now almost 100% created by agentic coding agents so we need it to be optimized for those tools. Vue.js is a simpler framework and I have found it to be very efficient to develop using this and the Agent.
Back end vs Front End - There are many options out there for each, and there are more and more that integrate both into one (like Next.js which we researched). At the end of the day, we decided to go with Express.js because again, like Vue.js it's simple. Also it's old so there is lots of documentation for the robot to consume on how to build it correctly.

Scalability

At first, we messed around with Docker, Kubernetes and Terraform to make a scalable system. Eventually we realized that Ansible was also a good tool to have. At the end of the day however, we determined that most of these things were a pre-optimization. With no real traffic yet, there was not any good reason to spend the money on all of these tools.

Our one exception to that is Docker. We did build our system within a docker container so that some day if we have to scale it will be easier becasue it will already be containerized.

Another thing we added after a bit of messing with it was Redis. While Redis was not necesarily needed at this early stage, it did help with the development process by allowing us to connect production and test chat together which made it much easier to test in general.