We build the software a business needs when the market product almost works. The honest version of that sentence includes telling you when it does not apply, because custom software you did not need is the most expensive thing on this page.
The pattern is consistent: a stack of tools that each do part of the job, joined by a human who exports from one and imports into the next. It is invisible on the balance sheet because nobody bills for it, and it is usually the single most expensive process in the company.
Before quoting a build we look at whether an existing product plus configuration does the job. When it does, we say so. Losing that project costs us less than delivering software you should not have commissioned.
Most bespoke software encodes a process that lives in one person's head. Writing it down surfaces the exceptions, and the exceptions are where the budget goes.
TypeScript, Next.js, Postgres. Chosen so that replacing us is a recruitment problem rather than an archaeology project. Novel technology is a cost you pay later.
The first slice goes live and gets used while the second is built. You find out whether the thing works against reality early, when changing it is still cheap.
Accounting, CRM, warehouse, payroll. The value of internal software is usually in removing the manual step between two systems that already exist.
Repository, database, infrastructure accounts, documentation. No runtime licence, no dependency on us continuing to exist.
We would rather talk you out of a build than deliver one you regret, so here is the framework we actually use. It is the same one we apply to our own tooling, and it has told us to buy more often than to build.
Every company believes its process is unique. Most of the time it is merely familiar. The test is whether a customer would notice if you did it the standard way. If invoicing works oddly because of a decision made in 2019 that nobody has revisited, that is not differentiation, it is inertia, and encoding it in custom software makes it permanent. If the process is genuinely how you win work, custom is defensible.
A common trigger is subscription cost, and it is usually the wrong number to look at. Software licences are visible and comparatively cheap. The hours spent moving data between those tools are invisible and comparatively expensive. Before commissioning anything, count how many hours a week a person spends as the integration layer. If it is under two, a build rarely pays back. If it is a day a week, the arithmetic changes completely.
A large share of custom software requests are really integration requests. The existing tools are fine individually and the pain is entirely in the gaps between them. That is frequently solvable with a much smaller piece of software that moves data and reconciles it, rather than a replacement for any of the systems. It costs a fraction and leaves you free to change vendors later.
Custom software is a permanent commitment, not a purchase. Dependencies need updating, the OS underneath gets end-of-lifed, an integration partner changes their API, and the business changes. Budget for that from the start rather than discovering it in year two. A market product includes this cost in the subscription, which is often exactly what you are paying for.
The outcome to avoid is custom software that covers eighty percent of the process, leaving the remaining twenty percent as a manual workaround plus a spreadsheet, so you now maintain software and still do the job by hand. This happens when scope is cut under pressure without revisiting whether the remainder still makes sense. If the budget only reaches eighty percent, the right decision is usually a narrower system that fully owns a smaller piece.
Usually you do not, and that is worth checking before anyone quotes. Custom is justified when the process is genuinely specific to how you compete, when the market products require you to change the process in a way that costs more than the software, or when integration between existing tools is the actual problem. It is not justified because the existing tool is ugly, or because a feature is missing that the vendor ships next quarter. We do this assessment as the first phase and the output is yours even if the answer is buy rather than build.
Quoted per project, on request, and the honest answer is that the range is enormous because the phrase covers everything from a form that writes to a database to a system that runs a warehouse. What narrows it: how many people use it and in how many roles, how many external systems it touches, whether the process is written down or lives in someone's head, and whether existing data has to come across. The scoping phase exists precisely to turn that range into a number.
You keep everything and can hire anyone. The code is in your repository under a mainstream stack, the infrastructure accounts are in your name, migrations are in version control, and the runbook explains how to deploy and restore. This is the question you should ask every supplier, and the answer should be demonstrable rather than reassuring. Ask to see the runbook before you sign anything, with us or anyone else.
Yes, and it usually goes better than replacing them. They know the business and the systems, and we know the parts they do not have time for. Practically this means agreeing where the boundary sits, working in the same repository with reviewed pull requests, and writing decisions down so the knowledge stays with you when the engagement ends.
The first usable slice typically lands within a few weeks of scope being agreed, and it goes into real use while the next is built. This is not a preference, it is risk management: software that meets a written specification but not reality is the most common failure mode, and the only reliable way to find out is to put a small piece in front of the people who will use it.
Neither. The whole engagement runs in writing, including scoping. In practice this suits internal software particularly well, because the specification ends up documented as a by-product rather than living in the memory of whoever attended the workshop.
Send what your team does by hand and which tools are involved. If an off-the-shelf product solves it, we will tell you which one. Written reply within one business day.
Request a quote →