A Field Mobile Application for Property Valuation Assignment Management

Delivered remotely for a business based in Montreal, Canada. Names withheld by agreement.

Project Overview

Industry: Property valuation services for mortgage lending — the working relationship between valuation management organisations and the independent appraisers who carry out inspections.

Type of solution: Two native mobile applications, Android and iOS, phone and tablet, delivered as field companions to an established enterprise platform through a purpose-built mobile API.

Business context: Valuation assignments are distributed by managing organisations to a network of independent, licensed appraisers. Each assignment carries a fee, a due date, property and contact details, and engagement terms that must be formally accepted before work starts. The appraiser then arranges access with a property contact, performs an inspection, and moves the assignment through review and revision to completion — coordinating throughout with the managing organisation. The desktop platform that runs this process was mature and well established. The problem was where the appraiser actually was while the process ran.

General users: Independent field appraisers. Every user is connected to one or more managing organisations, and the applications present all of their work — across all of those organisations — in a single inbox.

General purpose: To let a field professional accept work, schedule it, communicate about it, read the documents attached to it and keep its status accurate, from a phone, in the field, without waiting until they are back at a desk.

The Business Challenge

The work happens where the desk isn't. An appraiser inspects properties. Between inspections they are driving. The system of record was a desktop web portal, which meant the administrative half of the job was compressed into early mornings and late evenings, and everything in between was conducted by telephone and re-keyed afterwards.

Assignment offers are time-sensitive. An offer that sits unanswered gets reassigned. An appraiser who cannot see and respond to offers until the evening loses work to one who can respond within the hour — and the managing organisation loses time chasing an answer.

Acceptance is a formal act, not a button. Accepting an assignment means accepting engagement terms, and accepting with conditions means recording what those conditions are. The paperwork behind that varies by managing organisation and changes for commercial and regulatory reasons. Hard-coding it into two native applications would mean an app store release cycle every time a clause changed.

One professional, several clients. Independent appraisers work for multiple managing organisations. Without a single view, that means several logins, several inboxes and no reliable answer to "what am I actually committed to this week?"

Coordination is conversational. Access arrangements, property condition, revision requests — these are conversations. If the app cannot host them, they happen in email and by phone, outside the assignment record, and the record becomes incomplete.

Documents matter and are not small. Engagement letters, prior reports and supporting documents are PDFs that must be readable in the field, on the device, without exporting them somewhere else.

The platform already existed. This was not a greenfield build. The applications had to fit an established enterprise system, its interface, its data model and its status vocabulary — adding a new channel without asking the business to change how it worked.

Two platforms, one behaviour. Appraisers do not standardise on a phone. Both platforms had to be native, and both had to behave identically, because the managing organisation on the other side of an assignment cannot see which device it came from.

Our Approach

Build to the platform's contract, not around it. The customer already operated the system of record and had defined a mobile interface onto it. We built both clients against that contract as it stood — including its response conventions and its data formats — rather than asking for changes to a live enterprise platform. Where the contract had rough edges, the clients absorbed them defensively so the user never saw one.

Make the acceptance workflow server-driven. Rather than hard-coding acceptance, conditional acceptance and decline forms into two native applications, we built a small rendering engine in each client. The application asks the platform for the form definition appropriate to this assignment and this action; the platform returns an ordered list of typed, captioned, optionally-required controls, including formatted content panels for engagement terms. Each client lays them out, validates them by type, and posts back a generic answer set. New questions, revised terms and changed conditions ship the moment the platform is updated — with no app release on either platform.

Serve legal and help content the same way. Licence agreement, privacy statement, help content and onboarding explanations are fetched from the platform rather than bundled into the binary, for exactly the same reason.

Design the dashboard around the question the user is actually asking. The platform's own status vocabulary is preserved faithfully, but the applications add derived views computed on the device — what is overdue, what has unread messages, what still needs an appointment, what is outstanding overall. These are the four questions an appraiser asks first thing in the morning, and answering them locally from a single payload avoids extra round trips on a mobile connection while guaranteeing the counts match the lists behind them.

