When we tell the client they don't need a custom app

A company calls us wanting "an internal application". Usually, the description starts with an existing tool that can no longer cope: a spreadsheet with twenty sheets, a WhatsApp group used as an ordering system, or old software that no longer has support.

Our first job isn't to estimate. It's to understand if a product on the market solves the problem faster and cheaper.

What makes us recommend an existing tool

If a company's process looks the same as hundreds of other companies – invoicing, simple appointments, standard stock records – a subscription to a mature product almost certainly beats an application written from scratch. Not just on price, but on what happens in year two: who repairs it, who adds to it, who is available when the person who wrote the code no longer works with you.

We've lost projects by being honest here. That's fine. The alternative is to deliver something that becomes a burden.

What makes us say yes

Custom makes sense when there's a rule in the process that no product on the market has. A client who worked with cut-based orders had their own way of calculating material consumption, with exceptions for each supplier. Their Excel worked, but only they understood it, and the company couldn't grow beyond it.

The second case: integration. When data needs to flow between two systems that don't communicate, and someone copies it manually daily, the integration work pays for itself.

How we start, so we don't build in vain

We don't start with everything. We start with the part where the most time is lost, deliver it, and put it into real use for a few weeks. Only then do we decide the rest, with what we've learned from how people actually use it.

We also made the opposite mistake. For one project, we accepted a long list of features established in advance, which no one ever used after delivery. We redid part of it at our own expense. Since then, we insist on small deliveries, even when the client prefers one big handover.

What we can't promise

We can't accurately estimate a project where the rules aren't yet written anywhere. We give a range, say what would make it grow, and keep the client updated weekly. When someone gives you a fixed figure for a process they haven't seen, that figure has a hidden margin built into it.

If you have a process that relies on a single person or a file that's no longer coping, let's look at it before we talk about budget.

Existing tool or bespoke application

We have this discussion almost every time we get a request for "an internal application". There's no universal answer, but there are criteria.

What the first stage looks like when we say yes

We don't start with design or the database. We start with a map of the steps a person in the company takes on an ordinary day, written together with them, not with the manager. From there, almost always, a step emerges that can disappear completely.

The most useful outcome of an analysis meeting is when the client says "wait, but why are we doing this?". We've left meetings a few times with a smaller project than requested.

What costs more than people think

Not the visible part. The exception cases: what happens when someone cancels, when an order arrives partially, when two people modify the same thing at the same time. These consume time, and if we leave them until the end, the application seems ready but isn't.

What we can't promise

We've also given bad advice here: for one client, we recommended an existing tool that proved too rigid for their process, and after three months, we redid that part bespoke. It depends a lot on how well you know the process beforehand, and we never know it completely from the first meeting.

We cannot state the final price at the outset for a project we haven't fully described, and we don't promise a fixed deadline before analysis. If someone gives you both in an email, either they've done that exact project before, or they won't stick to them.

If you have a process that hinders you daily, let's describe it together. Sometimes the conclusion is that you don't need us for it.