Internal applications

When the spreadsheet has become a business-critical application, build the real thing.

It started as a workaround. It now has formulas nobody understands, no access control, no history of who changed what, and the whole operation depends on it.

  • From $4,500
  • About 4 weeks to launch
  • 30 days operating support

Where the spreadsheet problem usually shows up

  • 01

    One spreadsheet runs the operation

    Everyone knows which one, and everyone is slightly afraid of it.

  • 02

    The off-the-shelf tool doesn’t fit

    You are paying for software your team works around, and the workaround is now the real process.

  • 03

    The internal app is unmaintained

    It still works. The person who built it left, and nobody will touch it.

  • 04

    Management can’t see the work

    There is no screen showing what is in progress, what is stuck, and what needs a decision today.

  • 05

    Onboarding takes months

    Because the real process is tribal knowledge and every new hire has to be told the workarounds one at a time.

What we actually deliver

  • Software designed around the task

    Screens built for the job someone is doing, not generated from a data model and handed over.

  • Permissions, logging and an audit trail

    Who can see what, who changed what, and when — the three things a spreadsheet can’t give you.

  • Connections to your systems of record

    So the new application is not another island that needs somebody to reconcile it.

  • Documentation and a handover path

    Written as a deliverable, not as an upsell, so taking it in-house is always available to you.

The spreadsheet is not the enemy. It is the specification.

Somebody built it because the business needed something the software did not do. It encodes years of real requirements — we read it rather than dismiss it.

  • We start from what the spreadsheet actually does, including the parts that look wrong until you ask why.
  • We keep the flexibility that made it useful and add the control that makes it safe.
  • We do not rebuild the whole thing at once. The riskiest part moves first.
  • The people who used the spreadsheet test the replacement before anyone switches.

What fixing the spreadsheet problem looks like in practice

  • Operations dashboard

    What is moving, what is stuck, what needs a decision

    One screen a manager opens in the morning instead of asking three people.

  • Exception queue

    Item → reason → context → resolve

    The work that needs judgement, in one place, with everything needed to make the call attached.

  • Approval workflow

    Request → policy check → approver → audit trail

    Policy enforced by the system rather than remembered by a person.

  • Internal portal

    One place instead of four systems and a shared drive

    Where staff go to do the thing, rather than where they go to find out where to do the thing.

What this looks like in production

Case studies that used this capability

  • Internal software · Integration

    Five to Nine

    Workplace events platform

    Event scheduling, user management and reporting were spread across the product and a set of external tools, and the platform could not be extended safely because so little of it was covered by tests.

  • Internal software · Automation

    Paved

    Newsletter sponsorship marketplace

    Matching advertisers to newsletter publishers, placing campaigns and reporting on them was relationship-by-relationship work that did not scale.

  • Internal software · Integration

    e-Locker

    Smart locker systems for asset management

    Physical locker hardware, asset records, users and permissions had to behave as one system, and the operational side of that was being held together manually.

The rest of what we do

Questions about the spreadsheet problem

Should we build or buy?

Buy, wherever something off the shelf genuinely fits — we will say so, and we would rather integrate it well than build a worse version of it. Build is the right answer when the process is a real differentiator, or when the gap between the tool and the workflow is currently being filled by a person.

What happens to our spreadsheet?

It becomes the specification, and it usually keeps running in parallel until the replacement has proved itself against real work. Nobody is asked to trust new software with a critical process on day one.

Who owns the code?

You do. It lives in your repositories, it runs on infrastructure you control wherever possible, and documentation is part of the deliverable. If you want to take it in-house, we hand it over and revoke our own access in writing.

Are we locked in?

No. Custom code and configuration built for you belongs to you, systems run on infrastructure you control wherever possible, and documentation is a deliverable rather than an upsell. If you stop working with us, your business should not stop working.

Is our company the right size for this?

The offer is built around businesses doing roughly $5M to $30M in revenue, with recurring internal processes and someone who owns them. Outside that range we will still reply — we will just be honest about whether we are the right fit.

Show us the spreadsheet the business depends on.

The one person maintains, everyone relies on, and nobody wants to touch. We will tell you what it would take to turn it into something that cannot be broken by a stray paste.

  • For businesses with $5M to $30M in revenue
  • No long-term commitment
  • Start with one workflow
  • Keep ownership of everything we build