What the brief looked like
The client is a major Middle East retailer. The specific name is under NDA until the case study clears. The engagement was a REFORGE — rebuild the point-of-sale workflow on owned software, retire the SAP-vended POS surface for the pilot store cohort, transfer the platform to the in-house engineering team at the end of the build.
The brief from the CIO was specific. He did not want a re-platforming project. He wanted to understand whether a single workflow — the front-of-store transaction surface — could be moved off SAP cleanly without disturbing the ERP backbone behind it. Eight weeks to first store live. Honest scope, honest timeline, owned IP.
This is what the eight weeks actually contained.
What we kept
We did not replace SAP. We replaced one workflow that ran on SAP.
The ERP backbone — finance, inventory master, supplier records, replenishment — stayed exactly where it was. The pilot store's POS terminals retired the SAP POS surface and connected to a new transaction engine the client now owns. The new engine writes back to SAP for the same downstream processes the old POS handled. To finance, the daily reconciliation looks identical. To inventory, the stock movements arrive on the same cadence in the same shape. To the customer at the till, the experience is faster.
The honest framing of the scope is the part that made the eight weeks real. The team did not have to win the argument for replacing SAP. They had to win the argument for replacing the till.
What we replaced
Six things changed under the hood:
- The transaction surface. New POS UI built on a tablet-first React app the store associates actually like using. The associate-training time dropped from two days to four hours.
- The promotion engine. Promotions, loyalty redemptions, and cross-store discounts now run on a rules engine the client's commercial team edits without a release. The SAP POS version required an integrator change request.
- The receipt printer + payment-terminal integration. Direct integration on the new engine, no proprietary middleware required. The old setup carried a hardware vendor with a separate maintenance contract.
- The offline-first transaction queue. The new engine processes transactions when the network is intermittent — a recurring source of friction at one of the older store locations — and reconciles when the connection returns.
- The reporting surface. Store managers now see daily KPIs in a dashboard their team designed, against data their team queries. The SAP POS reporting was a separate licence and required a separate analyst.
- The integration surface to SAP. A single well-defined boundary, owned by the client's platform team, replaces the previous deep coupling that made every till change an ERP project.
The eight-week timeline
Week 1 — discovery. Map the workflows, capture the edge cases, identify the data contracts with SAP. We do not write code in week 1.
Weeks 2 to 3 — build the transaction engine and the SAP boundary. The team is two saasinator engineers, one client platform engineer, one operations lead from the retailer. Working POS UI is live in a staging environment by the end of week 3.
Weeks 4 to 5 — user testing in one store, offline. Store associates use the new POS against synthetic loads while the live POS runs the real transactions. Three rounds of feedback are incorporated.
Week 6 — promotion-engine cutover. The commercial team starts authoring promotions on the new engine, the old SAP promotions are sunset, and the team validates the parity report against last quarter's actual transactions.
Week 7 — payment terminal certification and hardware roll-out at the pilot store. This week is the highest-risk week — the hardware vendor relationships do not run on saasinator's calendar — and we plan for it accordingly.
Week 8 — go-live at the pilot store. Both POS systems run in parallel for the first three days. The SAP POS is decommissioned at the end of the week. The team that operates the new engine is the retailer's own.
What surprised us
Three things were not what we expected.
One — the hardware vendors were the schedule risk, not the software. The payment terminal certification took longer than the rest of the build combined when measured in calendar days the saasinator team was blocked. The lesson on subsequent engagements: the hardware certification work starts in week 1, not week 6.
Two — the parity report was the conversation that mattered. The commercial team did not trust the new system until they could see a quarter of historical transactions replayed through the new engine and the reports matched exactly. We had treated the parity report as a verification step. It was actually the trust-building artifact.
Three — the store associates loved the new POS more than we expected. The user-research signal in week 4 was unambiguous. The training time dropped because the new UI was simpler, not because the associates had been trained better. The lesson: do not let the SAP UI conventions anchor the new design.
The saasinator perspective
The CIO who ran this engagement made the move other Middle East retail CIOs are starting to make: he picked a single workflow where the SAP user experience was the weakest part of the operation, replaced it cleanly without disturbing the parts that worked, and transferred the new platform to his own team. The SAP renewal coming up next year is now a renegotiation against a smaller surface area.
We are not arguing that every retailer should rebuild their POS. We are arguing that the strongest case for REFORGE in a retail environment is the workflow closest to the customer, owned by an internal team operating against a stable ERP boundary. The POS is that workflow more often than CIOs realise.
What comes next for this client
The pilot store has been live for the case-study quarter. The retailer is rolling the new POS engine out to the next cohort of stores on a fixed schedule. The SAP POS licence will be reduced at the next renewal in proportion to the active till count. The conversation with SAP shifts from "expand the deployment" to "shrink the surface" — exactly the conversation the CIO wanted to be having.
If you are running an SAP-vended POS at scale in the Middle East and your hardware refresh cycle is approaching, the moment to model the replacement option is now. The diagnostic puts the math on paper.
Book a diagnostic. Ten working days. We will tell you which store cohort is the best pilot candidate and what the eight weeks would look like for your estate.