# It started with a what if. I’m Satyajit Pradhan. I build the systems behind product ideas, from merchant platforms to consumer AI. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-29 Canonical: https://satyajiit.dev/ ## What if AI could do more than answer? [OpenAlly](/work/openally/) is a cross-platform AI agent product for building an app, running a shop, and giving recurring work to agents. Conversations connect to agents, tools, and workflows across devices. I’m building it at [Matterward Labs](https://matterwardlabs.com). OpenAlly stretches from the experience someone touches to the systems underneath: a Rust device-side kernel, shared TypeScript, native bridges, and local storage. [Explore OpenAlly’s architecture](/work/openally/). ## What if your browser could help with the work? [TaffyGo](/work/taffygo/) is the Chromium browser I’m building for Android at Matterward Labs. It starts with ordinary browsing, then adds one assistant, Taffy, to help with pages, research and files. The idea is to keep the work close to the page: compare information across sites, prepare an image for a form, or turn a table into a useful file. File processing happens on the device. The person using the browser keeps control of what Taffy does. [Explore TaffyGo](https://taffygo.com). ## What if an AI could use the phone in your hand? [Aster](/work/aster/) is my open-source Android companion, built for the OpenClaw era. It lets agents observe and use a real phone, with the device owner in control. The connection can live entirely in the app: an on-device MCP server for direct clients, and Binder IPC for apps on the same phone. Neither path needs a separate server. [Read the Aster story](/work/aster/). ## What if opening a laptop was an interaction? [UnfoldMyMac](/work/unfoldmymac/) starts with the hinge, a piece of hardware most interfaces ignore. Lid movement becomes an input for desktop effects and living artwork. [Read the UnfoldMyMac story](/work/unfoldmymac/). ## What if the next product was a game? Two of my Matterward Labs projects are games, and both are out on Google Play: [Narrow Front](/games/#narrow-front), a portrait WWII strategy game, and [Siren Jam](/games/#siren-jam), a parking puzzle with an ambulance to rescue. Both are free, and the iPhone versions are coming to the App Store. [Play the trailers](/games/). ## Some ideas need a workbench. I build beyond the screen. My Bambu Lab H2C is where miniatures, custom enclosures, and parts for consumer gadgets start taking physical form. There’s something satisfying about bringing a circuit, a printed case, and the software inside into one working object. [More from the workshop](/lab/physical-computing/). ## Curiosity has a camera, too. [GamesPatch](https://www.youtube.com/@GamesPatch) is my YouTube channel, with 5K+ subscribers. Gaming, unboxing technology, and the joy of trying things out belong alongside the code. ## What if technology could make a quiet moment? [@dreamy.loopz](https://www.instagram.com/dreamy.loopz/) is my automated AI platform for creating peaceful moments, with 8K+ followers on Instagram. A different kind of output, with the same interest in the system behind it. ## A question that became a business. Before OpenAlly, I built [ZyadaShop](/work/zyadashop/): a mobile-first commerce platform that let a merchant build a storefront and Android app from a phone. It grew to 500+ shipped features, with approximately 15-second APK generation and a separate Play Store publishing workflow. ZyadaShop won Google Play’s Best of 2022 in India, Best Hidden Gems. Mosambee later acquired it. [Google’s announcement](https://blog.google/intl/en-in/products/platforms/google-plays-best-apps-and-games-of-2022-in-india/). ## Then came the systems behind the counter. My work at [Mosambee](/work/merchant-platforms/) spans team-built POS and merchant applications, microservices, and distributed systems serving lakhs of merchants. Products at that scale teach you to care about retries, failure modes, and what happens on an ordinary working day. ## It started with a small screen. In eighth standard, I built WAP applications and mobile-game portals with XHTML and PHP. There was a small screen, an idea, and enough curiosity to keep going. Later came certificate-generation tools for colleges and universities, Smart India Hackathon participation, an Associate Android Developer certification, and wireless IoT systems with companion apps. The tools changed. The habit of seeing an idea through stayed. [The longer story](/about/). ## Still asking. Still making. [OpenForge](/lab/openforge/) explores what happens underneath a game. The [Forza × MOZA Bridge](/lab/forza-moza/) forwards a racing game’s telemetry to a hardware setup. Some questions become products; others remain experiments worth following. ## Notes from building. [Giving AI an Android phone](/writing/giving-ai-an-android-phone/) and [Designing interactions around a laptop hinge](/writing/designing-around-a-hinge/) explain the decisions behind the work. ## Have a what if? [Let’s talk](/contact/). ## Open questions ### What if the next useful gadget is the one you build yourself? A printed enclosure, a circuit, and the software inside. I’m interested in the place where all three meet. [Step into the workshop](/lab/physical-computing/) ### What if the missing connection is a project waiting to happen? That question already led me from a racing game to a MOZA telemetry bridge. There are plenty more systems worth connecting. [Explore the racing experiment](/lab/forza-moza/) ### What if understanding a system changed what you could make with it? The interesting part is often underneath: the state, the assumptions, and the failure modes. [Look inside OpenForge](/lab/openforge/) --- # OpenForge An open-source Windows trainer for offline single-player games, built with Rust, Tauri, and declarative game definitions. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/lab/openforge/ ![OpenForge cover](https://satyajiit.dev/images/cover-openforge-v3-960.webp) OpenForge is my open-source Windows desktop application for offline single-player game trainers and mods. I wanted the game library, its controls, and the code behind those controls to belong to the same tool. The actual screens above show that arrangement: select a game, then move between its trainer and mod options. ## One application, different games I built the interface with Tauri and TypeScript; Rust handles the engine-specific work underneath it. A game definition describes the features the interface should expose. TOML and RON files keep those definitions inspectable alongside the code. That split is the part I find interesting. Adding a game should not mean designing another launcher. A game definition can describe the controls while an engine adapter deals with the mechanics that differ between titles. ## From a control to its implementation The screenshots show an example game workspace, including trainer controls and a separate Mods tab. They are captures from the repository, so the visible options belong to that recorded build. Supported games and features continue to live in the source. I like being able to follow a button down into the system it changes. OpenForge is where I work on that in Rust, behind an interface I can use myself. That interest in understandable device capabilities also turns up in [Aster](/work/aster/). ## Open the project OpenForge is available under the MIT license. The [repository](https://github.com/satyajiit/openforge-aio) includes the application, game definitions, engine architecture, and authoring documentation. It is built for offline single-player use. ## Sources & further reading - [OpenForge source and scope](https://github.com/satyajiit/openforge-aio) --- # I tend to follow the question. Satyajit Pradhan’s building stories, from eighth-standard WAP applications to merchant platforms and consumer AI. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/about/ I’m Satyajit Pradhan. I build the systems behind product ideas. My work moves between the interface someone touches, the services behind it, and the awkward details that have to work for the whole thing to be useful. I’m from a small town in Odisha, India, and currently work in Mumbai. ## Before there was a roadmap In eighth standard, I was building WAP applications and mobile-game portals with XHTML and PHP. A phone was enough to make the internet feel like something I could build for. Getting an idea onto that small screen was the interesting part. That habit carried into certificate-generation tools for colleges and universities. Repeating the same document work was a problem worth turning into a tool. I also participated in Smart India Hackathon through my university, earned the Associate Android Developer certification, and built wireless IoT systems with companion apps. Each project made me work across another boundary: a document and its data, a device and its connection, an interface and the hardware behind it. ## An idea becomes somebody’s working day [ZyadaShop](/work/zyadashop/) took the question into commerce: could a merchant build a website and Android app from a phone? I shipped more than 500 features across the platform and built an APK generation flow that took approximately 15 seconds. Mosambee acquired ZyadaShop. At [Mosambee](/work/merchant-platforms/), I contributed to team-built POS and merchant-facing applications used by lakhs of merchants. The work includes microservices, distributed systems, and the operational complexity that follows when software becomes part of someone’s business. ## The current what if Today, I’m building [OpenAlly](/work/openally/) at [Matterward Labs](https://matterwardlabs.com). It brings AI agents and practical tools into everyday personal and business work. [Aster](/work/aster/) and [UnfoldMyMac](/work/unfoldmymac/) explore different parts of the same interest: making software connect more naturally to the devices around us. ## Away from the roadmap I enjoy Rust, Counter-Strike, Call of Duty, football, and racing games. The [Forza × MOZA experiment](/lab/forza-moza/) is what happens when a game and a piece of hardware leave me with a question I want to answer. I’m interested in understanding how systems work, where they break, and how to strengthen them. That security mindset means looking for weak assumptions, failure modes, and ways to make behaviour easier to inspect. Persistence, for me, is often just continuing to work through those details until the idea becomes something usable. ## A camera and a workbench I run [GamesPatch](https://www.youtube.com/@GamesPatch), a YouTube channel with 5K+ subscribers, around gaming, unboxing technology, and trying things out. I also print miniatures and custom enclosures on my Bambu Lab H2C to build consumer gadgets. Working on something you can hold brings a different set of questions to the same building habit. [@dreamy.loopz](https://www.instagram.com/dreamy.loopz/) is my automated AI platform creating peaceful moments, with 8K+ followers on Instagram. My personal Instagram is [@satyajit.null](https://www.instagram.com/satyajit.null/). You can also find me on [X as @satyajiit0](https://x.com/satyajiit0) and [Reddit as u/XenonCI](https://www.reddit.com/user/XenonCI/). ## Recognition for something we built ZyadaShop won Google Play’s Best of 2022 in India in the Best Hidden Gems category. [Google’s announcement](https://blog.google/intl/en-in/products/platforms/google-plays-best-apps-and-games-of-2022-in-india/) lists the app. Mosambee later acquired it. ## Sources & further reading - [Satyajit’s public profile and project history](https://www.linkedin.com/in/satyajiit/) --- # OpenAlly A cross-platform AI agent product for personal and business work, with a shared Rust runtime and practical tools for getting things done. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/work/openally/ ![OpenAlly cover](https://satyajiit.dev/images/cover-openally-v3-960.webp) 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](https://openally.ai/). ## 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](/work/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](/writing/giving-ai-an-android-phone/) goes deeper into that boundary. ## The thread from commerce to consumer AI Building [ZyadaShop](/work/zyadashop/) and contributing to [merchant platforms](/work/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. ## What you can do ### Build an app: Give 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. Example request: “Turn my shop’s website into an Android app.” 1. Connect the website and choose the branding. 2. Review device capabilities and the signing setup. 3. Build the APK; prepare an AAB if you plan to publish. ![Give your website a home on Android.](https://satyajiit.dev/images/sunday-website-640.webp) ### Run the shop: Stock, orders, and money. In the same working day. Business tools bring the catalog, stock locations, orders, invoices, and payments into OpenAlly. An agent can work with the records you allow it to access; refunds and other consequential actions remain decisions for the owner. Example request: “Help me understand what is in stock before I take the next order.” 1. Keep products, prices, and stock locations together. 2. Follow an order into payment and fulfilment. 3. Review the action before money or stock moves. ![Stock, orders, and money. In the same working day.](https://satyajiit.dev/images/openally-desktop-business-960.webp) ### Delegate a routine: Give recurring work an agent and a place to run. Create an agent with a defined role and model, then set up recurring work for connected channels. The agent team and Automations screens keep those choices visible instead of burying them in a conversation. Example request: “Keep this channel’s recurring work on a schedule.” 1. Give the agent a job and choose its model. 2. Connect the channel the work belongs to. 3. Set up the routine and inspect its activity. ![Give recurring work an agent and a place to run.](https://satyajiit.dev/images/openally-automations-640.webp) ## Inside the app ### Put a routine to work. ![OpenAlly Automations screen showing scheduled workflows for LinkedIn, YouTube, X, and Instagram.](https://satyajiit.dev/images/openally-automations-640.webp) Set up recurring work for connected channels from the Automations screen. ### Each agent has a job. ![OpenAlly Agent team screen showing assistants for support, sales, development, and other roles.](https://satyajiit.dev/images/openally-agents-640.webp) A team of agents, with roles and model choices visible in one place. ### Keep the business close. ![OpenAlly Business screen with inventory, catalog, orders, customers, and tax settings.](https://satyajiit.dev/images/openally-business-640.webp) Catalog, inventory, orders, and customers alongside the work of your agents. ### Make the idea tangible. ![Sunday café website demo, with a menu and working sample bag.](https://satyajiit.dev/images/sunday-website-640.webp) Try Sunday, a working sample café website, inside an Android app frame. The menu and demo bag work. ## Product figures - **4+** Google Play rating - **5K+** Android installs Google Play Console, 2026-09-14. ## Sources & further reading - [OpenAlly product and platform availability](https://openally.ai/) - [OpenAlly trust and control](https://openally.ai/under-the-hood) - [Matterward Labs](https://matterwardlabs.com) --- # TaffyGo The AI-native Chromium browser I’m developing for Android at Matterward Labs, now on Google Play, with Taffy and on-device file tools. By Satyajit Pradhan Published: 2026-09-28 Updated: 2026-09-28 Canonical: https://satyajiit.dev/work/taffygo/ ![TaffyGo cover](https://satyajiit.dev/media/taffygo-launch-thumbnail.webp) A lot of useful work starts in a browser and ends somewhere else. Read a few pages. Compare the details. Copy a table. Resize a photo. Go back to the form. TaffyGo starts with that familiar sequence and asks how much of it could stay in one place. I’m building TaffyGo at [Matterward Labs](https://matterwardlabs.com): an AI-native Chromium browser for Android, with one assistant called Taffy. Ordinary browsing remains the foundation. Tabs, saved pages, downloads, and ad and tracker blocking belong alongside the assistant. ## A browser first The new tab is a quiet starting point: original artwork, one address box, and the everyday browser controls. Search the web, ask about a page, or hand Taffy a task. Those are different intentions, and the interface should keep the distinction understandable. The light and dark surfaces above are rendered from the same new-tab design used on the TaffyGo website. The film follows the broader product direction, from browsing and research to file preparation and developer integrations. ## Keep the work close to the page One example is a form that accepts a photo under 200 KB. The useful action is a sequence: take a copy, resize and compress it on the phone, attach the result, then let the person review the form before submitting. The original file stays untouched. The same idea applies to research. Bring information from selected pages together, compare products and reviews, and keep the sources beside the answer. A useful result should be something a person can inspect, save and return to. ## Local tools, explicit control File processing runs on the device. Requests to an AI provider are a separate choice. TaffyGo lets people connect their preferred provider, while keeping task progress and approvals visible in the browser. Under the interface is Chromium, Android UI, and a sandboxed Rust core. The engineering work is making those boundaries behave consistently when pages change, files are large, or a task needs the person to take over. ## Build the browser with us TaffyGo is [available on Google Play](https://play.google.com/store/apps/details?id=com.taffygo.browser). Its first-party source is licensed under the Mozilla Public License 2.0. Developers, designers, translators and testers are welcome to help shape it. Visit [taffygo.com](https://taffygo.com) for the product story and contribution information. The launch film above brings the direction together in under two minutes. ## Product figures - **Chromium** Browser foundation - **MPL 2.0** Source licence Product and source, 2026-09-28. Available on Google Play. ## Sources & further reading - [TaffyGo on Google Play](https://play.google.com/store/apps/details?id=com.taffygo.browser) - [TaffyGo product website](https://taffygo.com) - [Matterward Labs](https://matterwardlabs.com) --- # Giving AI an Android phone What building Aster taught me about connecting AI agents to Android: observation, actions, device permissions, and keeping control understandable. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/writing/giving-ai-an-android-phone/ ![Giving AI an Android phone cover](https://satyajiit.dev/images/cover-writing-android-4k-960.webp) Giving an AI agent access to an Android phone turns a conversation into a systems problem. The agent needs a way to observe the interface, request an action, and find out what changed. The person holding the phone needs to understand and control that access. [Aster](/work/aster/) is the Android companion I built around that boundary. It is separate from [OpenAlly](/work/openally/), the cross-platform AI product I’m building at Matterward Labs. ## A request is not an outcome An instruction such as “open that app” sounds complete in conversation. On a device, it is a request made against a particular state. The app may already be open. A dialog may be covering it. The screen may have changed since the agent last looked. I think of that interaction as a short loop: observe the available state, choose an action, then observe again. Treating an attempted action as proof of success would hide from both the agent and the person whether the action worked. This is a design principle I take from working across interfaces and systems. It does not require a model to be infallible. It requires the surrounding software to keep the difference between intention and evidence visible. ## Give the device layer a clear job Aster exposes Android capabilities to agents. I built it as an open-source project for the OpenClaw era, with connection options that do not require a second computer. The Android app can host its own Model Context Protocol server for clients that connect directly to the phone. OpenAlly’s native Android integration uses a separate Binder IPC path between apps on the same device. The on-device MCP server embeds Ktor and uses Streamable HTTP. Binder IPC avoids the network altogether, with token authentication and on-device approval. Aster also has an optional remote WebSocket mode through a separate server. The [Aster repository](https://github.com/satyajiit/aster-mcp) documents all three transports and their different tool catalogs; the project is MIT-licensed. A stable boundary is useful even when the interface on either side changes. The agent decides what it wants to attempt. The device layer decides which capabilities it exposes, under what permissions, and what result it can report. Those responsibilities should remain understandable independently. ## Permission belongs in the experience Android accessibility access is powerful because it can reach an interface rather than a narrow purpose-built API. A person needs an explicit way to approve access and stop it. Aster includes device approval and an on-device stop control. The design question is broader than whether a connection is technically possible. Can the person tell that control is active? Can they intervene when the agent is wrong? What happens if the connection is lost? These questions are useful requirements for any agent that acts outside its chat window. ## Keep platform claims precise Aster’s screen-control role is Android-specific. OpenAlly has a broader cross-platform scope. Combining those two descriptions into “an AI Android app” would lose the architecture and confuse what is available on another device. OpenAlly can share an agent runtime without promising identical device capabilities everywhere. I prefer to explain the shared job first, then identify which capability needs a particular platform. ## The part I keep returning to The interesting work is the connection between a useful intention and a dependable action. A model can suggest the next step; the product still has to manage state, permissions, and feedback. ## Sources & further reading - [Aster implementation and device controls](https://github.com/satyajiit/aster-mcp) - [OpenAlly product scope](https://openally.ai/) --- # Forza × MOZA Bridge An open-source UDP bridge connecting Forza Horizon 6 telemetry to MOZA Pit House for RPM LEDs and dashboard feedback. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/lab/forza-moza/ ![Forza × MOZA Bridge cover](https://satyajiit.dev/images/cover-forza-v3-960.webp) I wanted the RPM lights and dashboard on my MOZA setup to respond while playing Forza Horizon 6. The game could send telemetry, but that alone did not make Pit House listen. The Forza × MOZA Bridge grew out of following that missing connection. ## The listener was the missing piece At the time of the experiment, Pit House recognised the Forza Horizon 5 process and opened its UDP listener on port 30055 for it. Horizon 6 was sending the same 324-byte CarDash packet format. The repository includes a small compatibility helper that gets Pit House to open that listener. The bridge then receives the game’s output on port 4009 and forwards it to 127.0.0.1:30055. Normal 324-byte packets pass through unchanged. ## A bridge small enough to inspect The forwarding script uses Python’s standard library. Diagnostic counters distinguish received, transmitted, passed-through, truncated, and dropped packets. They make it possible to ask a specific question: did the game emit data, did the bridge receive it, and did a packet leave for Pit House? The dial above shows how RPM information reaches the wheel; it is not connected to my racing setup. ## Follow the packets The [MIT-licensed repository](https://github.com/satyajiit/forza-horizon-6-moza-bridge) contains the implementation and Windows setup instructions. I enjoy racing games, but this project came from a second interest: understanding why two pieces of equipment that should work together do not yet connect. ## Sources & further reading - [Forza Horizon 6 MOZA bridge source](https://github.com/satyajiit/forza-horizon-6-moza-bridge) --- # Have a what if? Contact Satyajit Pradhan about product ideas, systems, consumer AI, or the work at Matterward Labs. By Satyajit Pradhan Published: 2026-09-14 Canonical: https://satyajiit.dev/contact/ I’m interested in useful product ideas and the systems it takes to make them work. If something here connects with what you’re building, I’d like to hear about it. I’m from a small town in Odisha, India, and currently work in Mumbai. If you’re around, we can sit down for a coffee and talk about something you wish existed. ## Start a conversation [Write to satyajit@matterwardlabs.com](mailto:satyajit@matterwardlabs.com). [Find me on LinkedIn](https://www.linkedin.com/in/satyajiit/) for a personal conversation about the work. [Contact Matterward Labs](https://matterwardlabs.com/contact) for OpenAlly, our apps, product feedback, or a business enquiry. ## A little context helps Tell me what you’re trying to build, who it is for, and the part you’re thinking through. A rough idea is a perfectly good starting point. You can also [explore my public code on GitHub](https://github.com/satyajiit) or go back to [the work](/work/). ## Elsewhere My personal profiles are [@satyajit.null on Instagram](https://www.instagram.com/satyajit.null/), [@satyajiit0 on X](https://x.com/satyajiit0), and [u/XenonCI on Reddit](https://www.reddit.com/user/XenonCI/). Find my gaming and technology channel at [GamesPatch on YouTube](https://www.youtube.com/@GamesPatch). [@dreamy.loopz](https://www.instagram.com/dreamy.loopz/) is a separate Instagram page for my AI work creating peaceful moments. --- # Aster An open-source Android companion built for the OpenClaw era. On-device MCP and app-to-app IPC let agents use a real phone without a separate server. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/work/aster/ ![Aster cover](https://satyajiit.dev/images/cover-aster-v3-960.webp) Aster is an open-source Android companion I built for the OpenClaw era: agents were becoming useful outside a chat window, and I wanted to give them access to the phone already in someone’s hand. It lets an agent inspect the screen, tap controls, and navigate apps on a real phone. It is a separate app from [OpenAlly](/work/openally/), which talks to it over Binder on the same phone. ## The connection can live in the app Aster supports two app-only connection paths. Its **on-device MCP server** runs inside the Android app. An MCP client connects directly to the phone over a trusted network, without a separate Node server. On the same device, another Android app can use **Binder IPC** to request actions directly, with token authentication and on-device approval. OpenAlly uses that native app-to-app path. The on-device MCP server uses embedded Ktor and the MCP Kotlin SDK’s Streamable HTTP transport. Binder IPC stays on the device and does not need a network hop. Both paths reach the same command handler and device controls, although the available tool catalogs vary by path. To my knowledge, Aster was the first Android app to bring on-device MCP and direct app-to-app IPC together in this way. The public repository documents the implementation, and the code is available under the MIT license. There is also an optional remote path: the phone opens an outbound WebSocket connection to an Aster server, and an AI client connects to that server through MCP. ## A bridge to the screen An agent that only receives text cannot automatically understand what an app is showing or which control to tap. Aster exposes device capabilities through the Model Context Protocol, or MCP, and a native Android companion. Its public repository describes the supported tools and connection setup. Aster’s screen inspection and interaction rely on Android capabilities and permissions. OpenAlly’s broader cross-platform product does not depend on every platform offering the same screen-control mechanism. ![Aster’s screen-control dashboard, with the device interface and available control tools.](/media/aster-dashboard-device-screen-control.webp) ## Give the agent useful capabilities Screen inspection is one part of the toolkit. Aster can expose app navigation, files, notifications, media, calls and voice, camera capture, and Android system actions through its command handler. A spare phone can become a dedicated device for an agent; the phone someone already uses can also participate when they choose. Observing a UI hierarchy and tapping a control are separate actions. A useful result depends on what is actually on screen when the action happens, not only on the plan the agent made a moment before. ![The Aster MCP tool explorer, grouped around device capabilities.](/media/aster-dashboard-mcp-tool-explorer.webp) ## Permission is part of the architecture Accessibility access is a powerful capability. Aster’s implementation includes device approval and an on-device way to stop control. The on-device MCP server belongs on a trusted local network or a private network connection, not an exposed public endpoint. The native integration with OpenAlly uses Android Binder IPC and an approval boundary. It is a separate transport from the on-device MCP server. ![Aster’s light-theme permission screen, showing the Android capabilities the person can enable.](/media/aster-light-permissions.webp) The persistent kill-switch notification gives the person a way to stop screen control. The package policy blocks control of banking apps by default and fails closed. These checks apply across every path; the trust setup for each transport remains different. For example, an approved remote server connection does not turn the on-device MCP server into an authenticated public service. The remote server’s WebSocket needs a trusted network or a TLS/private-network layer when used remotely. The repository documents that boundary explicitly. ## Record a flow, or react to an event The on-device recording overlay captures taps, text, and scroll steps so a sequence can be replayed as an app automation. That is useful when the same route through an interface comes up repeatedly. A recorded flow still needs to account for a screen that has changed since it was recorded. With event forwarding, an incoming notification or device event can become a webhook to an endpoint the owner configures. It is off by default. The companion face adds another kind of feedback: it articulates speech and can react to music, while its event classifier keeps raw accessibility events on the device. ![Aster’s event-forwarding dashboard, with configuration and event controls.](/media/aster-dashboard-event-forwarding.webp) ## A dashboard when the setup needs one The optional server includes a web dashboard for device registration and approval, telemetry, logs, files, screen control, and tool exploration. It makes a multi-device setup inspectable. ![Aster’s device registry and approval interface in the optional server dashboard.](/media/aster-dashboard-device-registry.webp) Someone evaluating Aster should be able to choose the path they need without assuming that every screenshot represents a required service. ## The lesson in the boundary This project made one distinction concrete: the agent can propose an action, but the device layer is still responsible for exposing and executing that capability. A screen can change between observation and action. Permissions can be removed. A connection can disappear. Those are part of the product, not exceptions to design around later. I explore that reasoning in [Giving AI an Android phone](/writing/giving-ai-an-android-phone/). ## Product figures - **2** App-only paths - **MIT** Open-source license [Aster source & documentation](https://github.com/satyajiit/aster-mcp), 2026-09-14. Connection paths documented in the project source. ## Sources & further reading - [Aster source, MIT license, and connection modes](https://github.com/satyajiit/aster-mcp) - [Aster on ClawHub](https://hub.openclaw.ai/satyajiit/skills/aster) --- # Designing interactions around a laptop hinge Design notes from UnfoldMyMac: using lid movement as input, making effects feel connected to hardware, and considering motion as system behaviour. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/writing/designing-around-a-hinge/ ![Designing interactions around a laptop hinge cover](https://satyajiit.dev/images/cover-writing-lid-4k-960.webp) A laptop hinge is an unusually good invitation to think about interaction. It already moves for a reason. It has a physical range. And the person using it does not need to learn a new gesture. [UnfoldMyMac](/work/unfoldmymac/) began around that possibility: connect desktop effects to the MacBook lid. The app now includes lid effects, dynamic wallpapers, and creative scenes, with a native Swift, AppKit, and Metal implementation. ## Begin with the physical relationship When an effect responds to a hinge, the relationship between movement and image matters more than an elaborate animation. If the lid moves a little, the visual response should make that movement understandable. If the lid stops, the effect should not seem to continue on an unrelated schedule. That is a different design problem from a timed transition. A transition has a beginning and an end chosen by software. A physical input can reverse halfway through, pause, or arrive in small, uneven updates. The visual system needs a meaningful state for all of those moments. ## A useful model of the interaction I think about the experience in three parts: 1. **Input:** what movement or device state is available? 2. **Mapping:** how does that input become a position, amount, or visual parameter? 3. **Presentation:** how does the result appear without fighting the desktop? Separating those questions makes the behaviour easier to reason about. A rendering change need not redefine the input. A different device capability need not mean inventing a new visual language. This is a design model, rather than a claim that every effect uses the same implementation. The [UnfoldMyMac source](https://github.com/satyajiit/UnfoldMyMac) has the details of the current native app. ## Let people see what a design does A still image explains appearance, but it does not explain an interaction. A person choosing a lid effect needs to understand the relationship to movement. A person choosing a wallpaper needs to know whether it reacts to a different input or behaves independently. So the UnfoldMyMac library has to show a preview and say what each effect responds to. The question is not simply “Do I like this picture?” It is also “Do I want my desktop to behave like this?” ## Motion has a lifecycle A delightful effect is still a running system. It has resources to manage and moments when it is no longer visible. Its behaviour around closing, reopening, and changing context is part of the design. That concern carries into this portfolio. The machine has short responses to a person’s selection, and the page remains useful without them. ## Follow the small question What interested me was noticing a control already present in the object, rather than adding another to a screen. Following that question led from a laptop hinge into native rendering and a collection of effects. ## Sources & further reading - [UnfoldMyMac implementation and native stack](https://github.com/satyajiit/UnfoldMyMac) --- # Beyond the screen Miniatures, printed enclosures, and consumer gadget experiments with my Bambu Lab H2C. Where software meets something you can hold. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/lab/physical-computing/ ![Beyond the screen cover](https://satyajiit.dev/images/workshop-640.webp) Some ideas need more than a screen. I use my Bambu Lab H2C to print miniatures, custom enclosures, and parts for consumer gadgets. This is the physical side of the same curiosity that drives my software work. It is an ongoing exploration rather than a released gadget catalog. ## A circuit needs a home An enclosure is part of how a gadget feels. The electronics have to fit inside it, the ports have to be reachable, and the object has to make sense in your hand. Printing an enclosure makes those questions tangible. The interesting part for me is bringing the software, electronics, and physical object into one build. An application has an interface; so does a button, a connector, or a lid. There is something satisfying about making the pieces belong together. ## Miniatures belong here too Not every print has to solve a practical problem. I also print miniatures. The details and the simple pleasure of seeing a small object take shape are reasons enough to make something. I bring the same curiosity to games, unboxing technology, and trying new equipment on [GamesPatch](https://www.youtube.com/@GamesPatch), my YouTube channel with 5K+ subscribers. ## An open workbench Try the enclosure above: open the shell, inspect the board, and wake its display. It is a design demo, not a released gadget. The H2C, miniature printing, and enclosure building are part of my own setup and practice. What if the next small thing I want to use is something I can build myself? ## Sources & further reading - [GamesPatch on YouTube](https://www.youtube.com/@GamesPatch) - [Bambu Lab’s H2C introduction](https://blog.bambulab.com/bambu-lab-h2c-where-multi-material-vortek-system-meets-engineering-precision/) --- # Games I make at Matterward Labs Narrow Front, a portrait WWII strategy game, and Siren Jam, a parking puzzle. Both are free on Google Play and coming to the App Store. By Satyajit Pradhan Published: 2026-09-29 Canonical: https://satyajiit.dev/games/ Alongside the apps, I make games at [Matterward Labs](https://matterwardlabs.com). Two are out now on Google Play: a strategy game about holding one narrow road, and a puzzle about getting an ambulance out of a jammed car park. Both are free, and the iPhone versions are coming to the App Store. ## Narrow Front Narrow Front is a real-time WWII strategy game for phones, played in portrait. Each battle is one narrow front between two headquarters. You deploy infantry squads, tanks and support tactics as cards, fight from cover, take the farmhouses that matter, and push the line toward the enemy headquarters. The campaign follows ten small actions at real places from Colleville to Remagen, June 1944 to March 1945, with fictional characters and voiced motion comics. Skirmish adds eleven maps against the computer at five ranks. Every battle runs offline. The game is free, with optional rewarded ads and no in-app purchases. ## Siren Jam Siren Jam is a parking puzzle. An ambulance, a fire engine or a police car is boxed in by a jammed car park, and it can only drive straight forward or straight back. Tap the other cars away in the right order until one lane is clear, then send it racing to the hospital, the fire or the bank alarm. There are 160 levels across eight worlds, from Downtown to Frontline Valley, with drawbridges, traffic lights and broken-down wrecks along the way. The game is free, with nothing to buy; a short optional ad earns extra coins. ## How I build them Both games are made in Unity 6, and both keep the rules apart from the pictures. Narrow Front’s battles are decided by a plain C# simulation that ticks twenty times a second; the 3D view, the camera and the effects only draw what it reports. Siren Jam’s levels are generated from a plan and checked by a solver, which also sets each level’s move limit, so every jam has a known way out. ## Sources & further reading - [Narrow Front on Google Play](https://play.google.com/store/apps/details?id=com.matterwardlabs.narrowfront) - [Narrow Front website](https://narrowfront.matterwardlabs.com) - [Narrow Front launch trailer on YouTube](https://www.youtube.com/watch?v=2hugDp6AiLk) - [Siren Jam on Google Play](https://play.google.com/store/apps/details?id=com.matter.sirenjam) - [Siren Jam website](https://sirenjam.matterwardlabs.com) - [Siren Jam launch trailer on YouTube](https://www.youtube.com/watch?v=_6wqlsaN9tw) - [Matterward Labs](https://matterwardlabs.com) --- # UnfoldMyMac A native Mac app that turns lid movement into desktop effects, with dynamic wallpapers and creative scenes built in Swift, AppKit, and Metal. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/work/unfoldmymac/ ![UnfoldMyMac cover](https://satyajiit.dev/media/unfold-lights-out.webp) I only meant to make one effect. Watching the opening animation on the iPhone Duo made me look at the MacBook in front of me: it had a lid, too. What could happen on its screen when I moved it? UnfoldMyMac grew from that question into a native Mac app for lid effects, live wallpapers, and desktop scenes. The comic panels and video previews here come from the [original product story](https://unfoldmymac.com/story/). ## The spark: what if my Mac did that? The appealing part of the folding-phone animation was its relationship to the object. The screen changed because the device moved. I wanted to bring that physical relationship to a laptop, using the gesture someone already makes when opening or closing it. ![The original UnfoldMyMac comic: a maker looks from a folding phone to the MacBook on his desk.](/media/unfold-story-the-spark.webp) A conventional button gives an interface a clear event. A lid gives it a range. Half open is a meaningful state, and stopping halfway should stop the effect with you. That became the first constraint of the experiment. ## The first experiment was blur The first version recreated the frost idea in Metal. Lower the lid and the desktop blurs; lift it and the desktop becomes clear again. The effect follows the position, rather than finishing a canned animation after a trigger. ![The original comic’s experiment: the maker lowers his MacBook lid and watches the desktop respond.](/media/unfold-story-the-experiment.webp) Then came curtains, ribbons, artwork, and characters peeking over windows. Each needed its own visual language, but all of them kept the same physical promise. The movement on the screen should belong to the movement of the lid. Try the laptop at the top of this page: drag down, flick up, or hold the close and open controls. ## Then I left the lid open A lid effect has a beginning and an end. A desktop world has somewhere to stay. I started making scenes that could keep moving while I worked: a race circuit, a little city built from a GitHub profile, a factory following coding activity. ![The original comic’s bigger idea: a growing collection of race cars, curtains, windows, and desktop characters.](/media/unfold-story-a-bigger-idea.webp) That became the wallpaper collection. Lights Out stages an open-wheel circuit and countdown. GitHub After Hours turns public repository activity into a floating city. Codex Foundry makes a miniature accelerator from local coding activity. The clips below are original app-rendered previews with sample data. ## Game’s closed. World’s still on. Gaming wallpapers gave this idea a different vocabulary. Night City carries network activity along its neon lanes. Endless Dusk brings a chosen city’s weather to a Forza-inspired road. Site of Grace and Greenpath are quieter worlds to leave behind the windows. These scenes are part of UnfoldMyMac’s wallpaper collection; they do not control the games. Select a world below to see the moving preview. Each clip pauses when it leaves the screen, and the playback button remains available when reduced motion is enabled. ## See it on a real MacBook The product film follows the original spark, the growing collection, and demonstrations filmed on a real MacBook. A render can describe the visual idea, but seeing a hand move the lid makes the relationship easier to understand. The full story film is below. The [UnfoldMyMac website](https://unfoldmymac.com/story/) has more detail. The original [gaming film](https://www.youtube.com/watch?v=eYLM1soTuVs) shows the collection in motion as well. ## Playful surfaces, native responsibilities The app uses Swift, SwiftUI, AppKit, and Metal. A desktop effect has to coexist with normal work: windows, system input, available hardware, and the lifecycle of a rendering surface. A live wallpaper also has to say what data it reads. Public GitHub activity, local coding sessions, network readings, and weather are different inputs with different setup requirements. That is the systems work I enjoy inside a playful product. Keep the physical model understandable, make the sources of live data explicit, and stop doing work when the surface is no longer useful. [Designing interactions around a laptop hinge](/writing/designing-around-a-hinge/) goes deeper into the interaction reasoning. UnfoldMyMac is open source and part of my work at [Matterward Labs](https://matterwardlabs.com). Its [repository](https://github.com/satyajiit/UnfoldMyMac) contains the implementation, contribution guidance, artwork notices, and current hardware requirements. ## Product figures - **Swift** Native macOS app - **Metal** Real-time effects [UnfoldMyMac source](https://github.com/satyajiit/UnfoldMyMac), 2026-09-14. Native app and original product story. ## Sources & further reading - [UnfoldMyMac source and native stack](https://github.com/satyajiit/UnfoldMyMac) - [UnfoldMyMac product website](https://unfoldmymac.com) --- # GamesPatch My YouTube channel with 5K+ subscribers: gaming, unboxing technology, and following curiosity from a screen to a physical build. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/lab/gamespatch/ ![GamesPatch cover](https://satyajiit.dev/media/youtube-phfqjh8r0ue.webp) [GamesPatch](https://www.youtube.com/@GamesPatch) is my YouTube channel, with 5K+ subscribers. The videos embedded on this page are uploads from the channel. Browse the builds, gear, and games, then play one. ## The builds, on camera A walkthrough asks different things of a product than a screenshot does. You have to move through it, show what changes, and let someone see the interaction unfold. The Aster phone walkthrough and the MOZA telemetry fix are both on the channel. I enjoy that connection between making something and presenting it. A project can be a piece of software on my machine, then become something another person understands by watching it in use. ## Games are part of the story I play Rust, Counter-Strike, and Call of Duty, alongside racing games and other titles. Sometimes a game stays a game. Sometimes the equipment around it sends me into a project such as the [Forza × MOZA Bridge](/lab/forza-moza/), or a deeper systems experiment such as [OpenForge](/lab/openforge/). ## From opening a box to making one I also unbox technology on the channel: my PS5 Pro setup with limited-edition controllers and an M.2 SSD, the Switch 2 Dbrand Killswitch kit, and even the merch I brought back from Mumbai Comic Con. I print miniatures and custom enclosures on my Bambu Lab H2C and build consumer gadgets. Trying a new device leads me to ask how I might build one myself. That physical side has its own page, the [workshop](/lab/physical-computing/). ## Product figures - **5K+** YouTube subscribers [GamesPatch on YouTube](https://www.youtube.com/@GamesPatch), 2026-09-15. ## Sources & further reading - [GamesPatch on YouTube](https://www.youtube.com/@GamesPatch) --- # dreamy.loopz My automated AI platform creating peaceful moments on Instagram, with 8K+ followers. A quieter creative output from an interest in systems. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/lab/dreamy-loopz/ ![dreamy.loopz cover](https://satyajiit.dev/images/cover-dreamy-v3-960.webp) [@dreamy.loopz](https://www.instagram.com/dreamy.loopz/) is my automated AI platform for creating peaceful moments. The Instagram page has 8K+ followers. It is a separate creative project; my personal account is [@satyajit.null](https://www.instagram.com/satyajit.null/). ## Make room for a pause Most of the products on this site invite an action: run a business, build an app, control a device. With dreamy.loopz, I am interested in the moment someone spends looking. A peaceful scene can be the whole reason for making it. The four films above come from dreamy.loopz: a monsoon road trip with chai stops and a cottage by nightfall, an evening at the tapri, a mountain drive beneath the Milky Way, and a late-night city drive in the rain. Choose a film to watch it here. Sound is off until you turn it on; you can pause or open the original film at any time. ## The creative output and the system This project brings two of my interests into the same place: AI as a medium for making things, and automation as a way to support a creative practice. I built an automated AI platform around that peaceful direction. It is another answer to the question running through this portfolio. A useful system might serve a merchant or help an agent complete a task. It can also make a page of quieter moments that people choose to return to. ## Follow this thread Visit [dreamy.loopz on Instagram](https://www.instagram.com/dreamy.loopz/) for the films. For the broader product work behind my interest in agents and automation, [OpenAlly](/work/openally/) is the next chapter to explore. ## Product figures - **8K+** Instagram followers [dreamy.loopz on Instagram](https://www.instagram.com/dreamy.loopz/), 2026-09-14. ## Sources & further reading - [dreamy.loopz on Instagram](https://www.instagram.com/dreamy.loopz/) --- # Systems behind the counter My contribution to team-built POS and merchant applications at Mosambee, including the microservices and distributed systems behind them. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/work/merchant-platforms/ ![Systems behind the counter cover](https://satyajiit.dev/images/merchant-systems-640.webp) At Mosambee, I contribute to team-built POS and merchant-facing applications serving lakhs of merchants. My work spans the applications people use and the microservices and distributed systems behind them. ## The counter is only one part of the system A merchant sees an application at the point of sale. Behind that screen are services and operational processes that have to work together. Building for that environment means understanding the whole path, including what happens when one part is slow, unavailable, or in a different state from another. A flow can look simple on screen while depending on several moving parts. The challenge is to make the working experience coherent without pretending that complexity has disappeared. ## Built with teams These applications are a team effort. My contribution includes building POS and merchant applications, working on service boundaries, and reasoning about distributed behaviour. I describe the scale as the context of that shared work, rather than claiming every outcome as mine alone. Microservices introduce useful separations, but they also create operational questions. Where does a piece of state belong? Which service is responsible for an outcome? How does somebody investigate a failure that crosses boundaries? Those are the kinds of questions that keep the engineering work connected to the merchant experience. ## What this work sharpened Working on merchant platforms strengthened my interest in failure modes, observability, and understandable responsibilities. I want to know where a system’s assumptions stop holding and how to make it more resilient. That mindset also informs [OpenAlly](/work/openally/). The products are different, but both need machinery that supports the work behind the interface. ## A connection through ZyadaShop Mosambee acquired [ZyadaShop](/work/zyadashop/), the mobile-first commerce platform I built. The transition connected my earlier work helping merchants create their own digital storefronts with a broader world of merchant applications and payment infrastructure. ## Product figures - **Lakhs** Merchants served - **POS** Apps & services [LinkedIn profile](https://www.linkedin.com/in/satyajiit/), 2026-09-14. Team-built POS and merchant platforms at Mosambee. ## Sources & further reading - [Mosambee product overview](https://www.mosambee.in/) --- # ZyadaShop The mobile-first commerce platform I built, with 500+ shipped features, approximately 15-second APK generation, and a Play Store publishing workflow. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/work/zyadashop/ ![ZyadaShop cover](https://satyajiit.dev/images/cover-zyadashop-v3-960.webp) I built ZyadaShop as a mobile-first commerce platform that let merchants create a website and Android app for their shop. It brought storefront creation and the work of running a digital business into a flow designed around a phone. Mosambee later acquired ZyadaShop. ## Google Play Best Hidden Gems 2022 ZyadaShop was one of Google Play’s Best of 2022 winners in India, in the Best Hidden Gems category. Google’s announcement described it as enabling entrepreneurs to create their stores from their mobile phones. It was recognition for a product our team had put into people’s hands. ## A platform that started with the merchant A merchant should be able to get a digital storefront without assembling a development team. ZyadaShop generated a customer-facing website and app from a shop’s content and configuration. The platform grew to more than 500 shipped features. ## Approximately 15 seconds to generate an APK ZyadaShop generated an Android application package from the merchant’s configuration in approximately 15 seconds. That timing refers to generating the APK, not to installing it on a customer’s phone or obtaining store approval. App generation is an engineering workflow under the platform’s control. Play Store publishing is a separate workflow with its own submission and review stages. ## From configuration to distribution The product connected three stages: 1. The merchant supplied the shop’s information and configured the storefront. 2. The platform generated the website and Android app package. 3. A Play Store publishing workflow carried the app toward distribution, subject to the store’s processes. The interesting engineering problem was the connection between these stages. A simple merchant-facing action needed to produce a useful artifact and a clear next step. Fast package generation only helped if the merchant could understand what the platform had built and what still needed to happen. ## What carried forward ZyadaShop made me work across product design, Android, web applications, and the systems connecting them. Its acquisition by Mosambee led into my work on [POS and merchant platforms](/work/merchant-platforms/). The same impulse is visible in [OpenAlly](/work/openally/): make a useful capability reachable by someone with a task to do, then take the supporting system seriously. ## Product figures - **4.3** Google Play rating - **50K+** Android downloads - **500+** Features I shipped [Google Play listing](https://play.google.com/store/apps/details?id=com.argonlabs.mydukaan), 2026-09-14. ## Sources & further reading - [Google Play’s Best of 2022 in India: Best Hidden Gems](https://blog.google/intl/en-in/products/platforms/google-plays-best-apps-and-games-of-2022-in-india/) - [Satyajit’s LinkedIn profile and ZyadaShop project history](https://www.linkedin.com/in/satyajiit/) - [Matterward Labs product links](https://matterwardlabs.com/contact) --- # Ideas, put to work. From merchant platforms to consumer AI. The products, the systems, and the questions behind them. ## [OpenAlly](https://satyajiit.dev/work/openally/) A cross-platform AI agent product for personal and business work, with a shared Rust runtime and practical tools for getting things done. ## [TaffyGo](https://satyajiit.dev/work/taffygo/) The AI-native Chromium browser I’m developing for Android at Matterward Labs, now on Google Play, with Taffy and on-device file tools. ## [Aster](https://satyajiit.dev/work/aster/) An open-source Android companion built for the OpenClaw era. On-device MCP and app-to-app IPC let agents use a real phone without a separate server. ## [UnfoldMyMac](https://satyajiit.dev/work/unfoldmymac/) A native Mac app that turns lid movement into desktop effects, with dynamic wallpapers and creative scenes built in Swift, AppKit, and Metal. ## [Systems behind the counter](https://satyajiit.dev/work/merchant-platforms/) My contribution to team-built POS and merchant applications at Mosambee, including the microservices and distributed systems behind them. ## [ZyadaShop](https://satyajiit.dev/work/zyadashop/) The mobile-first commerce platform I built, with 500+ shipped features, approximately 15-second APK generation, and a Play Store publishing workflow. --- # Still on the workbench. Experiments in games, hardware, and what happens underneath. ## [OpenForge](https://satyajiit.dev/lab/openforge/) An open-source Windows trainer for offline single-player games, built with Rust, Tauri, and declarative game definitions. ## [Forza × MOZA Bridge](https://satyajiit.dev/lab/forza-moza/) An open-source UDP bridge connecting Forza Horizon 6 telemetry to MOZA Pit House for RPM LEDs and dashboard feedback. ## [Beyond the screen](https://satyajiit.dev/lab/physical-computing/) Miniatures, printed enclosures, and consumer gadget experiments with my Bambu Lab H2C. Where software meets something you can hold. ## [GamesPatch](https://satyajiit.dev/lab/gamespatch/) My YouTube channel with 5K+ subscribers: gaming, unboxing technology, and following curiosity from a screen to a physical build. ## [dreamy.loopz](https://satyajiit.dev/lab/dreamy-loopz/) My automated AI platform creating peaceful moments on Instagram, with 8K+ followers. A quieter creative output from an interest in systems. --- # Notes from building. Design decisions, system boundaries, and things I learned by following a question. ## [Giving AI an Android phone](https://satyajiit.dev/writing/giving-ai-an-android-phone/) What building Aster taught me about connecting AI agents to Android: observation, actions, device permissions, and keeping control understandable. ## [Designing interactions around a laptop hinge](https://satyajiit.dev/writing/designing-around-a-hinge/) Design notes from UnfoldMyMac: using lid movement as input, making effects feel connected to hardware, and considering motion as system behaviour.