The system a firm runs on.
A debt advisory CRM in full production. It replaced a Monday board, it was built from the team's own wishlist, and the firm is completely reliant on it. This is the one I would point at first.
The prospect view, running here with the same orbital geometry and the same CSS the CRM uses. In the product every body is a live prospect and its orbit is how hot the deal is.
- Role
- Sole developer
- Status
- Production, business-critical
- Database
- 211 tables
- Replaced
- A Monday board
Built from a wishlist, not a specification
Benchmark were running a debt advisory practice on a Monday board. It held tasks. It did not hold covenants, or bank submissions, or a loan book, or the reason a deal stalled three weeks ago. Everything the board could not carry was carried by people remembering it.
I asked what they wished it did, then built that
Not a requirements document. A wishlist, from the people who had the software open all day, about the things they had quietly given up expecting. Then the same question again a fortnight later, once they had seen the first version and realised they were allowed to ask.
A generic CRM cannot answer a covenant question, because covenant reporting is not a stage in a sales funnel. It is a recurring obligation with a due date, a document, a bank on the other end and consequences for missing it. That shape does not exist in an off-the-shelf pipeline tool, which is exactly why the practice was carrying it in people's heads.
What it actually holds
Thirteen modules, each one replacing something that used to be a spreadsheet, an inbox rule, or somebody's memory.
Covenant compliance, end to end
Every reporting requirement across the loan book, moving through eleven states from current to satisfied, waived or extended. Due dates, borrower notification, documents received, submission to the bank. The dashboard opens on it because it is the thing with consequences attached.
Live market rates
RBA cash rate, BBSY at thirty, sixty and ninety days, and swap rates at two, five and ten years, refreshed and stamped with the time they were pulled. A broker quoting off yesterday's number is quoting the wrong number.
Prospects, deals and the loan book
A prospect pipeline that becomes a deal, a deal that becomes a facility, and a loan book that remembers the terms. Credit assessments and bank submissions sit on the deal rather than in an inbox.
Documents, signing and letters
A filing taxonomy so documents land in the right folder without anyone choosing one, letter templates with real rich text that survives the trip to PDF, and e-signing built in rather than bought as a third subscription.
HR, leave, events and analytics
Team records, leave and public holidays, an industry events calendar, a personal hub for each staff member, and analytics over the whole lot. The parts of a business that usually get their own subscription each.
An agent that learns the repetitive jobs and takes them over
Doc McFindy watches how the team handle the tasks that come round again and again, learns the pattern, and starts executing them. Not a chatbot bolted to the side: an agent doing real work inside the system that holds the data, so the people are left with the judgement calls, the relationships and the exceptions, which is the part no automation is going to cover.
Then I took some liberties
The brief was to replace a Monday board. Nothing in it said the result had to be joyless. These people look at this software for eight hours a day, and a tool you stare at that long should give something back.
A pipeline you can read at a glance, from across the room
It is a real visualisation of real data, not an ornament. Orbit distance is deal heat, so the shape of the quarter is legible before you have read a single card. The board underneath lost nothing to make room for it.
It is also the thing people show other people. Software that gets shown off gets used, and a CRM only earns its keep if the team actually lives in it rather than updating it under duress once a week.
Doc McSigny, Doc McFindy, and the rest of them
The e-signing module is Doc McSigny. The spreadsheet tool is Doxcel and the announcements feed is Dox News. The help button asks "What's up Doc?". Doc McFindy, the agent that takes over the repetitive work, is a robot in a bow tie.
Giving the agent a face is not decoration either. Software that quietly does your job for you is unnerving when it is invisible and faceless. Make it a character with a name and a look, and people talk about what it has taken off them instead of wondering what it is up to.
None of this is in a specification anywhere. It exists because a system the whole firm depends on should feel like it was made by somebody, for them, rather than bought by the seat. The names are how you tell the difference.
The rest of the surface
Thirteen modules is a number until you see them. These are the ones that can be shown without exposing a client, and two of them are the reason people lean in.
The event tracker finds its own eventsNobody maintains this calendar. An agent goes out, reads what the industry bodies have published, and adds what is relevant. The banner is it reporting back: two new events discovered, and where they came from. Twenty-eight events across nine organisations, none of them typed in by a person.
Doc McSigny: build a form, send it, watch itCreate, Send, Track, View. That is the entire interface, and it covers custom form building as well as document signing. E-signing is usually a third subscription and a second login. Here it is four cards, and the documents never leave the system that holds the deal.
Analytics across the whole bookPipeline, settlements, lender relationships and the loan book, in one place rather than in whichever spreadsheet last got updated. Figures redacted.
HR, because the firm is a thing tooTeam, development and compliance, reports, compensation and onboarding, plus the post-settlement handover rule. A CRM that only knows about deals makes somebody keep a second system for the people doing them.
Settings the client actually ownsDropdowns, stages and taxonomies are configuration, not code. Benchmark change how their own pipeline is labelled without asking me, which is the difference between owning software and renting a developer.
What business-critical actually costs
A firm that cannot work when the software is down needs more than working software. These are the parts of the build that exist purely so that never happens.
A deploy that cannot take the business offline
The default way to ship a new version is to replace the running one where it stands. It is quick, it is what most tooling does out of the box, and it means the firm has no CRM for as long as the new build takes. That is a fine trade for a side project and the wrong one for software a business runs on.
Deploys here build in a second checkout, leaving the live application untouched until the new build succeeds, then swap it in. Database migrations run only after the build passes, so the schema can never get ahead of the code. A rollback script swaps the previous build back in seconds.
A test instance that refuses to boot if it can reach anything real
Staging runs on the same box against a copy of the database. The danger is obvious: the application authenticates to Microsoft Graph as itself, not as a signed-in user, so a carelessly copied environment file would let a test instance send real email, write real files to SharePoint and re-point live mailbox webhooks.
So it checks. A guard runs at boot and refuses to start if production credentials are present, or if the developer login is ever paired with the production database. The safety is enforced by the software rather than by remembering.
Authorisation that cannot be forgotten
Every server-side action in the codebase must call the permission check before it does anything. It is a standing rule in the project's own instructions, so it survives being forgotten at four in the afternoon eight months from now.
The same applies to credentials: a pre-commit hook blocks anything shaped like a secret, and the deploy scripts read what they need from the environment at runtime, which is precisely why those scripts can live in version control at all.
Numbers on screen that are actually the numbers
Every reporting screen ever built is exposed to the same quiet arithmetic: a list capped at fifty rows, with the total underneath it calculated from those fifty rows. The page looks right, the number is not, and nobody catches it until someone reconciles against the bank. In debt advisory that is the number a client acts on.
So the whole codebase is audited against exactly that shape. Every capped query either carries real pagination with a database count behind it, or an explicit comment saying it is a deliberate preview. Displayed totals come from a database aggregate, never from counting a slice.
The shape of it, in numbers
- Database schema
- 6,057 lines
- Server actions
- 120 files
- Test files
- 209
- Modules
- 13
Self-hosted on infrastructure Benchmark own, with the database on a private network, nightly backups taken before every deploy, and a documented rollback. The same ownership argument the ownership page makes, applied to the largest thing here.
Why I hang my hat on this one
It is a whole firm's operating system, built by one person, and they cannot do their work without it. That is a heavier thing to be trusted with than any feature list, and it is the clearest answer I have to the question of whether a custom platform is worth building.