Treat the network as unreliable, because it is. The Android client maintains a local mirror of the assignment record so the dashboard renders immediately on launch rather than waiting on a response. The iOS client uses a timed in-memory cache, a decision documented in the code as sufficient for the refresh window in question. Both check connectivity before issuing a request and fail with a clear message instead of a spinner.

Build for tablet properly. Both applications ship genuine master-detail split layouts for large screens alongside their phone layouts, rather than stretching a phone interface across an iPad.

Put the phone's own capabilities to work. Tap-to-call and tap-to-message on every contact number on an assignment, a street-level photograph of the subject property so an appraiser recognises it on arrival, native calendar-style scheduling, in-app document rendering, and push notifications with deep links straight into the relevant assignment, message or document.

Keep the two clients honest with each other. The same status model, the same derived views, the same form engine, the same notification routing, the same defensive handling of the shared contract — implemented independently and natively on each platform, verified for behavioural parity.

The Solution

Single inbox across multiple managing organisations. An appraiser connects to an organisation using a key that organisation issues, and can connect to or disconnect from as many as they work with. Every assignment carries its organisation with it, and the dashboard spans all of them.

Counted status dashboard. The platform's assignment statuses with live counts, alongside device-computed views for overdue work, unread messages, assignments awaiting an appointment, and everything outstanding.

Search across the caseload. Free-text search across assignments, including numeric references, from the dashboard.

Full assignment detail. Property details, engagement information, dates, fee and all associated contacts on one screen, with a street-level photograph of the subject property fetched by address and a setting to switch that off.

Dynamic acceptance workflow. Accept, accept with conditions, or decline — each presenting a form defined by the platform for that assignment and that action, rendered and validated on the device, including formatted engagement-terms panels.

Inspection scheduling. Set or change an inspection date and time against an assignment, with a month calendar view of everything scheduled and drill-through to a chosen day's work.

Per-assignment messaging. Threaded messages with the managing organisation attached to the assignment they concern, with unread counts on the dashboard and on each assignment, composition, and explicit read acknowledgement.

Document access. Attachment lists per assignment with in-app PDF rendering on both platforms, and export to other applications where appropriate.

Granular push notifications. Six independently controllable notification categories with preferences held on the platform so they follow the user across devices, and deep links that open the exact assignment, message or document the notification refers to.

Self-service account management. Registration with email verification returning the user into the application by deep link, credential recovery by email, user-identifier recovery by SMS, and enforced password rules.

Platform-served content. Licence, privacy, help and onboarding content delivered from the platform, changeable without an app release.

Phone and tablet, both platforms. Native Android and native iOS, each with a dedicated large-screen master-detail layout.

Key Features

Server-driven acceptance forms The most business-critical screen in the product is defined by the platform, not the binary. Typed, captioned, validated controls — including formatted terms panels — are returned per assignment and per action, rendered natively on each platform, and answered generically. Terms and conditional-acceptance questions change without an app store release.

Multi-organisation single inbox Connection-key based enrolment with as many managing organisations as the appraiser works with, and one dashboard across all of them.

Device-computed dashboard views Overdue, unread, appointment-required and all-outstanding are derived on the device from a single payload — fewer round trips, and counts that cannot disagree with the lists behind them.

In-field document rendering PDF attachments open inside the application on both platforms, with export where appropriate, so an appraiser reads an engagement letter at the property rather than back at the office.

Inspection scheduling with calendar view Set an inspection time against an assignment and see the month's scheduled work in a native calendar, with drill-through to any day.

Assignment-scoped messaging Conversations attached to the assignment they concern, with unread state surfaced on the dashboard, so coordination stays inside the record instead of scattering into email.

Deep-linked push notifications Six independently controllable categories, preferences held server-side, and payload routing that opens the specific assignment, message or document rather than the home screen.

