WEEK 12 | 19–23 OCTOBER 2026

Build. Stabilize.
Ship with confidence.

AI Marketing, HireRosterly, and BWP POS — integration, QA hardening, and React Native parity.

Prepared by Hassan • Weekly Technical Blog

01 | Executive overview

Week 12 focused on three forms of engineering delivery: integrating a new communication capability, converting QA findings into stable product behavior, and carrying recent web changes into a production-oriented React Native experience. Across the three projects, the common theme was moving beyond “feature complete” toward behavior that is dependable in the environment where users actually run it.

In AI Marketing, I implemented WhatsApp functionality and verified that the flow works correctly in local development. The remaining blocker is deployment-specific: Vercel currently exposes a Chromium/runtime issue that must be resolved before the integration can be considered production-ready. I also improved the Leads workflow by enabling email to be sent directly from an individual lead, reducing navigation and keeping outreach tied to the selected record.

In HireRosterly, I worked through QA-reported defects and resolved most of the reported issues. The remaining work is limited to a small number of cases requiring final verification. The emphasis was not only on closing defects, but also on regression testing so that changes did not destabilize adjacent workflows.

In BWP POS, I implemented recent web-side changes in the React Native mobile application and worked across UI responsiveness, navigation, POS and inventory flows, orders, settings, DTO handling, receipts, localization, printer behavior, and shop-name output. Validation included TypeScript, Jest, ESLint, Expo, Android/Web export, and runtime checks to catch issues at multiple layers of the mobile stack.

02 | AI Marketing — WhatsApp integration and lead outreach

WhatsApp functionality

The main AI Marketing feature work was the WhatsApp integration. I connected the functionality into the application and verified the expected behavior locally. Local validation confirmed that the integration logic and development environment can execute the workflow correctly, which narrowed the unresolved problem to deployment rather than the core feature implementation.

Deployment challenge: Chromium/runtime behavior

The same workflow does not yet complete successfully on Vercel because of a Chromium/runtime deployment issue. This is an important distinction: a feature can be correct at the application layer while still failing in production when its browser or automation dependency is not compatible with the serverless runtime. The current task is therefore to identify a production-compatible Chromium strategy, verify required binaries and launch options, and retest the full WhatsApp path in the deployed environment.

Lead email improvement

I also updated the Leads section so an email can be initiated directly from an individual lead. This reduces interaction cost because the user no longer needs to leave the selected lead context before starting outreach. The change improves task continuity: review a lead, decide to contact it, and trigger the email action from the same working context.

Technical lesson: local success should be treated as one test environment, not as deployment proof. Integrations that depend on Chromium, headless browsing, native modules, or external runtimes require explicit environment validation before release.

03 | HireRosterly — QA bug resolution and regression stability

HireRosterly work centered on QA feedback. I addressed the reported bugs, resolved most of the identified issues, and reduced the remaining set to a few cases that still need final verification. The focus was to convert each QA observation into a reproducible scenario, implement the fix, and then retest connected behavior rather than treating the defect in isolation.

Regression testing was a major part of the work. A bug fix can be locally correct but still introduce a side effect in a shared component, validation rule, navigation path, or data flow. Retesting the surrounding product areas helped improve confidence that the fixes increased product stability instead of simply moving defects elsewhere.

The remaining issues are now in a verification phase rather than broad implementation. The next milestone is to close those final cases with clear expected-versus-actual checks and record the regression outcome for the affected workflows.

Technical lesson: QA resolution is strongest when “fixed” and “verified” are separate states. The implementation closes the code-level issue; regression and scenario testing establish product-level confidence.

04 | BWP POS — web-to-mobile parity in React Native

For BWP POS, I implemented recent web changes in the React Native mobile application. The goal was functional parity rather than literal UI duplication. Web behavior provided the reference, while the mobile implementation had to respect touch interaction, smaller viewports, mobile navigation conventions, and platform-specific runtime constraints.

The work covered POS, inventory, orders, settings, DTO-related handling, receipts, and associated mobile flows. These areas are interconnected, so parity work required checking both individual screens and the transitions between them. Changes were evaluated in terms of user outcome: the mobile path should produce the same business result as the web path even when the interaction model differs.

UI responsiveness and navigation

I improved mobile UI responsiveness and adjusted navigation behavior, including single-step Back handling. Predictable Back behavior is especially important in transactional applications because unexpected multi-step navigation can cause users to lose context, repeat work, or exit a flow unintentionally. The changes focused on making secondary screens return to the immediately expected state.

Localization, printer, and receipt behavior

I implemented and improved application language switching and worked on printer/receipt language behavior. Receipt output was refined together with shop-name handling so the printed result better reflects the active language and business identity. These changes required attention to both UI state and the data that ultimately reaches receipt generation or printer output.

Validation discipline

During development I used multiple validation layers: TypeScript for type-level correctness, Jest for automated behavior checks, ESLint for code-quality issues, Expo for application tooling, Android/Web export checks for build compatibility, and runtime validation for behavior that only appears when the application actually executes. Using these checks together reduces the chance that a change passes one tool while failing at another stage of delivery.

05 | Problems encountered and solutions

06 | Technical lessons and outcomes

• Environment parity is part of feature delivery. A successful local integration is only one stage; production dependencies, binaries, and runtime restrictions must be tested explicitly.
• Regression testing converts bug fixing into product stability. Fixes should be evaluated against neighboring workflows and shared components, not only the original reproduction path.
• Cross-platform parity should be defined by behavior and outcome. React Native implementations can differ visually from web while still remaining consistent in validation, navigation, and business results.
• Localization is an end-to-end concern. Language selection can affect screen text, receipt generation, printer output, and business-identifying fields such as the shop name.
• Multiple validation layers catch different classes of failure. Type checks, unit tests, linting, build/export checks, and runtime testing are complementary rather than interchangeable.

Outcome: Week 12 closed substantial implementation and QA work across all three products. AI Marketing now has a locally validated WhatsApp flow and faster lead-email outreach; HireRosterly is near the end of its QA cycle; and BWP POS has stronger mobile parity, navigation, localization, receipt behavior, and validation coverage.

07 | Next steps

• AI Marketing: resolve the Vercel Chromium/runtime issue and run end-to-end production validation of the WhatsApp workflow.
• AI Marketing: verify the direct email action from individual leads across the expected lead states and email flow.
• HireRosterly: complete final verification on the remaining QA cases and document regression results for impacted workflows.
• BWP POS: continue parity checks against recent web changes, with emphasis on device-level navigation, language switching, printer/receipt output, and shop-name behavior.
• BWP POS: keep TypeScript, Jest, ESLint, Expo, export, and runtime validation in the development loop as remaining edge cases are closed.

08 | Closing reflection

Week 12 was defined by the difference between implementing a change and proving that it is dependable. The WhatsApp feature demonstrated how deployment environments can become part of application behavior. HireRosterly reinforced the value of regression testing after QA fixes. BWP POS showed that mobile parity is a continuous engineering exercise across UI, navigation, localization, receipts, builds, and runtime execution. The next step is to close the remaining verification gaps so each improvement is reliable in the environment where users depend on it.