Web platforms
SSR-first multi-tenant web apps with WebAssembly clients, passkey login, and zero-install user flows.
We build secure, fast, low-maintenance software with Rust at its core — web platforms with passkey authentication, iOS and Android apps, and Google Cloud back ends — and we advise organizations on online security, Google Workspace, Google Cloud and app design.
Six core areas where Rust pays off the most — mobile, web, cloud, and the security stack underneath.
SSR-first multi-tenant web apps with WebAssembly clients, passkey login, and zero-install user flows.
Native iOS and Android binaries in Rust, compiled to a native app around the system WebView, hosting our own web UI and adding what a browser cannot reach — Bluetooth, NFC, Face ID and fingerprint prompts, camera, push notifications and geofencing — with passkeys wired straight to Apple's and Android's own credential APIs. (Built directly on wry/tao.) When an app is mostly platform APIs, we write it in native Swift or Kotlin instead.
Telegram, WhatsApp, Slack and Google Chat bots that act on real business workflows — not just chat.
Axum services on Cloud Run: statically linked binaries in scratch containers, scaling to zero when idle, OIDC between services, and structured logging from the first commit.
Cloud Run, Cloud Tasks, Pub/Sub, Secret Manager, IAM, Workload Identity Federation — wired correctly, not copy-pasted.
Strict Content-Security-Policy with Trusted Types, HSTS preload, cross-origin isolation, row-level permissions enforced in the database rather than the application, append-only audit trails, and recorded legal acceptances with tamper-evident document fingerprints. Encryption and signing keys are protected by a hardware security module (HSM), and every service account can read only the exact secrets it uses.
Not every problem needs new software. We also advise organizations directly, on the same things we build with every day.
A review of how your organization signs in, shares and stores information: passkeys and two-step verification, account recovery, phishing exposure, access that should have been removed long ago — and a clear, prioritized plan to close the gaps.
Setting up and tightening Google Workspace for schools and businesses: organizational units, sharing and security policies, groups and shared drives, and moving people and data from one setup to another without losing anything on the way.
Choosing and configuring the right Google Cloud services, keeping costs predictable, least-privilege access and service accounts, secret management, and a review of what you already run before it becomes a problem or a surprise on the bill.
Before a line of code is written: what the app should do, for whom and on which platforms, its screens and flows, the privacy and app-store requirements it will meet, and an honest estimate of what it takes to build and to maintain.
Boring, predictable infrastructure plus a memory-safe language you can trust in production for years — on the server, in the browser, and on every phone.
Our logic, servers and data layer are written in Rust — no glue scripts, no Node toolchains. The screens are HTML and CSS generated by that Rust: it is what every browser and phone already renders natively, so pages load instantly, work with screen readers, and need no extra download. On mobile, that interface runs inside a native app built in Rust, and device features reach the platform SDKs through bridges we write and audit, not a plugin marketplace. We write Swift or Kotlin only where an app is mostly Apple's or Google's own APIs.
Cloud Run for stateless services, Cloud Tasks for queues, Secret Manager for credentials — all with OIDC, no shared keys. Scheduled work runs inside the service itself rather than a separate cron system, so there is one less moving part to authenticate and to fail.
Written in Rust itself — which is the whole point: one language from the server all the way into the database. Multi-model, with row-level PERMISSIONS, live queries and graph traversals, replacing three separate stores in most projects. It also runs embedded, inside the application binary, which is what makes an offline-capable build possible at all.
Small teams, written specs, and shipping code that holds up in production.
Every feature starts as a written design. You see the data model, the routes, and the security model before we touch the editor.
Authenticated endpoints, service accounts scoped to the minimum role, secrets in a managed vault rather than the image, and audit logs from the first commit. We ship static binaries in scratch containers — no shell, no package manager, nothing to pivot to — and enforce a dependency ban list in CI so a C library or an unexpected network client cannot arrive unnoticed. And we are moving every service into our own WebAssembly capability sandbox, written in Rust with no C code: there a service can reach only the hosts, secrets and files it declares, so even a compromised dependency cannot send your data anywhere else.
Frontend, backend, database, infrastructure, CI/CD, and the legal/compliance pages. One team, one bill, one source of truth.
Send a short note describing the project. We aim to reply within one business day.
Schedule
Book a 30-min intro call
Pick a time that works for you. We'll send a Google Meet link automatically.
support@jjir.org
Best for general questions, scoping, and bug reports — we aim to reply within one business day.
Business hours
Mon–Fri, 9:00 – 18:00 (US Central)
Phone available on request for active engagements.