A family of software products for modern work.

These four products are ours. We designed them, built them, run them and pay for their mistakes. Nobody briefed us, so every decision below was ours to get wrong. For each: the problem it solves, the decision that separates it from the obvious version, and who it is for.

EVERJUST.APP: a business operating system that is yours, not a seat in ours

The problem. Most companies do not run on one system. They run on a stack of them, joined by exports, spreadsheets and one person whose real job has quietly become reconciliation. Each tool is defensible on its own. The seams between them are where the work disappears.

EVERJUST.APP is a branded business operating system: 34 integrated apps, so the work that normally crosses tool boundaries stays inside one system instead of becoming five copies that drift apart by Thursday.

The design decision. The obvious way to build a platform like this is multi-tenant. One application, one large database, a tenant column on every row. It is cheaper to run, simpler to upgrade, and what almost everyone does. We did the other thing. Each customer runs on their own database rather than a shared tenant. The isolation boundary is a database, not a filter in a query.

That choice costs us. Upgrades become a fleet exercise instead of one deploy, and operations are heavier by design. What it buys is a system that is genuinely the customer's: it can be extended without first asking whether the change is safe for every other company on the machine, and there is no shared table their data has to be disentangled from later. The branding follows the same logic. The software carries their name, not ours.

Who it is for. Companies that have outgrown a drawer of point tools and want one system of record with the connective work already done. Not for a team that needs one narrow application. If the answer is a single tool, buy the single tool.

CustomAgents: an agent with a real working identity

The problem. An AI agent that lives inside a chat window cannot be addressed. Nobody can copy it on a thread. Nobody can call it. It has no presence where work actually arrives, so every useful task turns into a bespoke bridge someone has to build and then maintain.

CustomAgents gives an agent its own email address, its own US phone number and its own Slack profile.

The design decision. The obvious approach is a bot user in one workspace, or an API other systems are expected to call. Both make the agent a destination: something you go to, in a tool you adopted first. We inverted it. The agent gets real endpoints on the channels people already use, so nobody changes how they work. They get a new address that happens to be answered by software.

The second decision matters as much. Every agent runs in draft mode or automated mode. An agent that composes and waits for a person to send is useful on the first day and safe on the first day, because the worst failure is a bad draft somebody deletes. Moving to automated is a decision you make after watching the drafts, when the work has become boring enough to trust. Full autonomy by default spends trust before it has been earned.

Who it is for. Teams that want an agent doing real work inside the inbox, the phone line and the channel they already have. Not for anyone shopping for a website chat widget.

Custom Domain: the worst onboarding step, handled

The problem. Every platform that lets customers bring their own domain hits the same wall. The instructions are correct and the customer still fails: wrong record type, a proxy in front of it, a registrar interface that names everything differently, propagation that looks exactly like a bug. Then certificates, renewal and edge routing. It is a support queue with a product attached.

Custom Domain handles managed domains, DNS detection, verification, HTTPS and edge routing that users never have to touch.

The design decision. The obvious version is a documentation page and a Verify button. That puts the burden of understanding DNS on the person least equipped to carry it, then blames them politely when it fails. We moved the correctness into the service instead. It detects what is already configured, verifies it, provisions HTTPS and wires the routing.

The less visible decision is the one about failure. The service is built to know where a domain actually stands, so that when something is wrong it can say what is wrong. That sounds like plumbing, but it is the difference between a support answer that names the problem and one that begins with "have you tried waiting". Diagnosis beats reassurance, and it is the only version of this that shrinks a support queue instead of feeding it.

Who it is for. Product teams shipping something customers put their own brand in front of, and teams whose support queue is full of registrar screenshots.

FaceSmash: face authentication that never receives your face

The problem. Passwords, and then the usual answer to passwords, which is to upload a picture of your face to a vendor. That trades one liability for a worse one. A leaked password can be changed by the person it belonged to. A leaked face cannot.

FaceSmash is a passwordless face-authentication SDK with real-time liveness detection, built so that raw biometric data stays in the browser.

The design decision. The obvious architecture is server-side. Capture frames, upload them, compare against a stored template, return yes or no. It is easier to build, and it makes the vendor a permanent custodian of the most sensitive data a person has. We took the constraint instead: raw biometric data does not leave the browser, which means the liveness check has to run there, on the device, in real time.

Harder engineering, and it closes doors on purpose: anything that would depend on a central store of faces is unavailable to us by construction. Still the right trade. A breach cannot expose data that was never sent, and no subpoena, acquisition or change of ownership can turn a database we do not hold into a risk for the people who logged in.

Who it is for. Teams that want a fast, passwordless login and do not want to become responsible for other people's biometrics. Not for one-to-many identification across a population. That is a different product with a different risk profile, and not the one we built.

The pattern underneath all four

Each had an easier version available, and in every case it made the promise slightly untrue. Own database instead of a tenant column. Real addresses instead of a bot user. Correctness in the service instead of in the documentation. In the browser instead of on our servers. The harder architecture is worth it exactly when it is the one that makes the claim honest.

Client work gets the same standard. Enterprise builds happen in your cloud and your repositories from the first commit, with the architecture settled before anyone writes feature code. Feasibility answers whether a product should exist at all, before an engineering budget is committed, and a do-not-build is a legitimate result with the reasoning shown. A storefront rather than a platform is what the Service Configurator is for: configured and bought in the browser, no meeting required. Growth runs as a flat monthly program with a written report every month.

Every engagement is fixed-scope and priced in public on the store. No rate card, no billable hours, no proposal cycle. If you would rather talk first, contact us or book a time.