Skip to main content

Custom internal tools

A custom internal tool, built for how your team actually works.

You have looked at the platforms. Each one does about sixty percent of what you need, and your team covers the other forty by hand, in a spreadsheet nobody admits to.

Software for the specific step nothing off the shelf handles, designed with the people who will use it every day. Typically:

  • The workflow that currently lives in a spreadsheet nobody officially maintains
  • The handoff where information gets copied between two systems by hand
  • The screen your team wanted from a platform that was never going to build it

You own the code and the data, with no per-seat pricing.

You'll recognise this if

  • You pay for a platform and your team still keeps a spreadsheet alongside it
  • Onboarding includes explaining a workaround that exists because the software cannot do something
  • Someone spends part of every week copying information from one system into another
  • Your per-seat bill grows faster than the number of people doing the work
  • You have asked a vendor for a feature and been told it is on the roadmap
  • The way you do this particular thing is genuinely better than your competitors, and no product supports it

How we'd approach it

  1. 1

    We follow one real job end to end

    Not a workshop about the ideal process. We take one job that already went through and mark every point where somebody retyped something, waited for someone else, or opened a spreadsheet to cover a gap. Those points are the specification.

  2. 2

    We design the screens before writing code

    You see and react to the actual screens while changing them is still cheap. The people who will use the tool every day are in that conversation, because they are the ones who know which field is missing.

  3. 3

    We build it to sit alongside what you keep

    Most of what you pay for stays. We build the missing piece and connect it to the calendar, accounting and phone system you already run, so nobody has to abandon a tool that was working.

What changes

  • The platform does most of it, your team does the rest by hand

    The whole job happens in one place

  • A shadow spreadsheet nobody officially owns

    The spreadsheet retires, and its logic is in the system

  • Per-seat pricing that grows with headcount

    Software you own, with no per-seat pricing

  • Your best process is unsupported by any product

    Your best process is what the software is built around

We've done this before

Consumer shopping app

A native app, built end to end by one person

A consumer shopping product needed a native iOS app, the web platform behind it, and live payments moving through both. Designed and built end to end, with the earnings ledger guarded by 115 automated database tests rather than trusted to application code.

Read the case study

Home services marketplace

Real money movement, built and hardened

A marketplace moving real money between parties, built and then hardened. Money is the part of a custom build where correctness has to be enforced by the system rather than checked by a person.

Read the case study

Common questions

Why not just use Salesforce, or a platform like it?
Often you should, and we will say so on the call. A platform is the cheaper answer when the way you work is ordinary for your industry. It becomes the expensive answer when you are paying per seat for software your team works around, because then you are funding both the licence and the workaround.
What happens if we need changes after launch?
There is optional monthly support for fixes, monitoring and the next round of improvements, and it is cancelable whenever. Plenty of clients use it for a few months and stop. Because you own the code, stopping does not strand you.
We are a small team. Is a custom tool overkill?
Team size is the wrong measure. What matters is how much time the gap costs and how central it is to what you sell. A four-person firm losing a day a week to a handoff has a stronger case than a forty-person firm with a minor annoyance.
How do we avoid ending up with software only one developer understands?
You get the code, the documentation and a real handover, and it is built with the ordinary tools other developers already know rather than anything exotic. The test for whether that worked is whether another developer can pick it up, so that is what the handover is built to satisfy.

This is one way into the custom business software we build. Most projects start with whichever piece is costing the most and grow into the others, so it is worth seeing the whole picture before deciding where to begin.

Start with thirty minutes.

Tell us what's slowing you down and we'll tell you what we'd build. How much scoping it needs before a quote depends on the job, and we'll be straight with you about that.