Skip to content
LANGOLF DIGITAL
All work04 / 15
BUSINESS2026

LocalPOS Pro

A multi-surface point-of-sale and business operations platform

A multi-surface point-of-sale and business operations platform exploring POS, kitchen display (KDS), self-order kiosk, ordering, and administrative workflows for a single store.

Status
In Development
Category
BUSINESS
Year
2026
Primary stack
Next.jsTypeScriptSupabase
Demo
ENTER THE BUILD
LocalPOS Pro point-of-sale interface visualization

Project visualization — a designed representation, not a literal screenshot

01Overview

What this is

A multi-surface point-of-sale and business operations platform exploring POS, kitchen display (KDS), self-order kiosk, ordering, and administrative workflows for a single store.

Explores

  • Point of sale
  • Kitchen display system (KDS)
  • Self-order kiosk
  • Ordering
  • Administration
  • Store management
  • Business configuration
  • Supabase backend
  • Backend services
  • Automated testing

02Explore the build

The demo and the build insight

The demo

External application

ENTER THE BUILD

The public LocalPOS Pro build — POS, kitchen display, kiosk, and operations surfaces, live on Vercel.

ENTER THE BUILD

Build insight

01 / 04
Current build
In Development
Architecture and features below are the real build.
Demo
External
Launch control above opens the verified public build.

Build insight — real project data, not a live application.

One store-scoped data model is the single source of truth. Each surface is a tailored view over it, which keeps order state consistent when a kiosk order and a POS order interleave on the same kitchen screen.

03Problem · opportunity

What it sets out to solve

Running a local restaurant or retail business means juggling a fragile POS, a separate kitchen screen, an unconnected ordering channel, and admin work spread across still more tools. Small operators need one coherent system, not a stack of integrations.

04Concept

The core idea

A single business operations platform where the register, kitchen, kiosk, and back office all read from the same live store state — orders, menu, staff, and settings — instead of each surface maintaining its own copy of reality.

05What I built

What's actually in the code

In-progress development. The store data model, backend services, and first surfaces are being built against Supabase, with automated tests covering business logic as it stabilizes.

Approach

Defining one store-scoped data model (menu, orders, tables, kitchen stations, staff) on Supabase, then building each surface — POS, KDS, kiosk, ordering, admin — as a view over that model. Backend services and automated tests are part of the build rather than an afterthought.

06Key features

What's implemented today

  • Shared store state across POS, kitchen, kiosk, and admin surfaces
  • Menu and business configuration owned by the store, applied everywhere
  • KDS routed from the same order stream as the register
  • Kiosk and ordering flows modeled on the same catalog
  • Backend services built over Supabase for the core order lifecycle
  • Automated tests on business logic as it stabilizes

07Architecture

How it's structured

architecture.md

One store-scoped data model is the single source of truth. Each surface is a tailored view over it, which keeps order state consistent when a kiosk order and a POS order interleave on the same kitchen screen.

Design notes

The design is pragmatic: local business is the scope, multi-store growth is out of scope for now. Offline tolerance and hardware (printers, displays) are anticipated but not yet implemented.

08Technology

The stack

  • Next.js
  • TypeScript
  • Supabase
  • PostgreSQL
  • Node.js
  • Tailwind CSS

09Challenges · lessons

Where it got hard, and what it taught me

Challenges

  • Keeping order state consistent across surfaces updating the same store in parallel
  • Defining which configuration belongs to the store vs. the platform
  • Resisting scope creep into multi-store enterprise territory

Learnings

  • A shared data model removes an entire class of sync bugs before they exist
  • Self-ordering surfaces are only trustworthy if the kitchen view of an order is authoritative
  • Testing business logic early is cheap relative to debugging live order flows

10Current status

Where this project sits today

In Development2026

Architecture is established and modules are actively being built. Parts exist; the whole is not finished.

Demonstrated

  • Store data model and backend services in active development on Supabase
  • Automated tests being written for core business logic

11What comes next

Where this goes from here

  1. 01Complete the order lifecycle end to end across POS and KDS
  2. 02Add the kiosk and ordering surfaces against the shared catalog
  3. 03Expand automated test coverage across backend services