Insights / Product

Internal tool or off-the-shelf software: start with the work your team still does by hand

Before comparing features or five-year costs, look at who retypes what, which email threads drag on and which report gets rebuilt every Monday. Here is how we choose between off-the-shelf software, a custom tool and plain manual entry.

Internal tool or off-the-shelf software? Don't start with a feature list or a five-year cost spreadsheet. Start with the work the tool would replace: who retypes what, which email thread never ends, which report gets rebuilt every Monday. If that work is standard, buy. If it's specific to your business and comes back every week, a custom tool can pay for itself fast.

Custom or off-the-shelf: first look at what your team still does by hand

An agency asked us to run a workshop on about fifteen AI tools. The prep document was long. One detail was almost buried in it: the team was already paying for a coding assistant built into their development tool. They had never switched it on.

This team wasn't short of tools. It was short of someone looking at where work fell through the cracks. The expensive part is the gaps between tools, not the missing extra tool.

Since then, we always open with the same question: "Show me the last tool you paid for and never really adopted." If the answer comes quickly, that's where we start.

Then we look for three very concrete things:

  • Retyping. Who copies information that another tool already has?
  • Lingering emails. Which questions come back every week, from the same people?
  • The Monday report. Which table gets rebuilt by hand, the same way every time?

Until those three lists exist, comparing software is choosing an answer without knowing the question.

When off-the-shelf software is enough (more often than you think)

A Belgian guide makes the point: custom only makes sense for a distinctive process that no product on the market handles, and you should compare the options over five years.

For accounting, payroll, invoicing or e-signatures, buy. These areas are regulated, and legal updates are included in the subscription. You have no reason to track every change in the law yourself.

There's also a third option people forget: manual entry. For a charity campaign website, we needed to show a runner's progress, stage by stage. The first idea was to pull his runs from Strava. When we looked into it, the integration raised two concerns for us: what API access would cost, and whether the terms of use allowed us to display an athlete's data publicly.

So we replaced the integration with a simple checkbox in the back office. The editor ticks off a stage, and the distance calculates itself. No cost, no legal risk, and the site went live without delay. When the real need fits in a single number, an expensive integration is usually overkill.

Signs that an internal tool, client portal or dashboard will pay off

The first sign is mundane: a spreadsheet shared by several teams. That's exactly the moment to scope a first internal version. If three departments are fighting over the same file, that file has already become your business software, just a less reliable one.

One decision grid uses six criteria: how specific the process is, the number of users, how mature the need is, the three-year budget, data constraints and how fast things change. It concludes that custom wins as soon as three criteria point that way.

We applied this reasoning to ourselves. Clients regularly wrote to ask "where are we at?" Every reply took time and interrupted the work in progress. No product on the market combined what we needed. So we built our own client portal: one page per project, with the current phase, what we're waiting on from the client, invoices and a question form. Clients see progress without having to ask. Our internal notes and figures stay on our side.

Last sign: the hidden costs of bought software. Per-user pricing goes up with every hire, add-on modules pile up, and time lost on workarounds adds up. And then there's dependence on a vendor that can change its prices or terms while it holds your data.

What an internal tool really costs once it's live

Published benchmarks are telling. For a small business, one comparison prices generic SaaS as a per-user monthly fee with no setup cost. Classic custom development needs a significant upfront investment, then a monthly maintenance bill. Over five years for five users, the same table puts custom at a range that starts above SaaS and whose top end goes far beyond it.

The key takeaway: the real cost isn't the build, it's the maintenance. A tool that collects data from third-party websites works fine for a few weeks. Then a site changes its layout, and the tool keeps running while showing stale data, with no error at all. Nobody notices until a client points it out.

Same risk with a pay-per-use service: if AI credits run out overnight, the morning reports never go out. And the error message often mentions a technical code, not an account that needs topping up. That's why we monitor how fresh the data is and the balance with each provider, not just whether the tool is running. And we put maintenance in the budget as its own line, from the first quote.

How we build a first internal tool with a growing business

At Pillet Grenié Bureau, we never start with code. We first observe a week of real work, using the three lists above. Then we list the subscriptions you already pay for. Sometimes a feature you're already paying for solves half the problem.

Then comes the decision: we pick a single repetitive task, the one that eats the most time each week. The Monday report, client follow-ups or retyping between two tools. Not a full platform. A useful first version, delivered in a few weeks.

Safeguards go in before launch. What a client sees is filtered at the source, and internal notes never leave our systems. Access can be cut in one action. An alert fires if the data stops updating. And we check every technical promise before building it: we'd rather say no to a feature than deliver maintenance nobody budgeted for.

The result is measured in time given back to the team: a report that prepares itself, clients who find the answer without writing in, information entered once. And if the tool hasn't delivered anything after a month, the decision is simple: we switch it off.

If you want to know which of your processes deserves a tool, and which only deserves a checkbox, that's exactly what Bureau does with custom internal tools and client portals.

Written by

Pillet Grenié BUREAU was founded by Quentin Pillet and Tom Grenié.

About the studio
Related service

Product build

Design and build a web product, internal tool or client portal—or help finish a project that has stalled.

More on Product

Tell us what you need help with.

You don’t need a finished brief. Tell us what you’re trying to do, what is getting in the way and what you’ve already tried.

Start a conversation
Technical Insight