Purpul Pulse
Describe the shape of the system you need. Get a working backend, an API, and a front end that talks to it. Ship when ready.
Who is behind this
That is the honest starting fact. The work began in early 2026 and was not demonstrated to anyone for five months, because of a test set at the beginning and not moved since:
“Can it do what it says, and will it genuinely make me more productive or help me? And my answer has to be yes, otherwise I do not build it.”
A multi site trade counter and point of sale, built with a partner against their real requirements. The backend platform underneath it. A browser extension in evaluation.
The public product is in evaluation, not general release. Several claims in this deck are proven on our own machines and not yet at customer scale, and those are named where they appear.
Small team. No outside investment. Every claim carries the measurement that produced it, and anything unproven says so.
The problem
Tables, records, roles, permissions, search, media, reports, audit, exports, webhooks. Teams rebuild that same foundation for every project, then bill for it, then maintain it forever. Only a thin slice is ever specific to the business.
What changes
The foundation is not written again for your project. It is already built and proven. Your requirements decide the shape it takes, and what comes out is a real backend with real endpoints, not a prototype.
Requirements, a spec, existing documents, or an existing system. Whatever you already have.
A working backend, a documented API, an admin surface, and a front end wired to it.
The code, the data, and the ability to run the whole thing yourself.
Where to start
You already know how to do this. Describe what you need as though you were going out to tender: the things you keep track of, who is allowed to see them, what has to happen when, and what you would call a failure. Write it for you, not for a supplier.
That document is the input. There is no separate discovery phase to buy first, and no technical translation step where the meaning quietly changes.
“We run six trade counters. Staff take orders at a till and account customers have their own pricing. A discount over ten percent needs a supervisor. At close of day each till is counted and any difference is recorded.”
The things you named, the rules you set, the people who may act, and the reports you asked for. Running, with your branding, ready to be argued with and changed.
Running cost, measured
| Billed | Our platform | Conventional stack | Ratio |
|---|---|---|---|
| Month to date | $0.12 | $5.00 | 42x |
| Projected month | $1.39 | $60.42 | 43x |
| Memory | 400 MB | 15 GB | 37x |
Figures read from the hosting provider's own billing for two live projects on the same plan.
Two ways to run it
Deployed inside your estate, behind your own boundary. Your data stays where your policy says it stays. Custom front end where you need one, standard surfaces where you do not.
A browser extension. It makes sites easier to read and use, saves what you are browsing so you can work without a connection, and answers questions about the page you are on.
Resilience
Connectivity is treated as something that comes and goes, because it does. Work continues locally and is reconciled once the connection returns. Staff and customers are not asked to wait.
It watches itself
One system watches everything you run: the cloud services, the servers, the machines on site. It stays silent while nothing has changed, and tells you the moment something starts to drift. Silence is a measurement, not an absence.
Integration
Most projects stall on the joins: the old database, the supplier feed, the payment provider, the warehouse. That work is normally the majority of the timeline and most of the risk.
Brought across without a rewrite of the systems that hold it.
Ordering, delivery, payments and logistics providers.
Works with the sign in and permissions model you already use.
Files and media, wherever you keep them today.
The aim is a shorter integration phase, not a promise that integration disappears. Scope is agreed per system.
Proof
We are collaborating with multiple partners on large scale enterprise products in completely different industries. Rather than ask you to take that on trust: three claims, each one a single command on your own machine, with no network, and each with a deliberate failure watched before the pass was believed.
Why it holds up
The same request gives the same answer. Behaviour can be tested, reviewed and signed off.
A fraction of the memory and cost of a conventional stack, which is why it can run on modest hardware and in the browser.
When something is genuinely unknown it says so, by name. It does not invent an answer to look capable.
That last point is a design rule, not a limitation. A confident wrong answer costs more than a gap, because a gap announces itself.
In short
A backend, an API and a front end from what you can already describe. Running for pennies, working offline, and connecting to what you already have.
A working trade counter, the workspace behind it, and the billing that produced the numbers on this page.
Bring one system you would rather not rebuild. We will show you what comes back.