Contact

We build the system your branches use. Your books stay where they are. We build one system across your branches, connected to the ERP you keep. We build the server and the apps, against the ERP you already run.

Each order is typed once, on a phone in a dealer’s shop or in a browser, and nobody types it again at the branch. The software that keeps your books today goes on keeping them.

Each order is entered once, in the field or in a browser, and stock from a branch whose feed has stopped is marked with the date it was last read.

The read side is a snapshot of the ERP, rebuilt every two hours through the working day, with each branch read from the live stock feed or from a fallback copy. Writes go to a Postgres store beside the ERP and travel back to the branches as files and email.

A field and ordering system built by 64ARCS has been in daily use across a parts distributor’s 93 branches since July 2026. Its production Android app went on the Play Store on 14 July 2026. Two products of 64ARCS’s own, PathWay AI and 64Griddle, have been open in a browser as pilots since 15 September 2026.

Choose the level of detail.

Plain words, no jargon.

If you write software, start at Engineering detail.

Each number has one home, and every screen reads it from there.

Each fact has one owner, and every screen and report reads it from that owner.

Every read resolves against a single owner for each fact.

One place owns each number

One owner for each fact

The read side picks a source per branch

Stock, prices, dues and credit limits are each kept in one place. In the distributor’s system, stock for two in three branches comes from the live feed. The rest comes from a copy that runs about a day behind, and a branch whose copy has stopped updating shows its date next to its stock.

Customer, stock, price and credit limit each come from one place. Two in three branches are on the live stock feed. The others fall back to a copy about a day behind, and rows from a branch whose feed has stopped carry their as-of date.

The ERP sits on-premises behind a slow WAN link, so the read side is baked into the container image as read-only SQLite and rebuilt every two hours from 07:00 to 19:00 IST. A branch is read from the live stock master when its newest reading is under three days old, and otherwise from a fallback copy that lags about a day. Of the 93 branches, 62 read live. The supplier screen shows each branch’s as-of date, transfer suggestions state the source branch’s date, and stock rows from a dormant branch carry a dated warning. A fallback branch with no purchase in over 45 days is flagged dormant and is never offered as a source for a transfer.

Your own system stays

Your ERP keeps the books

The ERP stays the system of record

It is written for your business. It reads from the software your books already run on, sends orders back into it, and keeps what that software was never built to hold, such as field visits, attendance and credit decisions.

Nothing has to be migrated. It reads from the ERP and writes back through it, and keeps field activity, attendance and credit decisions, which the ERP has nowhere to put, in a separate store beside it.

In the one built so far, the ERP is 1,087,117 lines of hand-written VB.NET and keeps the books. A write store on Cloud SQL Postgres holds what it cannot: field activity, orders, attendance and credit decisions, with photographs in object storage. The captured order lives there, and the priced sales order lives in the branch ERP, as it always has.

A screen for each person

A view for each role

One front-end, one write path

Reps on the road, dealers ordering at night, suppliers and head-office staff each see the screens their job needs, on a phone or in a browser, in any of thirteen languages. An order taken where there is no signal waits on the phone and goes in when the signal returns. It cannot go in twice.

Reps, dealers, suppliers and head office each see what their role needs of the same orders, stock and dues, on Android and the web, in thirteen languages. Orders taken without signal queue on the phone and post when it returns, and a retried order is booked once.

Reps, dealers, suppliers and head office share one web front-end in thirteen locales, with each role fenced on the server. The Play Store app is a Trusted Web Activity around that front-end, so a feature ships with a web deploy. The phone keeps an outbox of orders taken offline. Each cart carries a client-generated transaction ID that is reused on every retry, so a post that timed out is booked once. The file sent to the branch is named after the order ID, and the ERP refuses a filename it has already saved.

What happens when you press save

The rules run on the server

Credit is re-derived on the server

Before an order is saved, the server checks the dealer’s dues and credit limit again against head office’s own record, whatever the phone showed. If the dealer is over the limit, had a cheque bounce in the last 120 days, or has a bill 90 days or more overdue, the server sends the order back with the reasons, and nothing is saved yet. The rep can confirm and book it anyway, and the reasons stay on the order for good. A dealer ordering from their own login cannot confirm past it. A payment and the photograph of its receipt are saved together, or neither is.

Credit is re-checked on the server against head office’s own dealer record before an order is written, a soft block, not a refusal. Where a rep confirms past it, the reasons stay on the order and show on its card. A dealer’s own login cannot confirm past it. A payment and its proof photograph commit together, or neither is recorded.

The order endpoint re-derives the credit level and answers 409 with needs_ack and the reasons unless the request carries an acknowledgement, so a client running old code cannot skip it. For a customer login the acknowledgement is forced false. Acknowledged reasons are persisted on the order row. A payment and its proof photograph arrive in one multipart request and commit on one connection, and the old proof-less path answers 426. The file sent to the branch carries no rates, and the branch ERP prices the order from its own masters at save.

Where a standard package already fits the way you work, it stays, and 64ARCS builds only the part it cannot do.

What we build, area by area    Where AI fits

Three things we have built.

One is the distributor’s system. The other two are early products of our own, both browser pilots, and each has a panel on the Products page that says where it stops.

Business system In daily use since July 2026

A distributor’s field and ordering system

Reps, dealers, suppliers and head office work from one set of numbers across 93 branches. Orders are still priced and billed in the ERP the branches already had.

How it was built
Product Pilot

PathWay AI

A student works on an assignment inside the terms their teacher set, and the session is kept as a record both of them see. It shows how the work happened and does not judge who wrote it. Replies are prepared examples, and no generative model is connected.

What it does, and where it stops
Product Pilot

64Griddle

It reads an AI prompt before you send it, marks where an assistant would have to guess, and offers wording that you accept or reject. Version 0.5.3 runs on local rules in the browser and makes no network requests.

What it does, and where it stops

The work starts in your branches, with how orders, stock and money move today.

01 · Understand

We sit in your branches and watch how the work is done today.

02 · Decide

Together with you, we settle where each number lives and who may change it.

03 · Build

It is written in small pieces, and you see each one working before the next begins.

04 · Join up

Orders reach your system with no rates on them. It prices them, and nobody retypes anything.

05 · Stay on

We stay on afterwards. A piece is replaced only after you have watched the new one run beside it.

01 · Understand

We sit in your branches and write down the exceptions and workarounds that never reach the org chart.

02 · Architect

We agree which system owns each fact, what gets connected and what gets built.

03 · Build

Each slice goes in front of a branch as soon as it works.

04 · Connect

Orders write back through your ERP and are priced there, so nobody retypes them.

05 · Evolve

We stay on, and any replacement runs beside the original before it takes over.

01 · Understand

Sit in the branches, trace every place a fact is contradicted, and find out which copy people trust.

02 · Architect

Agree the owner of each fact, where each rule is enforced, and the one write path.

03 · Build

The server comes first, with its rules, transactions and migrations, and the apps follow in slices that ship.

04 · Connect

Read from snapshots of the ERP, and write back through one deduplicated path that the ERP prices at save.

05 · Evolve

Replace a module only after it has run beside the original, read-only, on real data.

See the full method

It suits established mid-sized businesses that have outgrown spreadsheets and want neither a five-year programme nor a technology department.

Sometimes you don’t need us. Some problems are a process fix, not a platform. If a spreadsheet is already doing the job, it stays, and you will hear that early.

GST, TDS, dealer schemes and WhatsApp, for businesses in India

If your branches each hold a different figure for the same stock or the same dues, write to hello@64arcs.com or use the form. A person reads it and replies within two working days. The first call is sixty minutes on how your operation runs, no deck.