What to Look For in a Custom Mobile Build for B2B

Most B2B mobile builds fail in the brief, not the build. Someone writes a scope based on what they need from their desk — dashboards, admin controls, reporting views — and hands it to a developer. The people doing the actual work in the field get a product that takes twelve taps to log a job and crashes when the signal drops. Version two never ships because version one is still being fixed.

Custom mobile software for B2B is a different discipline from consumer apps. The users aren't choosing your product; they're being handed it. The environments are hostile — sites, warehouses, vehicles, trade floors. The workflows are specific and often awkward. Getting this right starts well before any code runs.

Start with the workflow, not the feature list

The most useful question you can ask before scoping a mobile build is: what does the person doing this job need to do in thirty seconds, possibly with one hand, on bad signal?

That question cuts through a lot of scope. If the answer is "log a delivery exception with a photo and a note", your v1 needs photo capture, a short form, and reliable offline queueing. It does not need a dashboard, a reporting tab, a user management screen or an in-app messaging system. Those are real needs — they're just not field needs, and packing them into v1 is the most reliable way to miss your shipping date.

Map the actual workflow. Talk to the people who run it, not just the people who manage it. A 200-person freight business whose drivers are logging proof-of-delivery on paper has a completely different mobile scope from a 200-person freight business whose drivers already use a carrier's app but need to cross-reference it against a custom job sheet. Same industry, entirely different build.

Offline capability is a decision, not a detail

For any field-facing mobile product, offline support needs to be a first-class requirement, decided at the start and scoped accordingly — not bolted on after the first demo when someone points out the site has no signal.

Offline-first architecture changes how you structure your data layer, how you handle conflicts when the device syncs, and how you test the product. Adding it mid-build is expensive and messy. Leaving it out entirely means you've built a product that's useless on a construction site, in a warehouse, at a trade show, or anywhere outside a city-centre office.

If your users will ever be somewhere without reliable connectivity, decide upfront what needs to work offline and to what degree. Full CRUD offline with sync on reconnect is one answer. Read-only access to pre-loaded data is another. Neither is wrong — but they're not the same build, and the scope needs to say which one you're committing to.

Build vs buy for B2B mobile

The honest test: can a SaaS tool cover your core workflow without three or more workarounds?

Tools like Fulcrum, Jobber, ServiceM8 or Inspectorio cover a lot of field-service and inspection use cases competently. If your workflow fits their model, start there. Configuration is faster and cheaper than a custom build, and the maintenance burden stays with the vendor.

But SaaS mobile tools are built around their own data models. The moment your workflow has non-standard roles, unusual data structures or a deep integration requirement with a system the SaaS tool doesn't support natively, you start accumulating workarounds. A workaround or two is fine. When you're maintaining five of them and staff are keeping parallel spreadsheets to compensate, you're paying for a SaaS licence and the cost of the workarounds. At that point, a custom build that fits your actual process is often cheaper over three years.

The calculation shifts further toward custom when data ownership matters — regulated industries, sensitive client data, or cases where the SaaS vendor's data portability terms would leave you stranded on exit. For a deeper look at these trade-offs in the context of MVP scoping, our guide on what an AU MVP actually costs and the UK equivalent cover the numbers in detail.

iOS, Android, or both?

For B2B, this is usually a policy question, not a technical one. Most companies with managed device programmes have standardised on one platform. Ask before you spec.

If your user base is genuinely mixed — or if you're building for an external audience like trade partners or sub-contractors who bring their own devices — a cross-platform framework (React Native or Flutter) lets you target both from a single codebase. The performance penalty is minor for most B2B workflows. The cost saving over two separate native builds is real.

Go native when the product's value depends on hardware access (camera performance, NFC, Bluetooth peripherals) or when you're hitting platform-specific APIs that cross-platform frameworks handle poorly. For a job-logging or inspection app, cross-platform is almost always the right call.

Scoping the MVP: what stays, what goes

The discipline here is naming what goes into version two before you finalise the v1 scope, not after. Putting features in a "later" bucket feels like a loss in the moment. It's actually the decision that gets things shipped.

A workable B2B mobile MVP usually covers:

• The primary field action (log, capture, submit, approve)
• Two or three user roles with appropriate permissions
• The one integration that makes the data useful (your ERP, your CRM, your job management system)
• Offline capability if the environment requires it
• Basic push notifications if the workflow depends on real-time handoffs

What routinely ends up in v1 that shouldn't: in-app reporting (a web dashboard does this better), user management UI (admin tools for your ops team don't need to live in the mobile app), and "nice to have" secondary workflows that affect maybe 10% of daily use.

If you're commissioning for an exhibition or trade environment, the scope mistakes we see most often from exhibition organisers overlap heavily with mobile builds — the pattern of over-scoping v1 is consistent across sectors.

How AI-assisted delivery changes the timeline

A studio using AI tooling across the build process — specification drafting, boilerplate scaffolding, automated test generation — can compress certain phases meaningfully. The gap between a locked scope and a testable prototype shrinks. Acceptance criteria that used to take a week to draft can be produced in a day and reviewed against the brief.

What this doesn't do is replace discovery. If the workflow mapping is wrong, the build is wrong — faster production of the wrong thing is not an improvement. The value of AI-assisted delivery is in the execution phases, once you know what you're building and for whom. What AI-accelerated delivery actually looks like in practice is worth reading before you brief a studio on timeline expectations.

For a well-scoped B2B mobile MVP — one core workflow, clear user roles, a single system integration — a competent studio using AI tooling can typically get to a testable build in eight to twelve weeks from scope sign-off. Complexity, platform breadth and integration depth all move that number. Scope drift moves it more than anything else.

Briefing a studio: what they need from you

The brief that gets a useful quote has three things: a description of the current workflow (including how it breaks), the user roles and their environments, and the one integration that matters most in v1.

A good studio will push back on the scope — that's a sign they've read it. If they quote without questioning anything, they've either built exactly this before or they'll be back with change requests inside four weeks.

Fix the contract structure before you start: time-and-materials through discovery, fixed price once the scope is locked and accepted criteria are agreed. That's the arrangement that protects both sides. The fixed price vs time-and-materials breakdown covers why the contract type affects more than just cash flow.

Get the field workflow right first. Everything else follows from that.