Cross-Platform Mobile & Desktop App Development

Three surfaces, one backend culture.

On mobile, I build native Android applications in Java — full products, not prototypes: catalogue and checkout flows, payment gateway integration, push notifications, in-app purchases, and the server-side webhooks that make subscriptions actually reconcile. On desktop, I build JavaFX and .NET applications for the workflows that browsers handle badly — long-running sessions, local hardware access, dense operational UIs. And on the design side, I produce complete mobile experiences before a line of code exists: the Modus Media Player engagement was a 45-screen iOS design system, prototyped interactively in Figma as the blueprint for a production build.

What ties the three together is the backend. Every app I ship is backed by a Java / Spring Boot API built in the same engagement — authentication, data, payments, push — because in a decade of doing this, the defects that hurt most were never in the screens. They were in the seams between an app team and a backend team who each assumed the other had handled it.

The honest framing: cross-platform frameworks (Flutter, React Native, and on desktop, Electron) trade some platform fidelity and dependency weight for a single codebase, and for many products that trade is worth it. Where the calculus tips toward native is when the app leans on the platform itself — payments and in-app purchases with their notoriously platform-specific edge cases, background services, hardware access, or performance under real load. My own delivery strength is native Android with a shared backend, and my advice on the choice is framework-agnostic: I'd rather talk you out of a mismatch before the build than bill you through one after it.

Desktop deserves the same scrutiny in the other direction. Teams reach for Electron by default because it's the web stack they know, and for content-centric tools it's fine — but operational desktop software that runs all day in a warehouse, lab, or control room benefits from the leaner footprint and native integration of a JavaFX or .NET client. The right answer falls out of three questions: who uses it, for how many hours at a stretch, and what does it need from the machine it runs on? Bring me those answers and the platform recommendation comes free with the quote.

Because these decisions deserve more than a paragraph, I've published the full reasoning as standalone guides: Electron versus native desktop, Flutter versus React Native as a general framework decision, and the same comparison rewritten for connected-device apps, where Bluetooth, background execution, and vendor SDKs change the answer. All three are written as framework-neutral advice — the same triage I run in consultations — and linked at the bottom of this page.

More businesses than the hype cycle admits. Operational Windows software written in WPF or WinForms runs core workflows in labs, logistics offices, clinics, and factories — software that works, encodes years of business rules, and has quietly lost the developers who understood it. Hiring for that maintenance is hard precisely because the stack stopped being fashionable, which is how 'legacy' becomes a synonym for 'unsupported' while the software is still load-bearing.

That niche is squarely inside my desktop practice: .NET and JavaFX client work backed by the same senior engineering as everything else here — taking over an existing codebase, stabilizing it, extending it with the features the business has been deferring, or building its modern replacement alongside it while the original keeps running.

The honest triage applies here too: not every aging desktop app needs a rewrite, and the rewrite-by-default instinct has burned more budgets than any legacy bug. A takeover starts with an audit of what's sound, what's fragile, and what the business actually needs next — and the recommendation that follows is sometimes 'maintain and extend', sometimes 'replace incrementally', and only occasionally 'rebuild'. Whichever it is, it arrives as a fixed-bid scope, not an open-ended meter.

Biryan Express is the end-to-end proof: a food-delivery e-commerce Android app built from scratch — catalogue, cart, checkout, integrated payment gateway, order management, and the operations admin panel the business runs on. One engagement covered the customer app, the backend, and the tooling; the seams problem never had a chance to exist.

Pick Plug is the rescue-work proof: an existing Android app whose in-app purchase flow was broken and whose backend subscription webhook silently failed. I rewrote the IAP flow, fixed the webhook, and took purchase conversion errors to zero — the kind of engagement where the win is measured in revenue that stops leaking. Hop Orbits, a multi-vendor marketplace I co-founded, adds the real-time dimension: Android frontend over WebSocket messaging for live buyer-seller interaction. And the Modus Media Player design system shows the front half of the pipeline — 45 iOS screens, a coherent design language, and an interactive Figma prototype ready for a development team.

