A nationwide mobile sales-quotation app, integrated with SAP

TL;DR

• Greenfield brief: replace an inconsistent, offline-tolerant quotation flow with a mobile-first app for distributed sales teams.
• I led the architecture and led a team of 3 to ship a mobile-first quotation app on Laravel + Filament, with SAP as the source of truth.
• The app rolled out to sales staff across the country and gave the business a real-time view of quotation activity alongside the existing SAP flow.

Context

The client had sales teams across the country handling business-to-business and high-value retail quotations. The shape of the brief is one anyone who has digitized a sales process will recognise:

• A salesperson surface that needed to work on a phone, in a store, on a variable connection.
• A quotation flow whose system of record was SAP, with everything else expected to converge on it.
• A business that wanted a live picture of quotation activity rather than only what eventually landed downstream.

The mandate was different from the rescues: this one was greenfield, but with a hard integration constraint. SAP was the system of record and was not going to move. Anything new had to plug into it without becoming another fragile bridge.

Constraints

The non-negotiable: the salesperson on the floor must always be able to produce a credible quote, even on a flaky connection.

Decisions

Decision 1 — Laravel + Filament for speed-to-rollout, not for novelty

The temptation in 2025 was to reach for a fashionable stack. The right answer for a small team and a nationwide deadline was the one we could ship.

Boring on purpose. The novelty budget went into the SAP integration, not the framework choice.

Decision 2 — Mobile-first PWA, not a native app

Same reasoning as earlier PWA work, applied at higher stakes.

For a tool used by employees rather than customers, a PWA was the obvious right answer — fewer moving parts, faster iteration, no rollout choreography.

Decision 3 — Treat SAP as a contract, not as a runtime dependency

SAP was the system of record. It wasn't, however, fast or always available. If the app called SAP synchronously on every action, the salesperson on the floor would feel every SAP hiccup.

This is the pattern I carried over from the e-commerce rescue: a single integration module with a typed interface, observable, retry-aware, and replaceable. The app reads from a local projection and writes through the module — SAP is the contract, not the runtime.

Decision 4 — Design for variable connectivity from day one

Sales sites don't have a uniform network story. Treating offline as an exception meant it would never be tested; treating it as a default meant it just worked.

The business outcome of this decision was simple: a salesperson on a bad connection still closes the quote.

Decision 5 — Filament as the back-office, not as the strategy

Filament made the admin surface cheap to build. That meant we could spend the saved time on the SAP integration and the mobile experience — not on yet another bespoke admin.

Outcome

By rollout:

• The app was deployed across multiple regions, covering multiple sales teams.
• Quotes were consistent with SAP catalog and pricing at the moment of generation.
• The business gained a real-time view of quotation activity alongside the SAP-of-record view.
• The SAP integration module became a reusable pattern across the other platforms my team worked on in the same engagement.

This was the build where the integration-module pattern proved generalizable: write the SAP boundary once, reuse it across products.

What I'd do on GCP today

Same brief today, same constraints, same SAP. The architecture instincts wouldn't change; the platform underneath would.

• Back-office runtime: containerize the Laravel app for Cloud Run. Same artifact, no host-management work.
• SAP integration: keep the single-module pattern. Move the writes onto Pub/Sub so the app never blocks on SAP, and the integration module becomes a Pub/Sub consumer with retries and a dead-letter topic.
• Catalog + pricing projection: sync from SAP into BigQuery (analytics) and Firestore or Cloud SQL (hot reads). The mobile app reads from the projection; SAP stays the system of record.
• Mobile surface: the same PWA, hosted on Firebase Hosting with offline caching via service workers. Optionally wrapped with Capacitor and shipped through Firebase App Distribution for staged rollouts.
• Real-time demand view: stream quote events into BigQuery and surface them in Looker Studio for the business — the data surface that was a side-effect on-prem becomes a first-class deliverable.
• Delivery: GitHub Actions → Cloud Run + Firebase, preview environment per PR. The same predictability we earned manually, but for free.

The shape of the work is the same as the rescues — a boring framework, a single integration boundary, an offline-first surface, and observability from day one — but the platform underneath does most of the heavy lifting.

If you have a SAP-coupled process that still depends on manual coordination, I'd be glad to compare notes on what a small focused build could look like. Reach out here.