Mobile app development
An enterprise app lives on a mid-range Android phone, on patchy mobile data, in the hands of somebody who did not ask for it. We build for those conditions first — because an app that needs a good connection and a new phone is an app your field team will find a way around.
Is this you?
- Field staff report by WhatsApp and somebody compiles it into a sheet every evening.
- Your existing app stops working the moment the signal drops.
- Dealers place orders by phone call because the app is too slow to use.
- You have no reliable record of who visited which site, and when.
- The app was built once, by somebody who is no longer available.
What we build
- Field force apps — visits, orders, collections, attendance, reporting
- Customer apps — orders, status, service requests, history, payments
- Dealer and distributor apps with credit limits and approved pricing
- Offline tolerance, with clean sync when the connection returns
- Camera, GPS, barcode and document capture where the job needs it
- Push notifications and WhatsApp alerts that are actually read
- Android and iOS from one codebase, unless there is a reason not to
- Play Store and App Store publishing under your own developer account
Businesses with people outside the office: sales, service, delivery, collection, site supervision — plus any company whose customers or dealers should be transacting rather than calling.
- A written scope you approve before any code is written
- A price agreed against that scope, not discovered later
- Source code, database, documentation and IP yours on final payment
- Training for your team, and close support through the first month
Questions people ask about this
How do you price a project?
Against a written scope, agreed before any code is written. We do not publish indicative figures, because the same-sounding requirement can differ several times over in cost depending on the specifics.
What drives the number: how many distinct user roles there are, how many screens and reports, how much data has to be migrated from existing systems, how many other systems it must talk to, and whether your process is already documented or has to be worked out first. A first conversation is usually enough for us to tell you the rough order of magnitude.
How long does a project take?
It depends on how much of the system you want live at once, which is why we usually suggest starting with one module rather than everything.
What holds true regardless is the shape of it: you see something working every two weeks from the start of the build. You are never waiting three months to find out the project went wrong in week two.
Who owns the source code?
You do, on final payment. Source code, database, documentation and intellectual property in the work are assigned to you in the contract. There is no licence that expires and no situation in year three where you discover the software is not yours.
We also hand over in a usable state: documented, commented, and written so another developer can pick it up.
Can you take over software somebody else built?
Often, yes, and it is a more common request than anybody admits. We start with a technical audit: what it is built on, what state the code is in, what is missing, and what it would cost to keep it running versus rebuild it. You own the findings whether or not you continue with us.
Sometimes the honest conclusion is that the system should be replaced. We will say that plainly, and we will also say when it should not be.
Tell us what isn’t working
A first conversation costs nothing and commits you to nothing. Bring the problem — the mess of spreadsheets, the report nobody can produce, the process that breaks every month-end. We will tell you honestly whether custom software is the answer, and roughly what it would take. Sometimes the answer is that you do not need us. We will say so.