POSSIQUEThe website and operating platform for a network of trading units
POSSIQUE helps people run a trading business of their own, selling authorised products with Gazian Water as the founding one, with headquarters and a network behind them. We designed and built its public site at possique.com and the platform that runs the network: one installable web app with a view for each role.
- Client
- Private client
- Sector
- Retail operations
- Year
- 2026
- Platforms
- Public website, Web platform, Installable web app
- Services
- Product and UX design, Web development
POSSIQUE is the enterprise and trading network of IT'S POSSIBLE NOW CIC. It provides the trading unit, authorised products, training, help with licences and insurance, and the app that records every sale, and the platform behind it recruits and checks operators, supplies their stock and gives headquarters one place to run the network. Greater Manchester is the first region.
Built for
- Headquarters staff, who approve people, sites and stock and set the commercial rules.
- Operators, who run their own unit and sell from a phone, often with a weak signal.
- Host partners, who provide trading sites and follow how each one is doing.
- Applicants, who check whether they qualify on the public site, then complete their checks and training on a phone.
The problem
A trading network runs on many small facts that all have to agree: who is allowed to trade, where, with which stock, at what price, and who is owed what at the end of the month. Those facts pass between people who are rarely in the same room.
The commercial terms belong to the client and change over time. Prices, margins, deposits and the host partner share had to be values headquarters sets from a screen, with a record of every change, because a new price should never need a developer.
Operators sell outdoors, often one-handed, where the signal comes and goes. A sale lost because the phone was offline is money nobody can account for.
Money and stock need a record that holds up later. Every change has to name the person who made it, and nothing financial can be quietly edited afterwards.
People deciding whether to apply have questions long before they have an account, and every answer they get has to be one the client has approved.
Goals
- 01Give each role its own view inside one installable app.
- 02Let operators record a sale in a few taps, with or without signal.
- 03Keep every commercial number in a registry headquarters controls, never in code.
- 04Track stock by owner, batch and place, so a recall reaches the right units.
- 05Record every change with its author, in a trail that cannot be edited.
- 06Answer visitors' questions on the public site from approved answers only.
- 07Answer the pilot's six questions from recorded data.
Our role
We wrote the blueprint with the client, designed the platform and its public site, and built and launched both.
What we delivered
- Discovery and a written blueprint, reviewed and approved by the client
- Platform screens designed in Figma across five surfaces
- The POSSIQUE wordmark and colours applied across the public site and the app
- One TypeScript application: Next.js front end and server domain
- PostgreSQL schema, migrations and an append-only audit trail
- Offline sale recording on the operator's phone
- Rules registry for every commercial value
- Stock ledger, wholesale orders and a payment step behind one interface
- Reports and exports for the pilot's six questions
- The public site at possique.com, with Ask a question and the See how POSSIQUE works tour
- Sign-in with an emailed code, a password or Google
- Staging and production servers, scheduled jobs and daily backups with a tested restore
How we worked
- 01
Write the blueprint first
The client's brief and several rounds of questions became a written blueprint, which he marked up and approved before the build started. The code repository and the platform's accounts belong to his company from the first day.
- 02
Design every screen before building it
The platform's screens, from the applicant's first steps to the headquarters desk, were designed in Figma first.
- 03
Build in weeks, on a staging server
The build followed an eight-week schedule. Each week shipped to a staging server with a written report and something the client could try himself.
- 04
Check against the schedule itself
After week six, every requirement in the schedule was checked again against the running product, and everything that check found was built.
- 05
Launch under the network's name
When the network took the name POSSIQUE, the public site, the app and the sign-in pages took its new wordmark, and possique.com went live with the earlier address redirecting to it.
Screens and features
Headquarters runs the network from one screen
Each person's steps from application to trading are tracked, every decision waits in one queue, oldest first, and commercial values are set from a screen.
Every change named, nothing edited later
The audit timeline keeps every action with the person who took it. Stock is a record of movements, by owner, batch and place.
Operators and host partners work from their phones
Each step before going live opens in order. With no signal, sales are saved on the phone and sent when it reconnects.
A public site that answers questions
possique.com explains what the network provides. Ask a question answers from 100 approved answers and offers the next step.
A tour of every role, and sign-in with Google
See how POSSIQUE works shows each role's real screens. People sign in with Google, an emailed code or a password.
Sales that survive no signal
A sale is saved on the phone with a key made at the tap. The phone keeps it until headquarters sends that key back, and each person on a shared phone has a list of their own.
Commercial numbers in a registry
Prices, VAT, margins, deposits and allocations are parameters. Headquarters previews a change before saving it, a price can be set for one product or for all of them, and every change appears on the audit timeline.
One approvals queue, oldest first
Identity checks, operator approvals, site compliance, stock approvals and exceptions share one queue, ordered by how long each item has waited.
Six steps from applicant to operator
Application, identity check, training, approval, a matched site and a signed agreement. The people register shows where each person is, and the operator's own steps before going live open one after another.
Stock by owner and batch
Stock owned by the network, on consignment, owned by operators or held at supply points is kept apart, sales draw from the oldest batch first, and a recalled batch appears on the operator's phone.
Orders keep their prices
A wholesale order stores its prices and VAT as they stood when it was placed, and every step of the order is recorded with the person who took it.
Corrections are new records
A recorded sale is never edited. A correction is a new record that points at the original, and a sale can be corrected once.
Approved answers before anyone signs in
Ask a question on the public pages answers from 100 approved answers, names the answer it used and offers the next step, such as starting an application. On phones that support it, the question can be spoken.
Support when someone asks for it
A person can tell the network, by choice, that a disability or health condition affects their work, and headquarters sees it on their record to arrange support. The public site sets out the extra support available through Difability.
Technical choices
What the product is built with, and why.
- One Next.js 16 application
- The public site and the applicant, operator, host partner and headquarters views are route groups in one deployable over one PostgreSQL database. The operator view installs on a phone and opens without the browser's address bar.
- An audit trail the database enforces
- The audit table is split by month and refuses updates and deletes. Every other table refuses a write that does not name its author, and in the code a write outside an audited transaction does not compile.
- Rules read through one module
- Every commercial value is read through the rules module and cached in Redis. The write that changes a value also clears its cache, so a new price is never hidden behind an old one.
- A stock ledger with no balance table
- Stock at a place is the sum of the movements into and out of it, per batch. A separate balance table would be a second record of the same fact, and the two would drift apart.
- Import boundaries enforced by lint
- A small kernel owns audit, rules, access, ledger and stock, and each feature sits in its own slice. ESLint stops one reaching into another, and a script writes deliberate violations to prove every rule still fires.
- Permissions held as data
- Roles and their scopes live in one table that both the code and a negative test read, so the test covers every role against every resource. Our own developer account is refused prices, payments, agreements and operator records.
Platform screens were captured from a local copy of the project's demonstration data, with the headquarters accounts named by their role: every name and figure on them is invented, and none is a commercial term. Public pages were captured from possique.com.
Running a network of people, stock and money?
Operations platforms with changing rules and records that have to hold are work we know well. Tell us how your network runs.