Service

Custom Software

Most businesses reach this point the same way: a spreadsheet became load bearing, and now four people maintain it by hand. The work is to replace that process without pretending the rest of the business will change to suit it.

Request thisProject or day rate

Engagement
Fixed scope per milestone, or day rate
Typical length
Three weeks to six months
Handover
Documented code, your infrastructure, your data
Best for
A process no off-the-shelf tool fits

Deliverables

What You Actually Receive

Named up front, so there is something to hold the work against when it is finished.

01

The Process, Mapped First

What actually happens today, including the exceptions people handle manually. The exceptions are usually where the real requirements are.

02

A Working Slice, Early

One complete path through the system in front of real users within weeks, rather than a full specification signed off in advance and discovered to be wrong at the end.

03

Integrations That Survive

Payment, logistics, ERP and CRM connections built to fail loudly and retry, because the systems on the other end will go down.

04

Operable Software

Logging, backups, error reporting and a runbook. Software nobody can operate is not finished.

In detail

How The Work Runs

What This Covers

Internal tools that replace a spreadsheet or a manual process. Dashboards that put the numbers a business already has in one place. Client portals. Data import and export between systems that were never designed to speak to each other. Occasionally a desktop application, where the work genuinely needs to happen on a machine rather than in a browser.

The common thread is that no product on the market fits the process closely enough, and bending the business to fit a product would cost more than building the thing.

Built Around The Existing Business

The systems already running the business (the accounting package, the ERP, the warehouse, the payment provider) are constraints, not obstacles. Software that requires everything around it to change does not get adopted, whatever its merits.

Where an existing system is genuinely the problem, that gets said. But it gets said with the migration cost attached, not as an aside.

Scope And Money

Work is quoted per milestone, each one small enough to be estimated honestly and useful on its own. A typical shape:

# Milestone Ends with
01 Process mapping A written description of what happens today, exceptions included
02 Thin slice One complete path working, in front of real users
03 Core build The everyday cases, in production
04 Integrations The connections to whatever else the business runs
05 Handover Runbook, backups, monitoring, and the code in your repository

If a milestone turns out to be wrong once it meets reality, it is re-quoted before the next one starts, not absorbed quietly and billed later.

You can stop after any milestone with working software and the code in your hands. That is the point of cutting them this way.