What we refuse to build, and why

A building materials merchant asks us to fold invoicing into his new app, right on top of the software his accountant already knows by heart; a restaurant owner asks for a payroll screen, when his accounting firm has handled that reliably for years. In both cases, we say no. What we refuse to build says as much about how we work as what we do build.

Refusing to rebuild a tool that already does the job#

The first refusal is the easiest to explain: rebuilding something a standard tool already does well. Accounting software run by an accountant, compliant point-of-sale software, payroll software that gets payslips out every month without errors: we never offer to replace these with a screen of our own.

If an off-the-shelf tool does the job, take it. We will tell you so, and it does happen.

What we build connects next to it: data entered once in the app flows out to the accounting software in the right format, with no re-keying. The app handles what exists nowhere else for that specific trade, and leaves the rest to whoever already does it well. Choosing between an off-the-shelf tool and a custom app is a screen-by-screen call, not an all-or-nothing one.

Refusing a feature nobody can say who will open#

The second refusal comes up in almost every audit: a feature requested "just in case", with nobody able to say who will open it, or on which day of the month. An advanced accounting export nobody has asked for yet, a reporting screen built for a manager who never raised the question, a checkbox added "for later": these are the first screens that sit unused six months after launch, the same way the features you pay for and never open sit unused in off-the-shelf software.

Before adding a screen to a first version, we ask a single question: who will open it, and at what point in their month? If nobody can answer precisely, the screen waits. It comes back the moment one named person needs it for one named task, never before.

Take the hypothesis of a building materials merchant who asks for twenty screens on a first version. Asking that question of each one, five come back with no clear answer and drop out of the initial scope. In this example, that is five fewer screens to build, and a first version that ships sooner for everything else.

Refusing to carry the upkeep of a regulated topic#

The third refusal is carrying, on our own account, the ongoing upkeep of a regulated topic: payroll, mandatory electronic invoicing, point-of-sale compliance. These change by law, not by us, and a specialist vendor tracks those changes full time, often backed by a certification.

Building our own payroll screen would mean tracking every pay scale, every rate, every exception: work that belongs to a different trade than ours, and one that would leave the business exposed if we fell behind. We would rather connect the app to the specialist tool already in place, both ways: hours logged in the field flow to the payroll software, documents produced by the till flow back into the app for the day's tracking.

What you gain: a single legal update to watch, carried by whoever made it their trade, while the app covers what no general-purpose vendor covers for your specific business.

The checklist we apply before saying yes#

What changes with an app built for the business#

This checklist is applied before a single line is written, during the audit that opens the project. It keeps being applied at every later request, months after launch: a new feature goes through the same question, who will open it and when, before it enters the scope.

For you, the result is a lighter app to use, one that does not ask people to navigate past screens nobody opens to reach the ones they use every day. See what an app built for a business covers.

What this does not mean#

Saying no to a request does not close it for good. A screen set aside because nobody could name who would open it comes back the moment one named person needs it: the refusal is about timing, not principle. Likewise, connecting to an existing tool does not mean settling for it everywhere: if that tool later becomes a drag of its own, the question gets asked again then, not before.

What we refuse to build: the key takeaways#

Three refusals come up on nearly every project: rebuilding a tool that already does the job, adding a screen with nobody to say who will open it, carrying the upkeep of a regulated topic that is not our trade. One question settles most of these: who will use it, and at what exact moment?

A vendor who says yes to every request ends up building a heavier app than the business actually needs. Saying no at the right time is as much part of the job as saying yes to the rest.