Custom software development.

Custom is the expensive answer, so it should be the second one you consider. We open most of these conversations by trying to talk clients out of them, because a rule that Shopify, an off-the-shelf ERP or a configured SaaS product can already express does not need a bespoke system built to hold it.

When custom software is genuinely the right call

It is the right call when the rules are the product — when what makes the business work is precisely what no product lets you configure.

• Contract pricing per account, with tiers, volume breaks and negotiated exceptions that differ by customer.
• Approval chains, where an order or a change has to pass through named people in a defined order and the trail matters afterwards.
• Split deliveries and partial fulfilment, where one order becomes several shipments across dates, warehouses or vendors.
• Weight-adjusted or measure-adjusted invoicing, where the customer is charged on what was picked rather than what was ordered.
• Entitlements and licensing, where what a customer may access is a calculation rather than a purchase.

Here is the test we actually use. If the workaround has a full-time employee attached to it — someone whose job is reconciling the spreadsheet with the system — then the workaround is already the more expensive option, and it is getting more expensive as you grow. If it does not, keep the workaround a while longer.

Build, buy, or configure?

Most operations end up with a mix, and the useful question is which parts belong where.

Where each option fits

Option	Fits when	Fails when
Buy an off-the-shelf product	Your process resembles the industry standard and you can adapt to it	You start paying people to bridge the gap between the product and reality
Configure a platform	The rules fit inside the platform's extension points	The workaround becomes load-bearing and nobody dares change it
Build custom	The rules are your competitive advantage, or no product expresses them	You build what you could have bought, and now maintain it forever

What we build

B2B ordering platforms

Account-based catalogues, contract pricing, credit limits, quotes, standing orders and reorder flows — with an internal order-entry mode so the sales team can place an order on a customer's behalf. The Servana platform is one of these: 82% of order volume moved off WhatsApp within two quarters.

Customer and partner portals

Self-service for the things that currently arrive as email: order history, documents, returns, claims, account management, reporting. Usually the fastest measurable win, because every request the portal answers is one your team no longer handles by hand.

Internal tools and operations systems

Warehouse and picking flows, allocation, scheduling, pricing administration, approval workflows. Unglamorous, and frequently the highest-return software a company builds.

Integration layers

The connective work between an ERP, an accounting system, a logistics provider, a payment gateway and a storefront — with retries, idempotency and reconciliation, so a failed message is visible and recoverable rather than silently lost.

Modelled before it is built

Discovery ends with a written domain model: the entities, the rules, and — the part most specifications skip — the exceptions. Every custom system we have inherited from another team failed in the same place, which is the case somebody decided was too rare to write down. The rare case is not rare. It is just infrequent, and it is usually the one with money attached.

The model is written in your language, not ours, and it is reviewed by the people who do the work rather than only by the people who commissioned it. That review is where most of the value of discovery actually appears, because it is the first time the rules have all been in one document.

How it is built

Laravel or Node.js over PostgreSQL, deployed to infrastructure you control. Roles, permissions and an audit trail from the start rather than added later. Automated tests over the rules that carry money, because those are the ones nobody wants to verify by hand at two in the morning. Delivery is incremental against a staging environment you can open at any point, so the first time you see the system is not at handover.

Security is treated as scope rather than as a phase: authentication, authorisation, input validation, encrypted secrets, dependency monitoring, and a threat model that matches what the system actually holds.

Yours, including the parts that are inconvenient for us

You own the repository, the database schema and the hosting from the first commit. Architecture decision records, runbooks and a test suite ship with the software, and handover includes sessions with the people who will operate it. There is no licence that turns into leverage at renewal.

We would rather keep a retainer because the work is good than because leaving is difficult. In practice most clients do keep one — but the arrangement should be a choice, and it is only a choice if the documentation is real.

Who this is for

Wholesalers and distributors whose ordering runs on email and spreadsheets. Manufacturers with configure-to-order products. Retailers with fulfilment models no storefront supports. Service businesses whose scheduling or entitlement rules are the business. Companies replacing a system that was custom-built a decade ago by someone who has since left. If you also need a storefront in front of it, that is ecommerce development, and the two are usually scoped together.

What it costs, and how long it takes

Both fall out of discovery, which is why we will not quote either before it. The variables that move a custom project are the number of distinct business rules, the number of systems it must integrate with, how much data has to be migrated and cleaned, and how many people need distinct roles inside it.

The first conversation is free and it is a scoping conversation, not a pitch. If we think you should configure something off the shelf instead, we will say so on that call. Discuss your project.