Mobile work, clearly scoped
First define what someone must do on the phone, on which devices, and with which data. Then we assess the smallest viable version, required integrations, and ownership after launch. The first conversation is a testable use case — not a wishlist of features.
Who uses the app, which action must succeed, and in which conditions — including offline periods or data from an existing system. Lock the required behaviour before choosing platforms, features and build cost. If you are still choosing between browser and installable app, start with a web app comparison instead.
€1,250 excl. VAT
An organisation with a non-standard process or product problem that first needs to investigate users, dependencies, risks and scope.
Independent project work that clarifies the problem, users, dependencies, risks and scope before an implementation price is provided.
Implementation not included
Annual plans for digital work
When software, automation and integrations add up to a year of work, COMPANY (from €5,000/year excl. VAT) can combine implementation and ongoing work. The proposal selects what is needed.
Build around how your company works.
From €5,000/year excl. VAT
A scoped technology plan for your website, specialist content and SEO, internal software, automation, mobile applications, AI and connected hardware.
The proposal selects the building blocks; not every capability is in the starting price.
COMPANY is not discovery only: the plan covers implementation and ongoing work. The Solution Session and Solution Sprint stay separate and optional.
That works. Request this module on its own, without an annual plan. A paid Solution Session or Sprint is optional.
Follow one field task without a connection, then reconnect after an office user has changed the same record. Decide which changes remain pending and who resolves the conflict. The Dutch work-order guide makes this requirement concrete before committing to an app scope.
Choose an app when the work depends on the device — not when a brochure site already answers the query. Camera capture, push alerts, offline drafts or a controlled field checklist are typical reasons.
If visitors only need information and a form, start with a website. If staff need a shared system in the browser, start with a web app.
Build price follows the work the app must do: roles, screens, data, integrations, device behaviour and tests. An app that only shows information is a different job from one that lets several people save changes offline.
At OmniTechs the Solution Sprint price on the pricing page is for independent scope research, not for building the app. A realisation quote comes only after the critical dependencies are clear.
iOS, Android or both — and whether native, hybrid or progressive web fits — are decided in the brief. Store accounts, review rules and signing stay with you unless the engagement says otherwise.
Most apps need a backend, authentication and monitoring. Those pieces are scoped with the app, not treated as free extras after launch.
OS updates, store policy changes, certificates and third-party services create recurring work. We confirm support limits in the engagement instead of implying unlimited aftercare.
For an illustrative field task, specify which draft, photo and completion status the worker may save locally. When the connection returns, the application must distinguish a pending upload from an accepted record and decide who resolves a conflicting edit. Test that task on the intended devices before choosing browser, PWA or native delivery.
Only if both audiences are required for the first release. Starting on one platform can reduce risk when the workflow is still being proven.
When the core action works well in a browser and installation, offline behaviour, push or deep device features are not required.
That is written before start. Business store accounts should stay under your control whenever possible.
Platform updates, security, store requirements, backend, monitoring, third-party services, support and new device versions can all create recurring work.
Describe the workflow, users and systems involved. We confirm platforms, backend and maintenance before quoting build.
