As developers, we tend to live inside the code. But successful project delivery depends on much more — understanding quality signals, data flows between systems, and the architectural decisions that shape how a business runs online.
This post distills the key lessons from Scandiweb's Business-Aware Development course into a practical reference. Whether you work in eCommerce or not, these concepts apply anywhere software meets business.
Part 1: Manual QA — Thinking Like a Tester
What is a bug?
Anything that prevents the client from operating their business as intended. It can be a broken checkout button or a subtle typo that damages brand trust. Both matter.
The 6 bug types
1. Content — Text/content deviations from what's expected.
- Spelling errors, untranslated text, placeholder content ("Lorem ipsum"), dead links, missing pages
- Reporting: Describe the exact position on the page. Leave zero room for confusion.
2. Visual — Inconsistencies between the live site and approved designs.
- Wrong fonts, colors, spacing, margins; missing hover states; content overflow; misaligned elements
- Reporting: Include the URL, link to the design, and provide a side-by-side comparison. For responsive issues, include the screen resolution.
3. Cross-Browser — Works in one browser, breaks in another.
- Reporting: Always include browser name and version. Without it, reproducing is nearly impossible.
4. Cross-Device — Same browser, different device, different result.
- Reporting: Specify the exact device. Standard testing covers iPhones, Android phones, and tablets.
5. Functional — Behavior that doesn't work as intended or at all.
- Filters not filtering, price mismatches, failed signups that show success, infinite checkout loaders
- Reporting: A good title is 90% of the success. Always include steps to reproduce, actual result, and expected result.
6. Performance — Operations taking too long. General rule: nothing should exceed 2-3 seconds.
- Check: page load (incognito, cleared cache), search speed, filter responsiveness, image sizes (~25-30KB per listing image), add-to-cart, checkout, login
- Reporting: Include the URL, steps taken, and measured time.
Reporting rules
- One issue per ticket — never group multiple bugs together
- Browser version — only required for cross-browser bugs; put "ANY" for everything else
- Priority — usually set by the PM, but use common sense (payments = always top priority)
- Intermittent bugs — clearly flag if a bug doesn't reproduce consistently
You don't always need full specs
Use common sense. Check standard flows (search, filter, cart, checkout, login), verify essential pages exist (About Us, T&C, Shipping), and flag obvious inconsistencies. QA should be part of task definition before development, not just after.
Part 2: Data Flows & ERP Integration
Key concepts
SKU (Stock Keeping Unit) — A product's unique public identifier (e.g., NIKE-AIR-MAX-90-BLK-US10). It's the common language between warehouse, website, support, and ERP. When systems need to agree on "which product," they match on SKU.
ERP (Enterprise Resource Planning) — The backbone system that existed before the online store. It manages what eCommerce doesn't:
- Warehouse management (trucks arrive, products scanned, stock updated)
- Point of Sale (physical store registers)
- Order processing & fulfillment
- Accounting, tax reporting, business intelligence
- Customer support & after-sales
The ERP is the "ugly but essential" internal system. The storefront is the "pretty face." Both need to sync.
Common order statuses:
| Status | Meaning |
|---|---|
| Pending | Awaiting payment confirmation |
| Processing | Payment confirmed, being prepared |
| On Hold | Paused (stock issue, fraud review, etc.) |
| Shipped | Handed to carrier |
| Delivered | Customer received it |
| Cancelled | Cancelled before shipment |
| Refunded | Money returned |
| Closed | Complete, no open disputes |
Why developers should care
If systems don't sync: customers buy out-of-stock items, the website shows stale prices, and 10,000 daily orders can't be manually copy-pasted into the ERP. "ERP integration" is really just data exchange — specific pieces of data traveling between two databases.
The ETL pattern: Extract, Transform, Load
Extract — Get data out of the source system in a usable format (CSV, XML, JSON, API).
SKU, Qty, StoreID
NIKE-AIR-90-BLK, 20, 50
NIKE-AIR-90-BLK, 90, 80
NIKE-AIR-90-BLK, -34, 03
(Negative quantity = backorders — people paid for items not yet in stock.)
Transform — Shape data to fit the destination. Example: the site doesn't need per-store stock, so sum it up: 20 + 90 + (-34) = 76 available units.
Load — Insert into the target system. Trigger reindexing, invalidate caches, confirm it took effect.
What flows where
| Direction | Data |
|---|---|
| ERP to eCommerce | Product catalog, pricing, stock, store info |
| eCommerce to ERP | Orders, customer data |
Practical takeaways
- Ask "where does this data live?" before building any feature
- SKU is your universal key across all systems
- Think in data flows, not "integrations" — what data, which direction, how often?
- Understand the business impact — a stock sync delay means overselling; a price sync failure means revenue loss
- Request only what you need — don't import full database dumps
- Delta over full sync — once basics work, sync only what changed
Part 3: From SSR to CSR — The Magento to ScandiPWA Shift
Server-Side Rendering (the old way)
Traditional Magento: user requests a URL, the server builds a complete HTML page (fetching data, merging with templates and CSS), sends it to the browser. Every click = full page rebuild.
The server does everything. The browser just displays.
Client-Side Rendering with ScandiPWA (the new way)
ScandiPWA flips this. The browser becomes the rendering engine:
- First load — Browser downloads the entire app (layouts, styles, fonts). It's an empty store — no product data yet.
- Data requests — The app asks the server for specific data via GraphQL: "give me the 6 best sellers," not "give me the whole homepage."
- Rendering — React takes the data, injects it into components, renders locally.
- Navigation — No full reloads. The app already has the layout; it just swaps in new data.
The architecture at a glance
| Component | Role |
|---|---|
| React (ScandiPWA) | The app — all UI, components, styles, routing |
| GraphQL | The only data pipe between frontend and backend |
| Service Worker | Local proxy — caching, offline mode, decides server vs. cache |
| Varnish | Server-side cache for GraphQL responses (~20ms) |
| Redux | Client-side global state |
SSR vs CSR compared
| SSR (Traditional) | CSR (ScandiPWA) | |
|---|---|---|
| What's sent | Full HTML pages | Small JSON data |
| Who renders | Server | Browser |
| Page transitions | Full reload | Instant, app-like |
| Offline support | None | Service Worker cache |
| First load | Fast (one page) | Slower (full app shell) |
| Subsequent loads | Same speed | Much faster |
| Response size | Large | Up to 10x smaller |
What happens to Magento extensions?
The old Magento frontend is gone. Extensions don't "just work" in ScandiPWA.
New extension — You build two packages:
- Backend (PHP): admin grids, DB tables, business logic + GraphQL resolvers
- Frontend (React): ScandiPWA extension with components, styles, GraphQL queries
Existing marketplace extension — Backend works, but needs:
- GraphQL resolvers (many extensions already include them — check first)
- A React "compatibility extension" on the frontend
Example (Stripe): Backend already handles payments. Frontend work = 3-4 input fields in checkout + success/error message. Minimal.
Backend-only extensions (reporting, analytics) need no frontend work at all.
Practical takeaways
- GraphQL is the only bridge — if data isn't exposed via GraphQL, the frontend can't use it
- Think in two packages — backend (PHP + GraphQL) and frontend (React), developed separately
-
Varnish still matters — tag your data with
X-Tagheaders for proper cache invalidation - Service Worker = local intelligence — key to debugging "why isn't my data updating?"
- Assess extension impact first — "does it have GraphQL?" determines the scope of work
- The frontend is an application, not a template — you're building a React app that consumes an API
Final Thought
Writing code is one part of the job. Understanding why the business needs it, how quality is measured, where data lives, and what changes when architecture evolves — that's what makes you effective on a real project.
This post is based on learnings from Scandiweb's Business-Aware Development course. All credit for the original course content goes to Scandiweb.
Top comments (0)