One person builds this.
Here’s what constrains him.
The fair question about a small firm delivering software a bank will depend on is what happens when the person building it is wrong, tired, or in a hurry. The answer isn’t a promise about character. It’s a set of checks that fail the build, that the person who wrote them can’t wave through, and that we test by deliberately trying to slip things past them.
We aren’t asking you to take our word for anything on this site. We’re asking you to look at what would stop us from saying it.
What has to pass
before anything ships.
We name them instead of counting them, on purpose: a count goes stale the moment someone adds one, and you can’t verify it from here. A name is something you can ask us to show you.
We commit every word this site shows to the repository as plain text. Change a claim and the diff arrives in the pull request as prose, so the person reviewing it reads what a visitor will read instead of reconstructing it from code. A change that skips the snapshot fails the build.
Before the built pages can ship, we scan them for a former employer’s name, a competitor’s name, and internal project codenames. Where we name something on purpose, we write the exception down with its reason and print it on every run, so a judgement call stays visible instead of turning into a silence nobody revisits.
We check the load-bearing statements here against the rendered page, not the source: that our compliance posture never reads as an attestation we hold, that a percentage never appears without saying whose number it is, and that no copy anywhere implies a client we don’t have.
Every marketing page is measured against how Robert writes to a client: contractions, a person in the sentence, sentences of natural length, very little hedging, and no em dashes. It reads the rendered page, and a page that drifts into filler fails the build.
On every change we drive the assessment flow end to end in the same browser engine that powers mobile Safari, and a failure blocks the merge. We check layout and per-device rendering separately across four device profiles.
This site publishes an accessibility statement, which makes conformance a claim we have to keep, not an aspiration. We measure contrast and layout when the design changes, including on the dark sections, where it’s easiest to get wrong.
One of our checks was
lying to us.
A check is only evidence if it’s capable of failing. In August we added one that wasn’t, and it looked completely ordinary.
Fourteen pages on this site quote industry figures, like typical no-show reductions and typical conversion lifts. Those aren’t our results, so each page has to carry a line saying so. We wrote a rule to enforce it: every page quoting a figure must render that disclaimer. The rule passed.
Then we deleted the disclaimer and ran it again. It still passed. The rule searched each page’s source for the disclaimer’s name, and the import line at the top of the file, left behind when we removed the paragraph, was enough to satisfy it. The check had been decoration from the moment we wrote it. Every run of it had been green, and green had meant nothing.
It now asserts the rendered paragraph, and it fails from either page. We found it because breaking a new check on purpose, before trusting it, is part of writing one here, not a review step someone might skip. Nothing about that rule looked wrong, and that’s exactly why the practice exists.
A check can also sit
where the risk isn’t.
In the same week, a one-word change to a button label broke the form that starts an assessment on this site, on every device profile. The tests that would have caught it existed and ran. They just ran in a job that couldn’t block the change, so the checks that could block it stayed green and the break shipped to a branch believing itself healthy.
Coverage in the wrong place reads exactly like coverage. The functional browser tests now block a merge, and the page and the test that drives it share the button’s label, so the two can’t drift apart again.
We’re telling you this because it’s the more useful half of the story. Any firm can show you a passing pipeline. What tells you whether the pipeline means anything is what happened the last time it was wrong.
What we don’t claim.
An evaluator finds all of this in the first technical session anyway. Volunteering it costs us nothing, and it’s the only reason the rest of the page is worth reading.
A small firm promising 24/7 availability is making a promise it can’t keep, so we don’t make it. Our care plans quote response times in business hours. Outside them, we design for bounded consequence: the failure modes that matter are the ones that lose or corrupt work, and we make those structurally difficult.
We build Apsis Line’s vendor connections as governed seams. A simulated seam says it’s simulated, a seam without a live connection refuses instead of pretending, and the platform never presents a simulation as live. None of it has run against a live Encompass instance yet. That starts with the first lender.
Policies written, scope set, Type I targeted. We’re not SOC 2 certified and we don’t describe ourselves as compliant. Ask and we’ll tell you exactly which stage the work is at.
You won’t find a conversion lift or a time-to-close reduction on this site. The figures that do appear are industry ranges, and we label them that way. When a real engagement produces a number we can stand behind, it’ll arrive with its method.
Things you can ask to see.
- The checks themselves: their definitions, and the history of every time we changed or added one, with the defect that prompted it.
- The rendered-copy snapshot: every word this site shows, as committed text, alongside the pull request that last changed it.
- The security and data posture for Apsis Line: credential scope, tenancy isolation, and where the SOC 2 work actually stands.
- Where our coverage is thin: we keep that written down too, and it’s a shorter conversation than pretending otherwise.