Back to home Custom work

When the modules don’t fit, we build the part that does

The Time & HR modules cover the ground most workshops share. Where your operation works differently, the answer is not to change how you run — it is to build the missing piece and connect it to what you already have.

Four kinds of custom work

Most jobs are one of these, or two of them together. If yours is none of them, it is still worth asking.

Custom integrations

Connect Nexflow to what you already run — payroll, accounting, suppliers, or the equipment on the floor. A proper API where the other system has one, a scheduled file exchange where it doesn’t, and webhooks where something needs to react the moment it happens.

  • Payroll and accounting
  • Supplier and customer systems
  • Machines, scanners and scales

Legacy system bridge

The system you can’t switch off yet keeps running while work moves across. We read from it, mirror it, or sync both ways, so you can move one process at a time and stop when it stops being worth it — instead of betting the business on a single cutover weekend.

  • Read-only mirror to start
  • Two-way sync where it earns it
  • Move one process at a time

Custom modules

A new module inside Nexflow, sitting beside the rest. Same login, same database, same permissions and the same audit trail — so it is not another silo with its own password and its own spreadsheet export.

  • One login, one database
  • Shares the part and staff records
  • Appears in the module switcher

Custom applications

Sometimes the job doesn’t belong inside an ERP at all. A standalone application, built for one process, that talks to Nexflow where it needs to and stays out of the way where it doesn’t.

  • Web, tablet or kiosk
  • Works offline where the job needs it
  • Yours — not a seat you rent forever

How a custom application gets built

The same eight steps every time, whether it is a small tool for one team or an application the whole floor depends on. You can stop at the end of any stage.

Walk the floor

Before anything is written down, we come and watch the work happen. What the process is supposed to be and what people actually do are rarely the same thing, and the gap between them is usually where the software has to go. The whiteboard, the clipboard and the spreadsheet somebody maintains at home are the requirements.

You get: a written description of the current process, including the parts nobody had written down before.

Scope, in writing

We agree what the application does, and just as importantly what it deliberately does not do, before any code exists. Anything out of scope gets listed as out of scope rather than quietly assumed. You get a price against that scope, so a change of mind later is a conversation about cost, not a surprise.

You get: a scope document and a quote you can hold us to.

Data model and integrations

We decide what the application owns and what it merely reads. Owning the wrong data is how you end up with two systems disagreeing about the same part. This is also where we find out what the other systems will actually let us do — which is often less than their brochure suggests.

You get: the data model, and an honest list of what each integration can and cannot do.

Clickable prototype

Screens before code. You click through the real flow with real labels and tell us where it is wrong, while changing it still costs an afternoon rather than a fortnight. Most of the arguments worth having happen here.

You get: a prototype you can put in front of the people who will use it.

Build in stages

The work is broken into stages that each end in something that runs. You see it at the end of every stage, not at the end of the project. If priorities change halfway through, the remaining stages change with them.

You get: working software at each stage, and the ability to stop.

Pilot on real work

One team, one line, or one shift runs it on real data, usually alongside the old way for a short period. This is the only honest test: a process that works in a demo and fails at 6am on a Monday has not been tested.

You get: the fixes that only real use finds, before everyone depends on it.

Cutover and training

The old way stops. We train the people who use it daily and the people who will be asked when something looks wrong, and we are around for the first days rather than at the end of a ticket queue.

You get: the handover, and documentation aimed at your staff rather than at developers.

Support and change

Businesses change and software has to follow. After handover it is supported, and changes are quoted the same way the original scope was. You are not locked into paying for changes you did not ask for.

You get: support, and a clear route for the next change.

Start with the walk

The first step costs you an hour or two and a walk around your own floor. You will get a written description of the process either way — whether or not you build anything with us.