One codebase, three platforms

Most app projects don't fail on the technology, they fail on the question that comes before it. Namely, whether an app is even needed. I ask that question in the first conversation, and in about half the cases the answer is no. A good mobile website is faster to launch, costs less, and skips the store review entirely.

When the answer is yes, it's usually for one of these reasons: users open it daily or weekly, it needs push notifications, it has to work offline, or the camera and other device features are central to what it does.

How I build

From one codebase for all platforms. The core is web technology, with native bridges for the things that make an app an app: camera, haptics, push, sign-in via Apple, Google or Facebook, payments. For iOS and Android I use Capacitor, for desktop applications Tauri.

That's a deliberate choice, not a fallback. Two separately developed native apps mean two builds, two test cycles, and two permanent construction sites for every change. For business and internal-tool applications, the difference in outcome rarely justifies that overhead. Where it does, for 3D, games, or heavy on-device processing, I'll tell you that instead of selling you my toolset.

A side effect that matters more in daily life than you'd expect: content and functional changes in the web core reach every device immediately, without a new store release and without users having to install an update. Only changes to the native parts need to go through the store.

Two of my own apps as proof

events is a planner for parties and club events. The app exists for iOS and Android, built with Capacitor on a Laravel backend, with a camera for photos, sign-in via Google and Apple, payments via Stripe, and haptic feedback. Guests can RSVP, keep a what-to-bring list, and organize carpools without registering.

zeit is time tracking and invoicing for freelancers, with a Tauri-based desktop application and an iOS companion. Both run in production, with real users and regular releases.

These two projects are the reason I offer app development at all. I didn't build them to show off as a portfolio piece, I built them because I needed the tools myself. Everything learned along the way, about store processes, certificates, push services, and the quirks of both platforms, goes straight into every client project.

The process and what it costs

After the first conversation, we set the scope: which platforms, which features in version one, which come later. Then a clickable prototype on a real device, because a lot feels different on a phone than in a mockup on a big screen. After that, development in two-week increments with builds you can install and try yourself.

A number without a conversation would be a guess. It gets noticeably cheaper in every case when a web application already exists as a base, because the core is already in place. If you're just starting out, that's often exactly the right path: build the web application first, running in the browser, to prove the concept holds up. The app comes after, on the same foundation.