The work lives in spreadsheets and chat threads.
Every order arrives as a message, someone copies it into a sheet, and the real status depends on who you ask. It is not an organization problem: nobody has the number at the moment they need it.
Mobile app development
Mobile apps that plug into the systems your business already runs.
iOS and Android, for your customers or for the people who work with you. What decides whether an app is worth having is not the screen: it is whether it reads and writes the data your company already keeps, so nobody types the same thing twice.
When the question comes up
An app usually shows up for one of three reasons.
Your customers already expect to do it from their phone.
They want to order, book or check where their job stands without calling and waiting for a reply. Right now a person answers that, during office hours.
The website handles the first visit, not the tenth.
It exists so people find you and get in touch. When the same person comes back every week to repeat the same task, the browser becomes the long way round: find the page, sign in again, and hear about a change only if they open it.
What we build
An app is four jobs, not one screen.
An app for your customers
Ordering, booking, tracking a delivery, checking history, paying where that applies. The work a person handles by message today, available at eleven on a Sunday night.
An app for your team
For people who work away from a desk: data entered where the job happens, with the photo and the signature attached to it right there, and work that survives a warehouse or a route with no signal.
Publishing on the App Store and Google Play
Developer accounts, store listing, screenshots, privacy policy, signing, and the back-and-forth with Apple’s review, which rejects for reasons that are not always obvious. Every update goes through it again.
Integration with what you already have
The app does not invent a parallel database: it queries yours. If your system exposes no API, we write it. It is the same work that sits behind the websites we publish.
How we work
The first version is defined by what we take out.
- 01
We learn how you work today.
One real day of operations: who enters what, where it stalls, what gets solved by message and which paper is still going around. Without this, the app becomes a digital copy of the mess.
- 02
We define the smallest useful scope.
The full feature list always fits in a meeting and never fits in version one. We keep the few that justify someone installing the app, and write the rest down for later.
- 03
We build it, and real people try it.
Every delivery is tested on real handsets, with the person who will use it, on data from your own operation. It is uncomfortable, and it is where everything no meeting predicted shows up.
- 04
We publish, then keep going.
Store release, measurement of what gets used and what does not, and fixes driven by that signal. An app without maintenance does not break all at once: Apple and Google keep updating their requirements, and one day an update stops being accepted.
Frequently asked questions
Native or cross-platform?
In most cases we write one codebase and both apps come out of it: there is less to maintain, and the two versions do not drift apart. We go native when the app depends on something the operating system only gives you there: sustained background work, an integration with specific hardware or a scanner, or a performance requirement we measure before deciding. Native means two codebases, and two codebases cost twice as much to keep alive. It is a decision made with the actual case on the table, not a preference.
What does an app cost?
It depends on four things, in this order: how many screens carry a business decision, whether the API still has to be built, whether the app handles payments or sensitive data, and whether it has to work with no signal. An app people use to check a status and an app that replaces your invoicing process do not share a budget or a conversation. The number comes after the first step, understanding the operation, and not in the first email. Some costs are also not ours: each store’s developer account, and the infrastructure the backend runs on.
Do you build for both iOS and Android?
Yes, and usually from the same codebase. Shipping to both stores at once does not double the development, but it does double the store work: two listings, two reviews, two update cycles. If the app is for your own team and the company hands out the phones, one platform is sometimes enough, and that is worth saying at the start.
Can it talk to the system I already use?
Almost always, and the real question is how. If your system exposes an API, the app consumes it. If it does not, but the data is reachable, we write the layer in between. If it is a closed third-party product with no API and no path to integrate, there is no trick: we tell you before we start and decide what to do then, instead of finding out halfway through.
Who publishes the app to the stores?
We do the work: accounts, listing, screenshots, privacy policy, signing and submission for review. The developer accounts, though, are registered to your company. It is more paperwork up front, and it is the only way the app and its users stay on your side if we ever stop working together. If the app is only for your team, both platforms allow internal distribution with no public listing.
What happens after launch?
In the first weeks things surface that no test predicted, because real use produces combinations nobody planned, and that is when fixes are fast. After that the work changes shape: keeping up with Apple’s and Google’s requirements, watching which features get used and which do not, and deciding what to build with that information. We can agree on monthly support or work change by change; what we do not recommend is publishing and never looking again.
Before quoting an app, it is worth knowing whether you need one.
Tell us how your team works today and what your customers keep asking for. If that is better solved by fixing the website or the system you already have, we will say so before you spend anything on an app.
Discuss my operation