Public development dashboard

Project Status

A transparent snapshot of where Axiom stands today.

This page documents current progress, active development work, testing activity, validation evidence, and upcoming milestones for AxiomScale.

Current stage

Validation phase.

AxiomScale is a working prototype system being tested in real households while hardware, app workflows, and setup friction are still being refined.

Current stage

Real-world validation with active prototype and companion-app testing.

Key focus areas

Reliability, setup friction, NFC workflows, Bluetooth sync, and whether the product remains useful during ordinary cooking.

Project snapshot

Progress should be measurable, not just described.

These indicators are intentionally practical. They show whether the project is accumulating real build and test evidence.

2 working prototypes assembled and out in households
V2 Slimmer second-generation prototype currently being assembled
3 independent users currently testing
103 days since first parts arrived on 5 January 2026
V1 tester baseline assembled for household validation
Now real-world validation, feedback capture, and V2 assembly

Hardware status

Functional prototypes are in use, but the hardware is still evolving.

The priority is not polish for its own sake. The goal is a reliable kitchen object that can survive repeated use and communicate clearly.

Prototype version

V1 tester baseline is assembled and being used for household validation. V2 is being assembled as a slimmer second-generation unit.

Known issues

Setup friction, surface fit, repeated-use reliability, enclosure refinement, and manufacturing practicality remain active questions.

Current hardware focus

Improve durability, reduce physical bulk, tighten the NFC interaction area, and keep the device understandable during cooking.

Software status

The Android app is functional enough for testing.

The app is treated as review and recovery infrastructure rather than something that must interrupt the cooking moment.

Android application

Tester-baseline app is working with local persistence, food search, NFC writing, and Bluetooth sync.

Logging workflow

The system is being tested around natural weighing, repeated foods, token assignment, and later review rather than live phone interaction.

Current software focus

Improve sync reliability, reduce setup confusion, refine correction flows, and capture logs in a way testers can understand later.

Testing programme

Testing is focused on product truth, not testimonials.

The useful feedback is the feedback that changes the product: what confused people, what survived repeat use, and what failed in ordinary kitchens.

Tester count

3 independent users currently testing or preparing to test the system in real household conditions.

Current testing focus

Reliability, setup friction, repeated use, NFC token behaviour, and whether the workflow feels worth keeping.

Open questions

How much guidance is needed, which token patterns survive real kitchens, and which mistakes are easy to recover from later.

Recent learnings

The project has changed because testing changed it.

These are validated product lessons rather than a list of completed features.

Passive logging matters

Fixed-location or container-attached tags can make repeated behaviours feel natural rather than like another task.

More tokens can create more friction

Adding identifiers solves one problem but can create another if tokens need too much management, storage, or remembering.

Setup friction is product friction

Pairing, NFC writing, first log setup, and sync instructions are part of the product experience, not admin around it.

Next milestones

What happens next.

The next stage is about broadening validation while tightening the parts of the system that testers actually touch.

01

Expand household testing

Bring more imperfect kitchens and more ordinary cooking routines into the feedback loop.

02

Refine app recovery flows

Make imperfect logs easier to understand, correct, and trust after the cooking moment.

03

Complete V2 hardware assembly

Use the slimmer prototype to test whether the product form is moving in the right direction.

04

Define validation goals

Turn tester observations into clearer evidence for reliability, repeat use, and product value.

Deeper information

Follow the evidence trail.

The dashboard is a snapshot. These pages hold the build history, visual evolution, and tester pathways behind it.