Custom software
When nothing you can buy fits, we build the small system that does.
Some businesses have a shape no product matches: a single place where every job and its status lives, a portal customers check themselves, a dashboard that shows the week at a glance, two tools joined so they behave as one. We build those, small and plain, and you own the result outright. When an existing product would serve you better, we say so before you spend anything.
The fit
When custom is the right call
Off-the-shelf software fits most businesses most of the time, and for less than anything built ever costs. The signals below are what it looks like when yours is the exception.
- You pay for a platform with a hundred features, use six, and the one you actually need is missing.
- The same information is typed into two tools by hand, and the copies disagree by Friday.
- The way a job moves through your business lives in one long-serving employee’s head and nowhere else.
- You have bent a product so far from its purpose that every vendor update breaks your workarounds.
- Customers call to ask where things stand because there is no page you could point them to.
- Every product demo ends with you realizing you would have to change how you work to match the software.
The work
How good custom work is done
Purpose-built does not mean big. The systems we build are deliberately small, and keeping them small, honest and yours takes more discipline than code. This is what that discipline looks like in practice.
An honest fit test
Custom software loses to a good product more often than it wins, and the assessment starts there. If a standard tool covers the job and the gap is only at the edges, we say buy the tool, and we can help you set it up. Building earns its keep when the mismatch sits in the middle of your operation — when the workarounds, the retyping and the errors cost more each year than a small system would. We put that comparison in writing so you decide on numbers, not on our enthusiasm.
Boring on purpose
Everything rests on foundations that have been dull for a decade: a relational database, a mainstream framework, hosting that thousands of other companies run on. Novelty is a cost you pay later, when the clever part needs a specialist to touch it. A boring system is one any competent developer can pick up cold, which is exactly the property that keeps you free to leave us.
The least that solves it
Scope is what decides whether this ends well. Every screen and every feature carries a permanent maintenance cost, so the first version does one thing: remove the problem that made you call. Ideas that come up along the way go on a written someday list rather than into the build. Given a few months of real use, many of those ideas stop looking necessary — and the ones that survive can be added to a system that is already working.
Where AI belongs
Most of what these systems do is not AI, and should not be. A step that runs the same way every time is written as ordinary code, which costs less and fails predictably. AI is reserved for steps that need reading and judgment, and it earns access to each one by clearing checks drawn from the history of your own operation — actual jobs, not demo data. Anything a customer might see waits for a person to approve it, and when the AI gets one wrong, that failure joins the checks it must clear from then on.
Running costs, in writing
Software you own still costs money to keep on: hosting, a database, email delivery, AI usage if there is any, each billed by its provider to your card, not ours. Before the build is approved you get the list — every service, what it does, and a realistic monthly figure — so the operating cost is a number you accepted, not a surprise on a statement. If a design choice would push that number up, you hear about it while it is still a choice.
Handover as a standard
A system you cannot run without us is a system we built wrong. From the first day, every account is registered to your business, the source code sits in a repository you control, and decisions are written down as they are made. At the end, the people who will use it learn it on the running system, and the documentation is judged by one test: a developer who has never met us should be able to take over from it alone. Keeping us on afterwards is a convenience, never a leash.
The engagement
From first call to handover
Fit call
A conversation about the process, not the technology. We ask what the workarounds cost you and check whether an existing product already solves the problem. If one does, we name it and the engagement can end right there; that answer is worth having.
Specification
We watch the work being done and write down exactly what the system will do, what it deliberately will not, and what it costs to build and to run. The price is settled before a line of code exists, and it does not move unless the scope does. You approve the document, and the document is the deal.
Build in stages
The first working version arrives early and handles a real slice of the job, so your team is using it while the rest is still being built. Corrections made at this stage are cheap; the same correction after launch is not. You see progress as working software, never as a status report.
Handover
Any account not already in your name moves there, your people are trained on the system they will actually use, and the code and documentation are delivered with nothing held back. Support from us afterwards is optional and billed on its own. The system does not need us to keep running.
What you keep
What you have when it ends
The end state is artifacts, not dependencies. Everything needed to run, change or replace the system is in your hands, not ours.
- A working system in daily use, on accounts in your company’s name.
- The full source code in a repository you control, yours to change or hand to any developer.
- An operating guide in plain language: what the system does, what it costs each month, and the first things to look at when it misbehaves.
- Staff trained on the real system, doing their real work.
- The written someday list of what was left out on purpose, so the next version starts from decisions, not memory.
Next step
Talk it through first.
Bring the process nothing seems built for. On a short, free call we will say whether it justifies custom software — and if a product already covers it, we will name the product instead.
Book the call