From Idea to Impact.

Problem

Devotees wanted texts and audio in one place, usable by people who are elderly or new to smartphones, and without depending on a connection.

Solution

An Android app built on a local library, with reading, audio, an offline assistant and a lock, plus a reference backend and admin tool for content.

Key challenges

• Keeping the highlighted line in step with both the device voice and recorded audio.
• Designing for people who have never used a smartphone app.
• Making an offline assistant honest by labelling where each answer comes from.

Learnings

• Starting offline-first made everything else simpler: the network became an enhancement, not a requirement.
• Real content and real audio are a separate piece of work from the engineering and must be planned for.

Outcome so far

The Android app is built and tested, and an iOS port exists in code. Content is still sample data and nothing is deployed.

Screenshots

Problem

A small gadget needs content loaded onto it, controlled remotely, and counted against, without a screen as large as a phone.

Solution

A companion app and web dashboard that talk to the gadget over Bluetooth LE and Wi-Fi, with checked, framed uploads and a built-in demo gadget.

Key challenges

• Defining a transfer protocol with checksums that survives dropped connections.
• Fitting photos and chants into a fixed number of slots on a small device.
• Letting people try the app without owning the hardware.

Learnings

• Writing the protocol first lets the software and the hardware be built independently.
• A simulated device finds interface problems long before real hardware exists.

Outcome so far

The Android app, iOS port and web dashboard are built against a defined protocol. The physical gadget that speaks it is not shipping yet.

Screenshots

Problem

Clinics need appointments, a visible queue, prescriptions and billing, but cannot run a heavy system.

Solution

One Node server that hosts many clinics, with installable web apps for doctors and patients, mobile apps, PDF prescriptions and an optional assistant.

Key challenges

• Keeping a live queue accurate across reception, doctor and patient screens.
• Separating many clinics' data cleanly inside one server.
• Making the AI assistant strictly optional and off by default.

Learnings

• Installable web apps get a clinic running quickly without waiting for app-store approval.
• Clear boundaries between clinics are worth designing in from the first day.

Outcome so far

The web apps and server run locally at version 0.1.0 and mobile apps are built. Hosting and a domain are still to be chosen.

Screenshots

Problem

Non-technical people want a clean page of their work, shared with a short link.

Solution

Editor apps for Android, iOS and web that publish to a short slug through a lightweight API designed for Cloudflare Workers, with QR sharing and plans.

Key challenges

• Giving every portfolio a short, unique, safe address.
• Letting people preview a draft exactly as it will publish.
• Separating free and premium features without confusing users.

Learnings

• Edge workers keep the API small, cheap and fast for a product of this shape.
• A no-code editor has to be as strict as a code editor about what it will accept.

Outcome so far

The apps and API are built at version 0.1.0. Nothing is deployed yet.

Screenshots