service
Custom software for processes that do not fit a product
Most organisations should buy software, not build it. We say that first because the decision to build is the expensive one, and it is usually made for the wrong reason. Custom software earns its cost when your process is the thing that makes you competitive — and bending it to fit someone else's product would give that advantage away.
When building actually beats buying
There are three cases where custom pays for itself. The first is when the process is the differentiator: a pricing model, an underwriting rule, a routing algorithm that your competitors do not have. Configure that into a generic tool and you have handed it to every other customer of that tool.
The second is integration debt. If four systems have to agree and no product speaks to all four, the glue is where the cost lives. Buying a fifth product usually adds a fifth thing to integrate.
The third is licence arithmetic. Per-seat pricing that made sense at forty people can become the largest line in the budget at four hundred. That is a real trigger, but it is a finance decision, and it should be made with a spreadsheet rather than a preference.
If none of those describe you, the honest answer is that configuring an existing product will be faster and cheaper, and we will say so.
How we scope it?
We start by mapping the constraint rather than the feature list. A feature list describes what someone imagines the software doing; the constraint describes what actually breaks today. These are rarely the same thing, and the gap between them is where most budget is lost.
That produces a written architecture before any code exists: the data model, the boundaries between services, and the failure modes we are designing against. You approve that document. It is deliberately readable by someone non-technical, because the person paying for the system should be able to understand what they are buying.
We then build in two-week increments against it. Every pull request is reviewed by a second engineer and CI has to be green before merge — not as ceremony, but because the alternative is discovering a design problem in month five.
What you own at the end
The source, the infrastructure definitions, the migrations, the test suite, and documentation written for the team who will maintain it rather than for us.
We are not interested in the kind of dependency where the client cannot change anything without calling us. A handover that a competent in-house developer can act on is part of the definition of done, not an extra.
TypeScript · src/domain/pricing.ts
What owning the code actually means in practice. The rule lives in one pure function with no database, no framework and no HTTP in sight, so it can be read, tested and changed by whoever inherits it. The awkward case — the one the client mentioned once in a meeting — is named in the code and pinned by a test, which is the difference between a rule that survives staff turnover and one that gets quietly re-derived wrong.
/**
* Trade pricing, exactly as the client's sales team describes it.
*
* The odd one is `settlementDiscount`: it applies to the line total BEFORE
* volume banding, not after. Applying it after is the intuitive reading and
* produces numbers roughly 2% low, which is how the previous system had been
* under-invoicing for two years.
*/
export function priceLine(input: LineInput, terms: CustomerTerms): LineTotal {
const list = input.unitPriceMinor * input.quantity;
const afterSettlement = terms.settlementDiscountBps
? Math.round(list * (1 - terms.settlementDiscountBps / 10_000))
: list;
const band = terms.volumeBands
.filter((b) => input.quantity >= b.fromQuantity)
.sort((a, b) => b.fromQuantity - a.fromQuantity)[0];
const afterVolume = band
? Math.round(afterSettlement * (1 - band.discountBps / 10_000))
: afterSettlement;
// Minor units throughout. A float here is a rounding dispute later.
return { listMinor: list, netMinor: afterVolume, bandApplied: band?.id ?? null };
}
// tests/pricing.test.ts — the test exists to stop someone 'fixing' the order.
test('settlement discount applies before volume banding', () => {
const result = priceLine(
{ unitPriceMinor: 10_000, quantity: 100 },
{ settlementDiscountBps: 250, volumeBands: [{ id: 'v100', fromQuantity: 100, discountBps: 500 }] },
);
// 1,000,000 -> 975,000 (settlement) -> 926,250 (volume).
// Reversing the order gives 926,875, which looks close enough to pass review
// and is wrong on every invoice.
expect(result.netMinor).toBe(926_250);
});Who works on this
Nayemul Saheb
CEO & Software Engineer
Scopes the build, owns the architecture, and writes the code.
When we would tell you not to build
If your requirement is standard accounting, payroll, CRM, or helpdesk, buy the product. Those markets are mature, the products are good, and a custom version will cost more and do less for at least three years. We would rather lose the project than build you a worse Salesforce. The same applies if the real problem is that nobody agrees on the process yet — software will harden the disagreement rather than resolve it.
Common questions
- How long does a custom build take?
- A first production release is usually three to six months, depending on how many systems it has to integrate with. We give a range after the discovery phase, not before it — a number produced before anyone has looked at your data model is a guess wearing a suit.
- What happens if requirements change mid-build?
- They will. Building in two-week increments exists precisely so that a change costs one increment rather than a renegotiation. What we push back on is a change that contradicts the approved architecture, because that is the kind that quietly doubles the cost.
- Can you work with our existing in-house team?
- Yes, and it usually produces a better result. We work in your repository, follow your review process, and leave your team able to maintain what we wrote. If your standards are stricter than ours, we adopt yours.
- Do we own the code?
- Yes, outright, including the infrastructure definitions and CI configuration. There is no runtime licence and no component you have to keep paying us for.
- What does it cost to maintain afterwards?
- Budget roughly 15 to 20 per cent of the build cost per year for dependency updates, security patches, and small changes. Anyone quoting materially less is either excluding security work or expecting you to absorb it.
Related services
- Web Development
- Cloud Application
- DevOps