iOS and Android apps
Native in Swift and Kotlin, or cross-platform in Flutter and React Native. Chosen on what the app needs to do rather than on preference, and we will explain the trade.
Most app projects fail on the parts nobody budgeted for: the backend, the store review, and the year after launch when the platforms change their requirements. We build the whole thing, ship it, and are honest at the start about which of your features belong in version one.
Thanks — that’s with us.
A senior engineer reads every enquiry and will get back to you shortly.
Book a time that suits you, or send a message and get an answer sooner.
2020
Building since
1,000+
Clients served
UK
Registered company
4.6/5
Rated on Clutch
Quick answer
The visible app is usually less than half the work. The backend it talks to, the authentication, the sync behaviour when a phone has no signal, the store submissions and the ongoing maintenance all cost real time, and they are what gets missed in a first estimate.
Native or cross-platform is the question everyone opens with, and it matters less than expected. Flutter and React Native are entirely sensible for most business applications and let one team serve both platforms. Native earns its premium when you are deep in platform-specific capability: heavy camera work, complex background behaviour, tight hardware integration. We will tell you which case you are in rather than defaulting to whichever we prefer.
Offline behaviour is the requirement most often underestimated. An app used by engineers, drivers or inspectors will lose signal, and deciding what happens then, queue, merge, conflict, is a design decision with real engineering behind it. It is much cheaper to decide at the start.
Then there is the year after launch. Apple and Google change requirements, and an app that is not maintained will eventually stop being accepted. We would rather set that expectation during scoping than present it as a surprise renewal.
What we build
Eight areas. The first two are where most of the effort actually goes.
Native in Swift and Kotlin, or cross-platform in Flutter and React Native. Chosen on what the app needs to do rather than on preference, and we will explain the trade.
The part the app depends on and the part most often missing from a first estimate. Built alongside the app so the two are designed together rather than negotiated later.
What happens when the signal goes: queueing, conflict resolution and what the user sees. Essential for field apps and much cheaper decided up front.
Connecting to the job system, CRM, ERP or finance system the app exists to serve. Usually where the real complexity sits.
On-device and server-side AI where it earns its place: document capture, classification, assistants. We will say when it is decoration rather than function.
App Store and Play Store listings, review requirements and the rejections that follow. Handled by us, including the second submission nobody budgets for.
Platform requirement changes, OS releases and dependency updates. An unmaintained app eventually stops being accepted, and we say that at scoping rather than later.
Where a responsive web application would serve better, we will build that instead. It is less revenue for us and the right answer often enough to be worth saying.
Why app projects overrun
Overruns we are asked to rescue are rarely about the interface. They are about everything the app depends on.
Not sure whether you need an app at all?
A responsive web application serves a good number of the briefs we receive, at a fraction of the cost. We will tell you if that is yours.
In practice
Six recurring briefs. These describe the work rather than named clients.
Jobs, photos, signatures and sign-off, working without signal and syncing when it returns. The offline design decides whether the app is used or quietly abandoned.
Paperwork captured at the job
A customer-facing companion to an existing service. The question worth asking first is whether it earns its place against a good mobile website, and sometimes it does not.
An app that justifies its existence
Stock counts, checks, inspections and approvals, built for a specific job rather than as a general platform. Usually small, quick and high value.
A process off paper
Booking, reminders and rescheduling, integrated with whatever the back office already uses rather than introducing a second calendar to reconcile.
One schedule, not two
Supply, demand, payments and messaging. Substantial builds where scoping version one honestly is what decides whether the project ships at all.
A first version that launches
Projects inherited from another developer. We will assess honestly whether to continue or restart, including when restarting is cheaper, which is not what the client wants to hear.
An honest route to shipping
How we work
Scoping is where a project is saved or lost, so we spend real time on it.
What the app does, what the backend has to provide, what happens offline, and which features genuinely belong in version one. Free, and sometimes it ends with us suggesting a web app.
App and backend together, released to you in testable builds rather than appearing at the end. You see it working while it is still cheap to change.
Store listings, review requirements and any rejections, handled by us. We check the feature list against store rules early rather than discovering a problem at submission.
Platform changes, OS releases and dependency updates, under an arrangement quoted openly. Your accounts and your repositories throughout.
Clear scope · Regular demos · Full handover
Honest fit
A fair share of app briefs are better served by a web application. We would rather establish that early.
Sectors
Where work happens away from a desk.
FAQ
What UK businesses ask before commissioning an app.
Still have a question?
Ask us directly — a senior engineer will get back to you.
Ask about your projectIt depends on the backend as much as the app. A focused internal tool over an existing API is a different proposition from a two-sided marketplace with payments. The honest answer is a written range after scoping, and we would be wary of anyone quoting before they know what the backend looks like.
Cross-platform, with Flutter or React Native, is entirely sensible for most business apps and lets one team serve both platforms. Native earns its premium for heavy camera work, complex background behaviour or tight hardware integration. We will tell you which you are, rather than defaulting to a preference.
A fair number of briefs we receive are better served by a responsive web application, which is cheaper, needs no store review and updates instantly. If you need offline use, the camera, location or notifications, an app earns its place. If not, we will say so even though it is less work for us.
You do. The code goes in your repositories and the apps are published under your Apple and Google developer accounts, not ours. Publishing client apps through an agency account creates a hostage situation and we do not do it.
It happens, and we handle it. We check the feature list against store requirements during scoping so the common causes are designed out, but review decisions vary and a resubmission is a normal part of the process rather than a sign something went wrong.
Platform requirement changes, OS releases and dependency updates, as a minimum. An app left untouched for two years will typically stop being accepted by the stores. We raise this at scoping because it is a real ongoing cost and discovering it later feels like a surprise bill.
Often. We assess the state of the code honestly and tell you whether continuing or restarting is cheaper. Sometimes the answer is restart, which is not what anyone wants to hear, and saying it anyway is the useful part.
Yes, and we usually should. The backend is where most of the real work sits, and splitting it across two suppliers is the most reliable way to produce an integration argument halfway through the project.
It depends on the size of the site and the scope of the work, so we do not publish a fixed price: the honest range is wide. The first conversation and the audit are free, and the quote follows them, in pounds, once we both know what the work actually is.
SpiderHunts Technologies Ltd, registered at Companies House under number 16718403, with an office at 182-184 High Street N, Office 14607, London E6 2JA. You are invoiced in pounds. The engineering team works from Lahore, which we state openly rather than implying a room full of desks in London.
Start here
What it does, who uses it, whether a backend exists, and what has to work without signal. We will come back with an approach, an honest view of what belongs in version one, and a realistic range in pounds.
Thanks — that’s with us.
A senior engineer reads every enquiry and will get back to you shortly.
Book a time that suits you, or send a message and get an answer sooner.