CodeNine

Services

Four engagements, and what actually happens inside each one.

Each is named after the situation you are in, not the technology we would use. Every one is quoted on scope. No hourly rate.

01 · Takeover and rescue

Somebody else wrote it, and now it is yours.

30days
Takeover to production · fastest so far

The most common way we start. It begins with reading, never a rewrite proposal. A rewrite quoted before anyone has read the code is a guess with a price on it.

Where the existing build is sound, we keep it. Where it is not, we replace it in one deliberate pass, not four opportunistic ones.

See it done: the Azima build
How it goes
Starts with
An Inherited Codebase Review. Read-only access, 2–3 days, a written verdict.
Then
A scoped plan against the risk register, ordered by consequence, not ease.
You get
A system your team can change, and documentation of what it does now.
Not for you if
You want a fixed rewrite price before anyone has opened the repository.

02 · Operational systems

Your operation does not look like the software you can buy.

Inventory where the unit of production is not the unit of sale. Costs that sit in six places and have to roll up. A branch count that keeps changing.

Nodes are surfaces · solid edges carry goods · dashed edges carry the reconciliation

Kitchen to branch, the shape of an operational systemA master kitchen produces 200 singara and transfers them as goods to a branch. The branch assembles each one into a combo, a different SKU, and sells 200 combos through the point of sale. A reconciliation spans the whole line, from what was produced to what was sold, because the unit of production is not the unit of sale and variance would otherwise be indistinguishable from theft.01 · ProducesMaster kitchen02 · AssemblesBranch ×2703 · SellsPoint of saleGoods200 singaraDifferent SKU200 comboProduced · 200Sold · 200Inventory reconciliationStock has to balance across the transformation, or variance is indistinguishable from theft.Every SKU mapped to its recipe · variance visible per branch · 27 branches
Starts with

Sitting with the people who do the work, not with a requirements document.

Built in

Slices that go live and get used, so the model is corrected by reality early.

Always includes

Controls for dishonest input. Approvals, variance reporting, reconciliation at both ends of a transfer.

Surfaces

Desktop terminal, mobile, and web back office where the operation needs all three.

Not for you if

An off-the-shelf ERP already fits your operation. Check that first; it is cheaper.

See it done: the Cha & Chill build

03 · The whole commercial stack

Till, storefront, stock and books, reconciling to each other.

Most businesses assemble this from four vendors, then spend their life reconciling between them. Built as one system, reconciliation is a consequence, not a job.

Two sales channels resolving to one stock position, accounts, and partner-wise allocationPoint of sale in the shop and the online storefront are two input surfaces. Both resolve to a single stock position rather than to separate inventories, and the two channels reconcile against each other rather than being totalled by hand. The stock position feeds accounts, where expenses, purchasing and cost against sale price are held. Accounts resolve into partner-wise allocation, which splits profit across the ownership structure and produces each partner’s share, resolved per line item.Channel 01POS, in shopChannel 02Storefront, onlineReconcileSalesSingle sourceOne stock positionExpenses · purchasingAccountsCost & marginProfitOne clickPartner-wise allocationShare AShare BShare C
Vapex back office, profit detail by partner, 4:3
The unglamorous end, where the value sits: purchase cost against sale price, marketing spend against what it moved.
Selling

POS in shop, storefront online, one stock position behind both.

Fulfilling

Order management with courier integration, so the customer and the shop see the same state.

Accounting

Expenses, purchasing, profit detail, partner-wise allocation across complicated ownership.

Marketing

CRM driving SMS and email off real purchase history.

Not for you if

Shopify plus an accountant covers it. Many businesses are genuinely in that category.

See it done: the Vapex build

04 · Regulated compliance

The counterparty is a government system.

Italy’s SDI e-invoicing is the one we have shipped. The shape generalises: a statutory format, an exchange that accepts or rejects, and no such thing as a partly valid document.

This is the same discipline as the fintech work. Money moves, an obligation is tracked, and being approximately right is being wrong.

The submission sequence, and the rejection return pathFive steps in one direction. One, prepare: the document is issued in your own system. Two, statutory format: it is serialised into the prescribed format and validated locally before it is sent. Three, government exchange: it is submitted to the exchange, which is not our system. Four, accepted or rejected: the exchange answers, and there is no partly valid document. Five, reconcile: document, response and reconciliation are retained and retrievable years later. A rejected document returns to step one, where it is corrected and resubmitted without gapping or repeating a number. Handling that return path is most of the work.01PrepareIssued in your ownsystem02Statutory formatSerialised, validatedbefore it is sent03Government exchangeNot our system, thedashed rule says so04Accepted or rejectedNo such thing as apartly valid document05ReconcileDocument, response,retentionAcceptedRejectedThe return path is the workA rejected document comes back to be corrected and resubmitted. Acceptance, rejection and non-delivery eachget a resolution path rather than a log line, and the numbering survives every retry.
Format

A prescribed document, validated before submission rather than after rejection.

Outcomes

Acceptance, rejection and non-delivery each get a resolution path, not a log line.

Integrity

Numbering that cannot gap or repeat under retries and concurrent issuance.

Retention

Document, response and reconciliation, retrievable years later.

Not for you if  You need a legal opinion. We build to the specification; your accountant reads the law.

See it done: SDI e-invoicing

Then we keep it running

Custody is the part most agencies do not sell.

Every engagement above can continue as a retainer. Four clients at a time is the capacity limit, and the reason custody works.

Retainer and project pricing are quoted on scope, on the call. Nothing published, and no hourly rate anywhere.

What custody actually includes

Uptime

Monitoring we watch, and a named engineer who answers when it fires.

Dependencies

Patched on a schedule, not when something breaks.

Changes

A running queue of small work. The business keeps moving, so the system does too.

Platform risk

We track the APIs and policies your model depends on, and warn you early. Azima closed because a platform withdrew a capability. We watch for that now.

Access

Direct to the engineers on your system. No account manager relay.

Technology

You work in whatever the system already runs on.

Django and PostgreSQL run in production across all four systems we’ve shipped. The rest is inherited: the stack you get is the stack the system already has.

We also build real-time voice agent and telephony platforms.

Surface
What we use
Backend
DjangoPostgreSQL
Client
ReactNext.jsTanStackReact Router
Mobile
ExpoReact Nativenative Android where the model needs it
Desktop
Electron, branch POS terminals
Smaller services
NodeExpress
Inherited
NestJS, mostly systems we've taken over
Cloud
AWSAzureGoogle CloudDigitalOcean

Questions

The ones that come up before the first call.

Most of these start the same way.

2–3 days · read-only repo access

Get a codebase review.