LifeXPoints

Field operations, run from the chat app your team already opens.

LifeXPoints builds software for field-service companies. Technicians get their orders, materials, and payments inside LINE. The back office gets one verified record of every visit, kept in sync with the ERP it already runs.

DispatchNorth branch · technicians
Good morning. You have 4 visits today. The first is below.
Work orderPENDING
No.WO-2610-0187
ServiceFilter replacement
Window14:00–16:00
Parts2 items reserved
Open orderNavigate
On my way.
Customer signed. Completion certificate filed and synced to the ERP.

Every order follows one status machine, start to finish.

Each change records who made it, when, and why. An order can't end up in a state the spec doesn't allow, so the field, the back office, and the ERP never disagree about where a job stands. Select a stage to see what happens there.

One suite, built around the visit.

Each module covers one job a field-service company already does, and all of them share the same identity, permissions, and audit trail. Start with dispatch and add the rest as you need them.

LX Dispatch · flagship

Work orders, from ERP to signed completion

Orders come in from the ERP or are created on a phone. Supervisors assign them in batches, and technicians run the whole visit from a chat card: navigate, photograph, collect payment, capture the customer's signature. The order goes back to the ERP only once it's finished and verified.

  • Traffic-light dashboardAn hourly check flags orders at risk. Warnings arrive as a daily digest; critical alerts go out right away.
  • Paperless completion certificateSignature, photos, and on-site payment are merged into one certificate that mirrors the legacy paper slip.
  • Calendar and map viewsSee a day's route on the map, a branch's month on the calendar, and reassign with one tap.
  • Desktop sign-in by QR codeScan once with your phone to approve a desk session. Each device is registered and can be revoked.

LX Stock

materials

Requisitions, returns, and installs done on a customer's behalf, each backed by photos. Warehouse staff check items face to face before stock moves, and every rejection and resubmission stays on record.

LX Pay

payments

Card payments collected on a phone through a payment gateway, with callbacks, refunds, and dashboards per department and per user. Every write is protected against cross-site request forgery.

LX Recurring

subscriptions

Service contracts, a billing calendar, and a daily scheduled job that charges each card on its due date, with history and accounting views.

LX Console

admin

Roles and permissions, rich-menu management, a registry of which staff are in which LINE group, and an account health page. Each change is written to the audit log in the same transaction as the change itself.

LX Payslip

HR

Pay slips delivered as chat messages through encrypted, versioned links that expire. No email attachments and no shared drives.

LX Pulse

reports

Daily department logs, receivables by branch, and how complaints were resolved. It also shows how much of each branch's work went through the system.

LX Sign-off

training

Staff confirm announcements and training with a signature. Managers see who has read each one.

LX Group Bot

webhook

Watches dispatch messages in team group chats and replies with structured cards, so teams that chat informally still produce clean data.

Plain code, strict rules.

No framework and very few dependencies. Most of the rigor is in the boundaries: what the browser is allowed to do, what reaches the ERP, and what has to happen before code reaches production.

The browser is never trusted

Every request re-checks identity, department, and role on the server. Internal services sit behind a proxy that only allows listed routes, and the client never calls them directly.

Photos skip the server

The server issues a signed upload link that lasts 15 minutes and works only for listed folders. The phone uploads straight to cloud storage, and only the final URL is saved.

One exit per outside service

Each external API, from messaging to e-invoicing, goes through exactly one file. That rule is recorded as an architecture decision.

Audit trail or nothing

Permission changes and their log entries are committed in the same transaction. If the log entry fails, the change is rolled back too.

Production only moves one way

Changes are cherry-picked from dev to production after a preflight check. The check scans for environment-specific values, and every version name includes the commit it was built from.

Tests block merges

CI runs PHP, JavaScript, and Python suites against three PHP versions. Guard tests also catch drift between documents and code, and comments in client-side code that say more than they should.

PHP 8.2 / 8.3Google App EngineCloud RunCloud StorageFirestoreLINE LIFFMessaging APIWeb PushPythonGitHub ActionsCloud Logging

Built by one engineer and a team of AI agents.

The whole suite was designed, built, and run by one full-stack engineer inside a regional service company: technicians in several branches, parts warehouses, payment collected on site, and an ERP that wasn't going anywhere.

AI coding agents do much of the typing. Human judgment goes where it matters: specs written before code, a decision record for every important trade-off, and tests that fail before a fix is accepted. When something breaks, the lesson goes into the docs so it doesn't break the same way twice.

7 months
from first commit to a suite running daily operations
~2,400
commits, each one tied to a ticket
~1,260
issues and pull requests
~215
test files across PHP, JavaScript, and Python
7
architecture decision records

Running field teams on spreadsheets and group chats?

hello@lifexpoints.com