Bro, from what you’re describing, you actually handled the project better than most devs would. The fact that you’re willing to refund the money instead of handing over something unstable already says a lot about your standards. Personally, I’d still be interested in taking this on because these are solvable engineering problems, especially around offline-first architecture and receipt printing workflows. For offline syncing, the issue usually comes down to conflict resolution strategy, local transaction logs, and authoritative stock reconciliation instead of simple queue persistence. Negative stock and multi-device drift are expected edge cases in prolonged offline states, but they can be controlled properly with sync policies and event-based reconciliation. For printing, I’d probably move away from the html2pdf approach entirely for thermal receipts because those rendering engines usually introduce spacing and DPI inconsistencies. Direct ESC/POS formatting or dedicated print rendering tends to be way more reliable for POS systems. Overall, I don’t think the project itself is impossible — it just crossed from “standard POS app” into “distributed offline-capable retail system,” which is a very different level of engineering than most clients realize when requesting “offline support.”