Software your operators will actually use on the floor

We design and build the applications your off-the-shelf systems do not cover: the yard tablet, the scale house screen, the supplier portal, the app that replaces the spreadsheet everyone depends on. We build with the people who use it, and we keep it working when the Wi-Fi does not.

Request a 30-minute call

Sound familiar?

Situations this work is built for. If a few of them describe your operation, you are on the right page.

  • The whole operation runs on one spreadsheet that only one person understands.

  • Our drivers call the office to ask what to load next.

  • The ERP does not do what we do, so we work around it every day.

  • Customers email us for order status because there is nowhere to look it up.

What we build

Operator-facing apps
Screens designed for gloves, glare and speed: receiving, weighing, inspection, work orders and downtime logging. Few taps, big targets, and no training manual.
Tablet apps for the floor and yard
Rugged-tablet apps for yard moves, bale tagging, cycle counts and load verification that keep working in dead zones and sync when the connection returns.
Customer and supplier portals
Self-service portals for order status, tickets, test reports, appointments and documents, so your office stops answering the same email twice.
Spreadsheet replacement
We study how the spreadsheet is really used, including the macros and the tribal rules, and rebuild it as an application with permissions, history and validation.
Mobile and offline-capable apps
Native and web apps with local storage and conflict handling, built for trucks, scale houses, warehouses and sites with poor coverage.

How the work runs

  1. Assessment

    2–3 weeks

    We shadow operators, collect the spreadsheets and forms in use, and map the data behind them. The output is a written findings report, a clickable prototype of the key screens and a prioritized roadmap.

  2. Build

    6–16 weeks

    Fixed-scope or phased delivery, with working software shown every week. The first release covers one workflow end to end, tested by the people who will use it.

  3. Pilot

    2–4 weeks

    One site, shift or team uses the app alongside the old process. We watch real usage, fix friction fast and agree what must be true before the rest of the operation switches.

  4. Run

    Monthly

    Monitoring, bug fixes, small enhancements and new screens on a monthly retainer, with a shared backlog your team can add to.

Tools we commonly use

  • TypeScript
  • React
  • React Native
  • Next.js
  • Node.js
  • PostgreSQL
  • SQLite
  • Cloudflare Workers
  • Progressive web apps
  • Docker

We pick tools to fit what you already run and what your team can maintain.

Where this matters most

Questions buyers ask

Why build custom software instead of buying a package?

Build when your process is a real source of advantage or no package fits it, and buy when a product already does the job. We will tell you which applies during the assessment, and we are comfortable recommending a purchase. A common outcome is a package for the standard parts and custom tools around the edges.

Who owns the code?

You do. The source code, the data and the documentation are yours at delivery, held in repositories your company controls. We favor widely used, open technology so any competent developer or in-house team can take it over.

Will the app work when the connection drops?

Yes, we design for it from the start when the site needs it. Offline-capable apps store work locally, queue changes and sync with conflict handling once the connection returns. We test in the actual yard or plant, not only at a desk.

How do you work with our IT team?

Alongside them. We agree on hosting, identity, security review and support handoff at the start, and we include your IT people in design reviews and weekly demos. If you want them to own the system after launch, we plan the handover from the first week.

Other services

Further reading