What an offline-first point-of-sale app has to get right

Elvin Ega — Wed, 30 Sep 2026 07:14:08 +0000

What an offline-first point-of-sale app has to get right

A shop on a Saturday afternoon. The connection drops. The queue is six people deep. The cashier finishes the sale, prints the receipt, and the stock count updates.

Weza POS is built on the assumption that the second half of that story is the normal case, not the outage case.

The constraint moves into the data layer

Most point-of-sale apps are thin clients. The till asks a server for the price, the server records the sale, the server adjusts inventory. When the server stops answering, the till stops being a till.

Weza POS puts the database on the counter computer. Checkout, barcode scanning, receipt printing, and stock deduction all run locally. Cloud sync is something you switch on, not something the checkout path waits for. Backup files are local, and data export is available from the app.

That single decision pushes work into places a cloud-first design never has to think about:

The local database is the source of truth, so reconciliation is your problem.
Backups are the shop's responsibility unless they pay for off-site.
Reports have to be computed from local data, not queried from a warehouse.

Hardware is where the ugly parts live

POS integrations get difficult at the device layer, and this is the part developers underestimate.

Thermal receipt printers in this class speak ESC/POS, which is a command set rather than a driver. You are writing bytes to a device, whether that is a serial port, a USB endpoint, or a network socket. The 58mm and 80mm roll widths are the two common form factors.

Barcode scanners in keyboard-emulation mode present as a keyboard, so they need no driver. That is why "works with a standard USB scanner" is achievable. Cash drawers are usually kicked by a pulse sent over RJ11 or RJ12, often through the printer rather than directly.

None of that is hard on its own. It gets hard when you have to support the long tail of hardware a real shop already owns.

Shipping the same app to three platforms

The builds are an .exe for Windows, a .dmg for macOS, and .deb or AppImage for Linux. ⟨verify⟩

Desktop distribution means you own updates, code signing on two platforms, and whatever the Linux packaging story turns into. A web app avoids all of it, which is the trade you make for working offline.

The licence model is a product decision

The Pro tier is a one-time payment per device. The Business tier is a subscription that adds cloud backup and sync, plus the multi-staff features. ⟨verify⟩

That split is coherent. Offline resilience is what you buy once. Off-site durability is what you rent. A shop that wants both a local database and automatic remote backup pays monthly, and a shop that is willing to run its own backups does not.

Questions I would ask before picking it

If you are evaluating this for a shop you support, these are the ones that decide it:

How does sync resolve conflicts? If two tills sell the same last unit while both are offline, what does the merged inventory look like?
Is the local database encrypted at rest, and where do the keys live?
What is the restore path from a backup file, and how long does it take on a busy morning?
Which printers and scanners have actually been tested? The compatibility list matters more than the feature list.
Is sync one-way or two-way? One-way upload is easier to reason about and easier to recover from.
What happens to reports and history if a subscription lapses?

The site answers some of these and not others. ⟨verify⟩

Where this design fits

One or two tills, a fixed counter, and an internet connection you cannot depend on. A pharmacy that cannot hold a queue while a connection resets. A bar on a Friday night.

If you are running a cloud POS in a place with reliable connectivity, the offline architecture buys you less. If you are not, it is the difference between a lost sale and a recorded one.

Supercharging AI Development with code-contextify

Elvin Ega — Fri, 15 Aug 2025 11:20:19 +0000

As AI-powered coding becomes the norm, one challenge keeps popping up — how do we give AI models complete context about our codebase? If you’ve ever tried pasting a dozen files into ChatGPT, Claude, or Gemini, you know the pain.

That’s exactly where code-contextify comes in.

This nifty CLI tool takes your entire codebase, cleans it up, and turns it into a single AI-ready text file — perfect for sending to any large language model.

🚀 What is code-contextify?

Simply put, code-contextify scans your project, applies smart filters (respects .gitignore, skips binaries, removes irrelevant noise), and outputs a formatted, readable text file that contains:

📊 Project statistics (total files, total size)
🌳 Directory tree with excluded file markers
📄 Full file contents (only relevant code and docs)

This means that instead of AI guessing about your project, you can hand over full, precise context in one shot.

💡 Why Developers Love It

Full AI Context — Feed GPT, Claude, or Gemini the entire codebase
Perfect for Code Reviews — Share with teammates without sending raw repos
Great for Debugging — AI can see the full picture
Automated Filtering — No more handpicking files
Privacy First — Runs locally, no data leaves your machine

📦 Installation

npm install -g code-contextify

Or without installing:

npx code-contextify /path/to/project

⚡ Basic Usage

# Convert current directory into AI context
code-contextify

# Convert a specific directory
code-contextify /path/to/project

# Custom output file
code-contextify my-context.txt

Example:

code-contextify review-context.txt --filter "node_modules,dist,*.min.js"

This generates review-context.txt containing only the files that matter.

📊 What the Output Looks Like

Project Statistics:
Total Files: 42
Total Size: 1.25 MB

Folder Structure (Tree)
=====================
Legend: ✗ = Excluded
├── src/
│   ├── components/
│   │   ├── Header.js
│   │   └── Footer.js
│   └── utils/
├── node_modules/ ✗
├── package-lock.json (123.45 KB) ✗
└── README.md (2.34 KB)

Followed by:

src/components/Header.js
------------------------
import React from 'react';
// ... actual file content

📏 Counting Tokens Before Sending to AI

Before sending your context file to an AI model, it’s smart to check token usage — especially for models with smaller context windows.

You can use QuizGecko’s Token Counter to paste your generated file and see how many tokens it contains.

🎯 Sending to Any AI Model

Once you have your .txt file, you can paste it directly into an AI chat or send it via API.

Example with OpenAI API:

import fs from 'fs';
import OpenAI from 'openai';

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const context = fs.readFileSync('project-context.txt', 'utf8');

const response = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [
    { role: "system", content: "You are a senior developer reviewing a project." },
    { role: "user", content: `Here is the full project context:\n${context}` }
  ]
});

console.log(response.choices[0].message.content);

You can swap gpt-4 for Claude, Gemini, or any other LLM.

📥 Try It Now

GitHub: github.com/ElvinEga/code-contextify
NPM: npmjs.com/package/code-contextify

Stop pasting files one by one — let your AI see everything at once.

Turn your codebase into conversation — one context file at a time.

DEV Community: Elvin Ega

What an offline-first point-of-sale app has to get right