A live product, two regulated systems running inside American healthcare companies, and an AI call centre that replaced a staffed one. Different scales, same team building them.
A service for condo residents whose property manager has stopped answering them — about a leak, a heating failure, a pest problem, whatever it is. Built and launched end to end.
A maintenance ticket can be closed by the same person it embarrasses. A formal letter that cites the Act, names a date, and copies the board has to be answered by someone who can be held to it. The whole product exists to move a resident's problem from the first category into the second.
It's the clearest example of the whole job in one place: a real problem, a product designed around a legal and procedural reality rather than around a technology, and every layer — the drafting, the tracking, the payments, the public data — built and shipped by a team you can fit in one room.
If you want to see how we think about a problem before writing any code, this is the thing to go and read.
A working portal for a durable medical equipment distributor in the United States, handling Protected Health Information under HIPAA. The operational spine of the business: getting patients in automatically, keeping everyone informed, and assembling the paperwork that has to be right before anybody gets paid.
It has been through a US hospital's vendor audit and came out the other side. For a team this size, that is the part we would want to know about.
Patient data is the whole system, so the safeguards are not a layer added at the end — they shape how it was designed.
Worth being precise: nobody "certifies" software as HIPAA compliant — there is no such certificate to hold up. What exists is a system built to the requirements, operated correctly, and audited by the people relying on it. This one has been.
Nothing about it is technically exotic. What makes it difficult is that the rules are real: a billing packet is either complete and correct or it gets rejected, and a rejected packet is money and weeks. The system has to be built around how the process genuinely works, including the exceptions, rather than around a tidy version of it.
It is also the best proof that "no project is too small" does not mean small is all we do. Regulated healthcare data, automated end to end, audited by a hospital — built and maintained by the same people who will build you a one-page site.
A medical device manufacturer has to prove, continuously and on demand, that it is in control of its own quality system. This portal is where that happens: an ISO 13485 quality management system built into the software rather than maintained beside it, covering essentially everything the business is required to run.
It has been through an ISO 13485 audit. For a system of this size, that is the part worth knowing about.
Most quality software is a filing cabinet: it stores what a person did. This one has an AI agent that does the QMS work itself — the routine, procedural, deadline- driven tasks that otherwise consume a quality manager's week.
With the same rule that governs everything else we build in regulated environments: it escalates rather than guesses, and every action it takes is logged and attributable. In a quality system, an unexplainable decision is worse than no decision.
Compliance software fails in a specific way: it becomes a second job. Staff maintain the real process, then maintain the system that supposedly describes it, and the two drift until an audit finds the gap. Building the quality system into the software the business already runs on is what stops that happening — and it is the reason it holds up when someone comes to check.
A client was staffing a call centre to answer the same questions over and over. We replaced that operation with an AI system that picks up, understands what the caller actually wants, and resolves the routine calls without a person involved at all.
The point is not to remove people from the loop entirely. It is to stop paying them to answer the same eleven questions, and to make sure the calls that genuinely need judgement reach someone who has the full picture rather than starting cold.
Anything the system is not confident about escalates rather than guesses. That rule is the difference between a call centre that works and one that quietly annoys every customer you have.
The projects a lot of developers quietly decline because they're not big enough to be worth the admin. They're worth doing, they just shouldn't be priced like an agency engagement.
The fixed prices cover sites that present information and collect enquiries. The moment money or accounts are involved, the work changes shape:
None of that is harder than what we build for the medical distributor — it just can't be priced sight unseen. Fifteen minutes and you'll have a fixed number.
Not just onto this page.
One fixed number, agreed in writing before work starts. It only changes if you change the scope, in writing.
Full IP assignment on final payment. Repository, hosting, domain and keys in your name from day one.
A short note every week while the project runs. If a date is slipping you hear it early, not late.
If it's broken and we built it, we fix it free for a month after launch. No ticket haggling.
Hosting, domains, model usage and licences go on your accounts at cost. No reseller margin, no rent to stay online.
If the work needs a large firm behind it, or AI isn't the right fix, you'll hear that on the first call.
Whether it's a one-page site or a system that runs your operation, the first conversation is the same: tell us what's annoying you.