Property recognition imagery A street-level photograph of the subject property, fetched by address, so an appraiser recognises where they are meant to be — with a user-controlled switch to disable it.

Platform-served legal and help content Licence, privacy and help content fetched rather than bundled, changeable without a release on either platform.

Genuine tablet layouts Master-detail split views on large screens on both platforms, not stretched phone interfaces.

Technical Architecture

Two native clients, one contract. Independent native applications on Android and iOS, built to the same purpose-built mobile interface exposed by the customer's existing enterprise platform, and verified for behavioural parity rather than sharing code.

Networking layer. Each client isolates the platform interface behind a single networking layer that centralises authentication, request construction, connectivity checking, response-envelope interpretation and error surfacing — so every screen consumes a uniform result and no screen knows how the platform's conventions work. On Android this takes the form of a small class per endpoint over a shared request base; on iOS, a single interface factory of closure-based calls.

Dynamic presentation layer. A rendering engine on each platform turns a server-supplied ordered control definition into a laid-out, validated, keyboard-aware native form, and turns the completed form back into a generic answer set. This is what makes the acceptance workflow releasable from the server side.

Local persistence. The Android client maintains a local relational mirror of the assignment record behind a small data-access layer, so the dashboard is available before the network responds. The iOS client uses a timed in-memory cache sized to the refresh window. Session state and user preferences are held in each platform's standard preference store.

Notification layer. Cloud messaging registration with a server-side token registry and re-registration on refresh, six independently controllable categories with preferences held on the platform, and payload-driven deep-link routing into specific records.

Document layer. In-application PDF rendering on both platforms, with retrieval through the platform interface rather than direct file access, and export through the operating system's own sharing mechanism.

Presentation layer. Native screen composition on each platform over shared base classes handling keyboard avoidance, scroll behaviour and navigation styling, with separate large-screen master-detail layouts.

Flow: Native client (phone or tablet) → Authenticated mobile API → Customer's existing enterprise valuation platform → Cloud push notifications back to the device → Deep-linked directly into the assignment, message or document concerned

Technology Stack

Technical Challenges & Solutions

Security & Reliability

Authenticated device sessions. Authentication issues a session credential bound to the device at login, presented on every subsequent call and cleared on logout, with the enterprise platform remaining the sole authority on what any user may see or do.

Server-side authorisation. The clients hold no authorisation logic. Every assignment, message and document request is scoped by organisation and evaluated by the platform, so the mobile channel cannot widen access beyond what the system of record already grants.

Explicit connection consent. An appraiser sees an organisation's work only after enrolling with a key that organisation issued, and can disconnect. Visibility is an explicit, revocable act on both sides.

Self-service credential recovery over separate channels. Password recovery runs through email with a temporary credential and a forced reset; user-identifier recovery runs through SMS to the registered mobile number. Two channels, deliberately.

Registration verification. Account creation requires email verification, returning the user into the application by deep link rather than leaving them at a web page.

Connectivity-aware failure. Both clients check reachability before issuing a request and present a specific, actionable message rather than an indefinite spinner — the difference, in the field, between a user who retries and a user who calls support.

Defensive response handling. Null-tolerant decoding throughout, sentinel-value filtering on dates, and layered fallbacks for error messaging, so an unexpected payload degrades into a clear message rather than a crash.

Crash reporting in production. Both clients report crashes from the field, where reproduction is otherwise close to impossible.

Content governance from the platform. Licence and privacy content is served rather than bundled, so the terms a user is shown are always the current ones.

Scalability & Performance

One request, four answers. The derived dashboard views are computed on the device from a single assignment payload rather than requested separately — fewer round trips on a mobile connection, and counts that always agree with their lists.

Cache windows tuned to real refresh behaviour. A timed cache suppresses redundant full fetches within the window a user is realistically working in, with pull-to-refresh available whenever they want to override it.

