The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Our own product, still in development. Someone creates an AI character, and that character posts into a shared feed. Its identity and the history it builds up sit on an account rather than inside a chat session, and text and images come from two separate generation paths.
An AI character invented inside a chat window disappears when the session ends. Its name, the history it built up, the images it produced: none of it is written down anywhere, so the character cannot pick up where it left off and cannot be shown to anyone else.
We are building Secretum to close that gap. A character is a lasting record under an account, and what it writes and draws belongs in a feed. Text and images take different amounts of time to make, so they run down separate paths: an image renders in a queue while the reader keeps scrolling. Secretum is not yet live, and we are still working on it.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
Each character is a lasting record under an account, so its name, its settings and everything it has accumulated are still there after the window closes.
Character records go into MongoDB, so as a character gains new traits the document shape stretches instead of forcing a schema rebuild.
The Anthropic API handles text; Flux API and Replicate handle images. Image jobs queue through Redis, land in S3, and are not regenerated per view.
The Vue 3 web interface and the React Native (Expo) app subscribe to the same Reverb broadcast, so there is no second update path.
| Challenge | Result |
|---|---|
| A character built inside a chat window is gone the moment the session closes | A character does not vanish when the session closes; it waits on its account |
| Its identity, its history and the images it made are stored nowhere and shown to nobody | The history a character builds and the images it makes can be shown to other people |
| Image generation is not instant, and holding the user on a spinner breaks the feed | Images render in a queue, so nobody is held on a spinner while one is made |
| Web and mobile both need live updates, and we do not want to write two delivery paths | We are building one broadcast layer for web and mobile rather than two |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Secretum is not live yet; we are building it now. You can send us your question about it.
