Do you build mobile apps for iPhone and Android?
Yes — iOS, Android, or both, and we handle App Store and Google Play submission rather than handing you a build file and wishing you luck. Most of our mobile work is Flutter: one codebase ships to both stores, which cuts the build roughly in half against writing the same app twice and keeps the two versions from drifting apart afterwards. We go fully native in Swift or Kotlin when an app leans hard on platform-specific behavior.
Do we actually need a native app, or would a website do?
Often a mobile Web app is the right answer, and it is cheaper, and we will tell you so. You need a real installed app when it has to work with no signal, run in the background, use the camera or scanner heavily, send push notifications, or live on the home screen because people open it twenty times a day. If none of those apply, a responsive Web app saves you the app stores entirely.
Can you build a Windows desktop application?
Yes, including the parts most Web shops skip: a signed installer, silent deployment to managed machines, local printers, scales and scanners, and running against a local database when the network drops. macOS builds get signed and notarized so staff are not clicking through security warnings. Where a browser would genuinely do the job, we will say that first.
Who designs it? We do not want something that looks homemade.
Design is part of the build, not an upsell. You get a clickable prototype before we write the expensive part, layouts drawn from your brand, and a small design system so the twelfth screen looks like the first. Everything is responsive down to a 360-pixel phone and meets WCAG 2.2 AA contrast and keyboard requirements. If you already have a designer or a brand guide, we build to it.
Who owns the code?
You do, outright, on final payment — source, history, and deployment instructions, in your own repository and accounts wherever possible. We do not hold your project hostage in our hosting account, and we do not charge to hand it over.
What does a project cost?
A small integration or automation is usually a few days of work. An internal tool with logins and reporting is typically a few weeks. A first mobile app release — designed, built, and through App Store or Play review — is normally measured in weeks rather than months, because we ship the smallest useful version first. We quote after a free scoping conversation, and we will tell you when the honest answer is that the software is not worth building.
We already have a developer. Is that a problem?
No, and it is common. We take the piece your team is short on — an integration, a migration, a legacy component — work in your repo and your conventions, and leave without a trace of vendor lock-in.
What programming languages do you work in?
The problem picks the language more than we do. Python and TypeScript carry most of the web work; Go or Rust where a service has to be small and fast; Java, C#, and C++ where your existing systems already run on them; Swift when a mobile app goes fully native; JavaScript and SQL under nearly everything. We also take the work most shops turn down — COBOL, Fortran, Ada & SPARK, Erlang and Elixir, Scala, Clojure, F#, Julia, and Zig — usually on one side or the other of a modernization. If your team already has a stack, we work in yours instead.
How do we work together day to day?
A short kickoff, then a working demo you can click through at a regular cadence rather than a status report you have to interpret. You talk directly to the person writing the code, because that is who there is.
Will you sign an NDA?
Yes, routinely, before you share anything sensitive. Send yours over, or we can provide a simple mutual one.
What happens after launch?
Your choice. Take it in-house with documentation and a handoff walkthrough, or keep us on a small retainer for updates and support. Both are normal; neither is a trap.