Skip to content

Custom Business Software

Internal tools: replace the spreadsheet with something shaped like the job

Somewhere in your business, a shared spreadsheet runs a whole job. It works because one person knows its habits: which colour means “chase this”, what “sent?” means in the status column, which tab not to touch. An internal tool turns each of those habits into something the software does, for that one job, so it works when that person is away. We build it for one job, from the spreadsheet you already use.
Talk through your spreadsheetSee every habit become a feature ↓
Warranty claims · 912 rowsJobSerialMfrStatusCreditJ-471WH-88231Asubmitted$180J-488—Asent?—J-488—ASUBMITTED 9/3—J-495FN-20417Bwaiting—J-503WH-90112Apaid$96colours:= ?12341status typed by hand→ 4 fixed states2serial left blank→ serial required3same job twice→ one claim per unit4colours only one person reads→ named filtersClaimsNeeds serial · 3Ready · 5Submitted · 14Credit due · 64WC-118 · J-488 · water heater · Manufacturer Athe only claim for this unit3SerialWH-88540required2Statusdraftsubmittedapprovedpaid1Historyoffice manager · submitted Sep 3Credit$214 · matched to statement✓

The spreadsheet that runs a job

Warranty claims start simply: a row per claim, a few columns. Two years later the sheet has 912 rows, three ways of writing “submitted”, rows nobody dares delete and a colour code that lives in one person's head. Credits get missed because nobody can see which claims are owed money.

An internal tool takes that one job and gives it a proper home: each claim is a record with fields that must be filled, a status from a fixed list, a history of who changed what, and a view for each question the office actually asks.

Today, and with an internal tool

Today

  1. 01A job closes; someone adds a row if they remember.
  2. 02The serial number is copied from a photo, or left for later.
  3. 03Status is typed by hand and coloured by mood.
  4. 04Credits are checked against statements by eye, monthly.

Claims stall without anyone noticing, and owed credits are never chased.

With an internal tool

  1. 01A job with a warranty part opens a claim automatically.
  2. 02The claim can't be submitted without a serial and install date.
  3. 03Status moves through four fixed states, each change recorded.
  4. 04Credits are matched to statements, and the unmatched ones are listed.

One place for the job, and nothing depends on one person's memory.

Every habit becomes a feature

Each habit in the sheet was a workaround for something missing. The tool supplies the missing thing.
Status typed by handFour fixed states: draft, submitted, approved, paid
Colour codingNamed filters anyone can use
A “notes” columnA history of who changed what, and when
The same claim entered twiceOne claim per unit, checked when it's created
A tab marked “do not edit”Permissions: only the office manager approves credits
Checking statements by eyeCredits matched to statements; the leftovers listed

One claim, start to finish

WC-118 · J-488 · water heater

  1. Job J-488 closed with a warranty part

    claim opened from the job record

    done

  2. Serial and install date filled from the job

    install date Aug 21

    done

  3. Nameplate photo needed

    requested from T3, who did the install

    waiting on a person

  4. Photo attached; claim submitted

    office manager · Sep 3

    done

  5. Manufacturer approved the claim

    done

  6. Credit received and matched

    $214 · on the October statement

    done

Closed. The credit is matched to the statement, and the history shows every step and who took it.

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Record

    Backend Architecture

    One claim per unit, with required fields.

  2. Screen

    Internal Tools

    • the claim
    • its history
    • what's owed

    missing serial → claim can't be submitted

  3. Connect

    API Services

    Claims open from closed jobs in the field-service tool.

  4. Control

    Identity & Access Management

    Only the office manager approves credits.

Underneath every stepApplication FrontendsFast screens that work on the office computer and a phone.

What changes from one business to the next

The jobWhich one job the tool takes over, and where it stops
FieldsWhat must be filled before a record can move
StatesThe fixed list, and who can change each
ConnectionsWhich systems it reads from and writes to

A common starting point is a Postgres database, a Next.js application, sign-in through your existing accounts, and an API connection to the system that holds your jobs. These are starting candidates, not requirements.

Is an internal tool the right system?

Good fit

  • One job runs on a spreadsheet that several people edit.
  • Mistakes in it cost money or customers.
  • The job's rules are clear enough to write down.

Avoid when

  • The job crosses several teams with handoffs. Look at a workflow application.
  • An off-the-shelf product already does this job well.

How we'd approach it

Most of the early work is studying the job, its fields and states, and the systems it should connect to.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

For your industry

Questions about internal tools

Why not a no-code app on top of the spreadsheet?

For a few people and a simple job, that's often fine. It stops working when you need rules, permissions, history or connections to other systems.

What happens to the 912 rows?

They're imported. Duplicates are merged, free-text statuses are mapped to the fixed states, and anything that can't be mapped is listed for a person to decide.

Can it grow?

Yes. It's built on a real database and an API, so a second job can be added later, or it can become part of a larger platform.

Who maintains it?

You own the bespoke work you paid for and receive the code and documentation needed to run it. You can run it yourself or with your own developer, or add optional support from us.

Replace the spreadsheet that runs a job

Tell us about the spreadsheet only one person understands. We'll show you what it would look like as a tool.

Start a project