Because the most expensive app bugs are backend bugs wearing an app costume. A purchase that doesn't unlock, a notification that never arrives, an order that vanishes between checkout and kitchen — users experience all of these in the app, but the defect lives in the API, the webhook, or the queue behind it. When one developer owns both sides, there is no boundary to fall into: the Pick Plug engagement existed precisely because an app-side team and a backend-side assumption had quietly diverged, and purchases were failing in the gap. Fixing it took someone willing to treat the app, the store's purchase API, and the server webhook as one system — which is how I build new products from the start.

Because money moving through an app involves three parties that each hold a slightly different model of the truth: the app, the store or payment gateway, and your backend. A purchase is not one event — it's a sequence of promises across that triangle (intent, charge, confirmation, entitlement, and eventually renewal, refund, or cancellation), and every arrow in the triangle can fail independently, out of order, or twice.

The failure modes are never demo-visible. They surface as the intermittent purchase that charges but doesn't unlock, the subscription that renews at the store but lapses in your database, the refund your backend never hears about. Pick Plug arrived here as exactly that pathology — an intermittent in-app purchase failure — and the repair lived in treating the flow as one distributed transaction: a rewritten IAP flow in the app, a fixed subscription webhook on the server, and reconciliation between them, taking conversion errors to zero.

The engineering answer is unglamorous and absolute: the backend is the ledger of record, every store event is verified server-side and processed idempotently, and the app renders entitlement from the ledger rather than deciding it locally. Building to that standard from day one is dramatically cheaper than retrofitting it after revenue is already leaking — and it's why payment and subscription scope carries real weight in my quotes: it's the feature where correctness is directly denominated in your revenue.

Every consumer-facing app is secretly two products, and the second one runs your business. Biryan Express is the clean example: customers saw a food-delivery app — catalogue, cart, checkout, payments — but the operation ran on the admin panel behind it, where orders are managed, the menu is maintained, and the day's business is actually conducted. That surface has its own users, workflows, and reliability requirements, and app budgets blow up mid-project most reliably when it was priced as an afterthought — 'and a simple admin page' is the most expensive phrase in app briefs.

Treating the admin surface as a first-class deliverable is part of how engagements are scoped here: the same backend serves both surfaces, so building them together costs far less than commissioning them apart — and the operational features (roles, audit of who changed what, reporting) get designed into the API rather than bolted on. If your product's real complexity lives in operations rather than the consumer screens, that's not a problem; it's just the true shape of the project, and the quote will reflect it honestly instead of discovering it in month three.

Yes — real-time is an architecture choice, not a headcount. Hop Orbits runs live buyer–seller interaction over WebSocket messaging between an Android frontend and the backend, which is the general pattern: the server pushes state changes over a persistent connection, and the app renders them as they arrive. The same shape powers live order status, chat, auction bids, or a courier moving on a map.

The engineering weight isn't in the socket — it's in the state discipline around it: what happens when the connection drops mid-update, how the app reconciles after reconnecting, and making sure the pushed view and the queried view can never disagree. Those are backend-and-contract problems, which is why real-time features benefit disproportionately from the one-engagement model. The developer designing the push protocol is the same one consuming it in the app, so the reconnection story gets designed once, correctly, instead of negotiated between teams after the first field reports.

Mobile quotes here are fixed-bid, returned within 48 hours of your brief — no hourly meter. What determines the number:

If you already have an app and the problem is narrower — a broken purchase flow, a flaky backend, an integration that never worked — the engagement can be narrower too. Rescue work like Pick Plug is scoped and fix-bid the same way, and it's often the highest-ROI engagement in this catalogue: small scope, immediate revenue impact.

Four engagement models, depending on what you need:

Remote-first, worldwide, response within 24 hours, and new engagements typically starting within one to two weeks.