Custom Software
Build one focused application around the full job.
For a job that matters, currently held together by a spreadsheet, an inbox, and somebody's memory.
One place holds the record, shows whose turn it is, and will not let the job skip a step. The rest of your systems stay where they are.
Symptoms
When the job outgrew the spreadsheet
At a wholesaler, the status of an order lives in a spreadsheet, two inboxes and a group chat, and each one is right about something different.
At a contractor, one office manager knows which jobs are waiting on a part, and the answer is in their head rather than in any system.
At a clinic, the same handoff is tracked in the scheduling system and again on a printed sheet, because the system will not hold the one field they need.
What you get
What exists when we hand it over
- 01
One record per job, with the current status on it.
- 02
Roles, so somebody without the right permission cannot advance the work by accident.
- 03
A history of who changed what.
- 04
Working connections to the systems you keep, and a defined behavior for when one of them is down.
- 05
A written definition of finished, which the application enforces rather than suggests.
Inside the system
Put the record, the role, and the status in one place you can trust.
Choose a workflow stage
Check selected. Automation checks: Catch missing details before work begins.
Sample interface · Operations workflow.
- Data model
- Defines the durable records, their identifiers, and which system is the source of truth for each field.
- Role-based access
- Maps each role to the records it sees and the moves it can make.
- System connections
- Defines the events, the sign-in, the retries, and what the screen says when a provider is down.
- Acceptance path
- Turns completion, invalid moves, and recovery into checks that actually run, not notes nobody reads.
- Ownership plan
- Names who owns the business decision, the code, the support queue, and the rollback.
Fit
Use focused software when the process, not the whole stack, needs replacing.
It works when one job has a beginning and an end, several people touch it, and no single place says where it stands.
A good fit when
- The job has a finish line that somebody currently confirms by asking around.
- More than one role touches it and each needs something different from it.
- The records already exist. They are simply in four places.
The wrong purchase when
- You want a general system of record for the whole business. That is a different purchase and a much bigger one.
- One person does the whole job start to finish and it works. Leave it alone and spend the money elsewhere.
- Nobody agrees what finished means. Settle that argument first, with us or without us.
Delivery
Release the smallest version that finishes a real job.
We model the whole path first, then build the narrowest version of it that a real job can travel all the way through.
- 01
Job map
Traces the job from the request to the moment somebody calls it done.
You keepThe job map, on one page.
- 02
Working slice
Builds the narrowest path that still completes a real job end to end.
You keepA running slice, usable on real work.
- 03
Role review
Each role tries what it should be able to do, and what it should not.
You keepThe role and permission table.
- 04
Controlled cutover
Moves a measured amount of live work across, watches what breaks, and proves the way back.
You keepThe cutover plan and the first release record.
Engagement
How we scope and quote it
One job, not a platform. The first release does one thing completely rather than five things partly.
- 01
Scope is fixed around a single job, and we say out loud which neighboring jobs are out of it.
- 02
The quote follows the scope, and the scope follows the diagnostic. We do not price a build we have not mapped.
- 03
We need whoever runs the job today, plus whoever can approve a change to how it runs.
- 04
If a product you can buy already does this well, we tell you which one and stop there.
Questions
Do we have to move off the tools we already pay for?
No. We build around them and connect to them. Replacing your accounting or your email is not the job.
What happens to everything in the spreadsheet?
It comes across as part of the first release, and we agree beforehand which columns are worth keeping.
Can our own team change it afterwards?
Parts of it, and we are explicit about which parts before we build. The rest is a change request, and you hear what it involves before you commit.
What does a build like this cost?
We quote against the written scope that comes out of the diagnostic. Before that, any number is a guess and you would be right not to trust it.
Who keeps it running once it is live?
We name that before launch. It can be us or it can be your own people, but it is written down rather than assumed.