One person builds this.
Here is 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 is not a promise about character. It is a set of checks that fail the build, that the person who wrote them cannot wave through, and that we test by deliberately trying to slip things past them.
You are not being asked to take our word for anything on this site. You are being asked to look at what would stop us from saying it.
What has to pass
before anything ships.
Named rather than counted, on purpose: a count goes stale the moment someone adds one and you cannot verify it from here. A name you can ask us to show you.
Every word this site shows is committed 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.
The built pages are scanned before they can ship for a former employer’s name, a competitor’s name, and internal project codenames. Where something is named on purpose, the exception is written down with its reason and printed on every run — so a judgement call stays visible instead of turning into a silence nobody revisits.
The load-bearing statements here are checked against the rendered page, not the source: that our compliance posture is never overstated 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 do not have.
The assessment flow is driven end to end in the same browser engine that powers mobile Safari, on every change, and it blocks the merge. Layout and per-device rendering are checked separately across four device profiles.
This site publishes an accessibility statement, which makes conformance a claim rather than an aspiration. Contrast and layout are measured when the design changes — including on the dark sections, where it is easiest to get wrong.
One of our checks was
lying to us.
A check is only evidence if it is capable of failing. In August we added one that was not, and it looked completely ordinary.
Fourteen pages on this site quote industry figures — typical no-show reductions, typical conversion lifts. Those are not 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 the paragraph was removed — was enough to satisfy it. The check had been decoration from the moment it was written. 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; that is 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 could not 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 button’s label is shared between the page and the test that drives it, so the two cannot drift apart again.
We are telling you this because it is 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 nothing and is the only reason the rest of the page is worth reading.
A small firm promising 24/7 availability is making a promise it cannot keep. What we design for instead is bounded consequence: the failure modes that matter are the ones that lose or corrupt work, and those are made structurally difficult before anyone talks about how fast someone answers the phone.
Apsis Line’s vendor connections are built as governed seams that report themselves as simulated until a lender provisions credentials, and the platform never presents a simulation as live. None of it has run against a live Encompass instance — that begins with the first lender.
Policies written, scope set, Type I targeted. We are not SOC 2 certified and do not describe ourselves as compliant. Ask and we will tell you exactly which stage the work is at.
You will not find a conversion lift or a time-to-close reduction on this site. The figures that do appear are industry ranges and are labelled as such. When a real engagement produces a number we can stand behind, it will arrive with its method.
Things you can ask to see.
- The checks themselves — their definitions, and the history of every time one was changed or added, 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 is a shorter conversation than pretending otherwise.