flutter-pos-system: an offline point of sale for a small restaurant

A point of sale that keeps everything on the tablet

flutter-pos-system is described as an open-source Flutter app designed for small restaurants and businesses, and the target is explicit in both the description and the repository topics, which name android-app, app, flutter, ios-app and possystem.

The interesting thing about this project is not the feature list, which is a fairly standard POS set, but the three design principles stated alongside it. The first is offline usage, meaning the system can be used even without an internet connection. The second is privacy-focused, with the statement that no personal data is stored remotely and only on your device. The third is responsive width design, which for a point of sale matters more than it sounds, because the same app has to work on a phone in the hand and a tablet on the counter.

Those three principles together explain the whole architecture. A till that works offline has to hold its own state, and a till that stores customer demographics on the device has to treat the device as the database rather than as a thin client for one. That is a coherent design for a single venue, and it is also exactly the design that does not scale to a chain, which is the trade to keep in mind.

The project ships with English and Chinese documentation, the Chinese version being the default link in the readme, and the site is built with MkDocs from the docs/ directory in the repository.

Inventory, register and customers, and what each screen is for

The feature list is six items, and reading them as a workflow shows what the application is actually for.

The inventory system monitors and manages ingredient inventory, which is the part that distinguishes this from a generic till. A restaurant's stock is its cost, and the tool that decides what to reorder is the one the owner opens at the end of a service.

The cash register feature is described as simplifying daily balance calculations, which is the arithmetic of a shift rather than a full accounting system. The customer information feature captures customer demographics such as age and gender for analytics, which is a deliberate choice to record more about the people who buy rather than less.

Transit covers exporting and backing up orders, menus and other data for external use, which in practice means the owner can get their data out to a spreadsheet for their own analysis, and that is a consequence of the local-first storage model rather than a separate feature.

Analytics lets the owner create custom line charts and pie charts. The word custom is doing the work here, since the point is that the data is yours and the charts are generated by the app rather than pulled from a hosted dashboard.

The printer feature prints receipts over a Bluetooth connection, which is the detail that makes this deployable in a real restaurant: receipt printers that pair over Bluetooth to a phone or tablet are common in the small-venue market precisely because a wired or networked printer is not.

The build tooling, and the release process behind the version numbers

The repository is a Flutter project with the usual Dart surroundings, and the Makefile at the root is the entry point for development work. The targets are conventional and worth listing, because they tell you what the maintainer considers part of the definition of done:

format: ## Format code
	dart format --line-length 120 .

lint: ## Lint code
	flutter analyze .

test: ## Run tests
	flutter test

There is a coverage target that runs flutter test --coverage, then strips the generated localisation files out of the report with lcov, generates HTML with genhtml and opens the result. Excluding lib/l10n/gen/* from coverage is a sensible detail, because generated localisation code is not code anyone writes and counting it inflates the number.

There is an outdated target that runs flutter pub outdated with --no-transitive and --no-prereleases, which is the right way to run it, since transitive updates and prereleases produce noise rather than information.

The version bumping is scripted as well. The bump-dev target reads the current version out of pubspec.yaml, prompts for a new one, validates that it is in x.x.x format, and refuses a version that is not above the current one. It then derives a numeric build code from the major, minor and patch numbers and writes the result back into pubspec.yaml with sed. An empty answer bumps the build code only, which is the convention for a version that changes nothing user-visible.

The tree also carries a Pipfile, an analysis_options.yaml and a devtools_options.yaml for the Dart analyser, a l10n.yaml for localisation, a firebase.json, a release.config.json for the release tooling, an android/ and ios/ directory, and a scripts/ directory.

Where the project publishes and how it is licensed

The distribution picture is simple and worth stating plainly. The Android build is downloadable from Google Play under the package com.evanlu.possystem, and the iOS version is listed as coming soon. The homepage is a documentation site served from GitHub Pages at evan361425.github.io/flutter-pos-system, which also hosts the images used in the readme.

The licence is Apache-2.0, and the readme points to the LICENSE file rather than restating the terms. That is the more permissive of the two common permissive licences, which is a sensible choice for an application a small business might want to fork, rebrand and self-host, which is the most likely reason to adopt an open source POS at all.

For a project that handles point of sale data, the licence is only the first question. The second is what happens to the data a restaurant collects, and the design principles answer that directly: no personal data is stored remotely, only on the device. There is no server to breach because there is no server. A business that has to answer a data protection questionnaire about its customer demographics will find that answer short, provided the device itself is protected, which is a responsibility that moves to the operator along with the data.

The quality signals in the readme are the badges rather than the claims. There is a codecov badge pointing at the master branch, a Codacy grade badge, and the Apache 2.0 licence badge. The codecov link implies coverage is measured in continuous integration, which is consistent with the Makefile's coverage target.

Where flutter-pos-system is the wrong choice

The first limitation is the one the design principles imply. A local-only data model is excellent for one till in one restaurant and does not work for a chain. There is no server component in the repository layout, no API package and no account model, so two stores cannot share a stock list, a manager cannot see the day's takings across sites, and a till that fails takes its history with it. If your business has more than one venue or more than one operator on the same till, that is the wrong shape.

The second is that a customer record on a tablet is a liability you own. The privacy principle is real, and it is also a single point of failure. There is no backup, no sync and no server-side copy, so a lost or stolen device means lost customer data and lost sales history, and the transit export feature only helps if somebody actually exports it. A restaurant that treats its till as the only copy of its books needs a process around it that the app cannot provide.

The third is the scope of the features themselves. There is no multi-user support, no role-based access, no purchase orders or supplier management, no shift scheduling, no tax configuration, and no integrations with an accounting package. A product that does inventory and a cash register is a starting point for a small operation, not a replacement for a restaurant management system.

The fourth is the platform position. Android is available now, iOS is listed as coming soon, and an iOS-only business cannot use it. The Flutter codebase would make an iOS build straightforward for a team with the skills, but the project has not shipped it.

The fifth is the release pace. The recent versions are 2.12.0 from 2026-08-07, 2.11.3 from 2026-05-10 and 2.11.2 from 2025-09-14, which is a steady patch cadence with the last push on 2026-10-18. A point of sale is a system a business depends on every day, so a version with a migration path for the data is what matters, and the project documentation does not describe how a database upgrade is handled between versions. A business running this on a tablet needs to know what happens to its data when the app updates.

Editorial conclusion

flutter-pos-system fits a single-venue operator who wants a till that works with no internet connection and keeps customer data on the device, since the offline-first and privacy principles are stated as design commitments rather than features and the Android build is downloadable today. It is the wrong choice for a business with more than one till, since the local-only data model has no server to synchronise it, and it is the wrong choice if you need an iOS build today, which the project lists as coming soon. Before adopting it, install the Android app from Google Play and enter a week of real orders into it, and read the development documentation if you plan to fork it, since the last push was on 2026-10-18 with version 2.12.0 released on 2026-08-07.

Frequently asked questions

Official sources

1. evan361425/flutter-pos-system on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases