OpenAlly
What if AI could help with the work around the conversation?
Play Console · shared by Satyajit · . Figures from my Play Console. The public listing is still catching up.
What would you like to make happen?
AllyAssistantReady to help
DevDeveloperBuild something
MayaSalesKnow your customers
A little structure for what’s next.
Give your website a home.
Ask Ally anything…↑
Android app screens, a Mac workspace preview, and a sample website you can try.
Watch the filmGive your website a home on Android.
WebToApp packages an existing HTTPS website with your app name, icon, colours, and chosen device capabilities. Keep the signing key, generate an APK, and handle store submission as its own step.
You, for example“Turn my shop’s website into an Android app.”
- Connect the website and choose the branding.
- Review device capabilities and the signing setup.
- Build the APK; prepare an AAB if you plan to publish.
COFFEE. COMPANY. NO RUSH.
Make room
for slow.
Good coffee. A sunny corner.
A little more time for yourself.
From a question to something you can use.
Your routines, your business, your next app.
Put a routine to work.
Set up recurring work for connected channels from the Automations screen.
Each agent has a job.
A team of agents, with roles and model choices visible in one place.
Keep the business close.
Catalog, inventory, orders, and customers alongside the work of your agents.
Let me try the app I’m making.
COFFEE. COMPANY. NO RUSH.
Make room
for slow.
Good coffee. A sunny corner.
A little more time for yourself.
Make it yours.
Make the idea tangible.
Try Sunday, a working sample café website, inside an Android app frame. The menu and demo bag work.
OpenAlly is a cross-platform AI agent product for individuals and businesses. I’m building it at Matterward Labs to help people get useful work done: organise information, make websites and apps, and handle the everyday operations of a business.
Start with the job someone needs done
A person may need to turn scattered information into a plan. A small business may need to organise customers, inventory, orders, bookings, invoices, or payments. Those tasks are connected in the working day. OpenAlly brings agents and practical tools into one product so a conversation can lead into the work itself.
The product has Android and Mac interfaces, with iPhone part of its cross-platform direction. Platform availability and install options live on the OpenAlly website.
One runtime, several interfaces
The implementation separates the interface from the device-side runtime. The interfaces share TypeScript packages, while a Rust kernel owns the agent loop and the tools that act on local work. The mobile interface is React Native; the desktop application uses a Tauri shell.
The mobile interface talks to the Rust kernel through a native bridge. This gives the product a defined boundary between presenting a task and carrying it out. Agent sessions, model access, tool execution, and local records belong behind that boundary rather than being duplicated across screen components.
When the interface changes, a better screen should not require a second implementation of what an order means or how a tool is allowed to act. My work connects these parts into a product that people can use, while keeping their responsibilities explicit.
Model choice is a product decision
OpenAlly connects to different model providers and to compatible self-hosted models. People can choose the model that suits the job rather than rebuilding their workflow around a single provider. Supporting that choice requires a consistent path for requests, results, and failures inside the runtime.
Some work needs a capable remote model; other work benefits from local processing on supported devices. The interface needs to make those choices understandable. Privacy depends on the selected model and connected services, so local records should never be confused with a claim that no information can leave the device.
Business records stay close to the work
OpenAlly stores operational records such as inventory, orders, invoices, and payments in SQLite on the device. Optional hosted services and connected channels have their own responsibilities. Keeping those boundaries explicit makes it easier to reason about data ownership, availability, and what an agent is actually permitted to access.
I care about the less visible parts of that experience: a clear account of what happened, predictable permission checks, and failures a person can understand. An agent making a useful suggestion and an agent taking an action are different responsibilities. The system has to treat them that way.
Aster has a specific role
Aster is a separate Android companion for accessibility-based screen interaction. It can give an agent a way to inspect and operate an Android interface when the user enables it. That capability is Android-specific; it does not define OpenAlly as an Android-only product.
OpenAlly coordinates agents and work. Aster provides a particular device capability, behind a separate permission boundary. Giving AI an Android phone goes deeper into that boundary.
The thread from commerce to consumer AI
Building ZyadaShop and contributing to merchant platforms made me spend time with the systems behind everyday work. I’m carrying that interest into consumer AI with OpenAlly: start with a real task, give it an understandable interface, and build the machinery needed to follow through.
OpenAlly and its architecture are still changing. This page describes the boundaries I’m building around; the public site lists what ships today.
Sources & further reading
What I built, and the history behind it, is my first-person account. The links above back up the product descriptions and implementation details.
Talk to me on LinkedIn