Local mirror for cold start. The Android client's local database renders a usable dashboard before the network responds, which on a poor connection is the difference between a usable app and an unusable one.

Efficient imagery. Property photographs load asynchronously through weak-referenced tasks on Android and a caching image component on iOS, so scrolling a list of assignments does not stall on network images.

Push rather than polling. New assignments, messages, documents and status changes arrive by push notification, so the application is not waking to poll and the device is not paying for it in battery.

Stateless clients. All authority and all durable state sit on the enterprise platform; the clients hold a session credential, a cache and user preferences, so a reinstall costs nothing but a login.

Native on both platforms. Native rendering, native navigation and native device integration, chosen deliberately for an application whose users are outdoors, on cellular connections, on devices spanning a wide range of ages.

Business Outcomes

• The administrative half of an appraiser's job moved into the field, rather than into the hours before and after it.
• Assignment offers can be answered immediately, with acceptance, conditional acceptance and decline all completed properly on a phone.
• Engagement terms and acceptance questions became a server-side change, not an app release on two platforms.
• Multi-organisation appraisers gained one inbox, with every assignment scoped to the organisation it came from.
• Coordination stayed attached to the assignment, through in-app messaging with unread state surfaced on the dashboard, instead of scattering into email and phone calls.
• Documents became readable at the property, not back at the desk.
• Scheduling became a native, calendar-driven action, with the month's inspections visible at a glance.
• Time-sensitive events reach the user directly, through granular push notifications that open the exact record concerned.
• The existing enterprise platform gained a mobile channel without being reshaped to accommodate one.

Why it worked

Most mobile projects are not greenfield. The system of record already exists, it works, and the business depends on it — which means the interesting question is not "what would we build?" but "what can we add without asking the business to change?" That is a harder discipline than it sounds, because the honest answer usually involves absorbing someone else's conventions, quirks and vocabulary into your own code so that the user never encounters them.

Our team builds for that reality. We took an established platform's interface as given, wrapped its conventions inside a single isolated layer in each client, and let every screen above that layer stay clean. We built the most business-critical workflow in the product — formal acceptance of a professional engagement — as a server-driven form engine, because we recognised that the content of that workflow changes for reasons outside anyone's development schedule, and that two native applications behind an app review cycle is exactly the wrong place to hard-code it. We built genuine tablet layouts, genuine offline tolerance where it earned its cost, and we documented in the code the one place where we decided it did not.

Our teams work across native Android and native iOS, integration with established enterprise systems, mobile API contract design, server-driven interface patterns, push notification architecture, offline-tolerant client design and field-workforce applications — with the judgement to know which parts of an existing business process should be modelled faithfully, which should be simplified for a small screen, and which should be moved to the server so nobody has to ship an app to change them.

Final Summary

An appraiser's job is to be at properties. The software running their workload assumed they were at a desk — so the offers, the acceptances, the scheduling, the messages and the documents all queued up for early mornings and late evenings, and everything in between happened by telephone and got re-keyed afterwards.

Our team built native Android and iOS applications that move that entire loop into the field. Assignments arrive by push notification and open directly to the record concerned. Acceptance, conditional acceptance and decline are completed properly on the phone, through forms the enterprise platform defines per assignment and per action — so engagement terms and conditional questions change on the server rather than through two app store release cycles. Inspections are scheduled against a native calendar. Messages stay attached to the assignment they concern. Documents open on the device at the property. And an appraiser working for several managing organisations sees all of it in one inbox, scoped correctly to each.

Underneath, both clients were built to an existing enterprise platform's mobile interface exactly as it stood, with that interface's conventions absorbed into a single isolated layer so no screen above it was ever exposed to them. The dashboard answers the four questions a field professional actually asks each morning, derived on the device from one payload. The Android client keeps a local mirror so it is useful before the network responds. Both ship real tablet layouts. Two independent native codebases, one contract, one behaviour — and a mature enterprise platform that gained a mobile channel without having to change how it worked.