Security and ownership
Make It Happen builds systems that run in the client's own accounts, with role-based access control, two-factor authentication, row-level permissions and an audit trail of every state change. Code ownership is a term of the agreement, named in the proposal. We claim no certification.
Handing a vendor your origination logic, your commission rules or your patient records is not a small decision, and a studio that answers it with a badge on a page has not answered it. So here is the posture stated as mechanism: where the system runs, who can reach it, what is written down, who owns the code, and what happens to all of it if we stop existing. Where we claim nothing, we say so.
A certificate is issued by an auditor. This is the mechanism.
Access is role-based, and the permission is per feature rather than per person, edited from a panel instead of from the code. Sign-in carries two-factor authentication. Rules run at the row, so a record is visible only to whoever it belongs to — not hidden in the interface, enforced where the data is read. Every state change is written to an event history: what changed, who changed it, when. We name no certification, because a certificate is issued by an auditor against a scope and a date, and not by a studio about itself. What a studio can build is the part an audit examines: the audit trail, the permission model, and the documentation that explains both.
The system runs in your accounts, not ours.
Every account the system depends on is opened in your name and billed to you: the database, the hosting, the mail sending, the analytics. We hold collaborator access at the level the work needs, and that access is a switch you own. Nothing is held hostage behind a login only we have, and your customers' records do not sit in a studio-owned account beside another company's. When the relationship ends you remove our access and the system keeps running, because it was never running anywhere else.
The old system is integrated at a documented boundary, not replaced by surprise.
We do not ask you to throw out the system your business already depends on. We integrate against its documented interfaces and, where it can emit them, webhooks. Where it cannot, we read on a schedule through a boundary that is read-only by default, so an integration cannot corrupt the records it is reading. Before any of that is coded, the mapping is written: which fields move, in which direction, how often, which identifier is the one that decides, and what happens to a row that fails validation. Where a system has no interface at all, we say so and scope the manual path instead of pretending otherwise.
Nothing you operate depends on this studio still existing.
It is a fair question to ask a studio of two partners with no separate delivery team, and the answer is structural rather than reassuring. The system runs in your accounts under your billing, so nobody has to renew anything on your behalf. The code lives in a repository you own from the first commit, not from the day of handover. It is built on documented interfaces and widely used tooling, so the pool of engineers who can pick it up is large. There is no proprietary layer of ours sitting in the middle of it. The foundation we reuse is process and generators on our side; what ships to you does not depend on it to run.
Patient data and borrower data change the design, not just the paperwork.
When the records are patient records or borrower files, the constraint is designed in from the start rather than added afterwards. Who can read what is decided per role and per field, so whoever books an appointment does not open a clinical note, and whoever chases a payment sees a balance without seeing the underwriting file. Retention is explicit: what is kept, for how long, and what is deleted or anonymized when that period ends — written into the schema instead of left to whoever remembers. Opening an individual record is logged, so the question of who read this has an answer. An automated agent is given the narrowest boundary of all: it reads through the same permission model as a person, under an identity of its own, scoped to the tables and fields its task needs, with writes limited to what it is allowed to change and an escalation to a person for everything else, and every exchange logged for review. What is not claimed: we are not your compliance advisor, we certify nothing, and we do not sign off on whether your process meets a regulation. We build the mechanism and the evidence; your counsel or your auditor judges it.
You own what you paid for.
The agreement names it in writing before anyone starts.
Whatever the agreement says, the handover is the same: architecture and data model, the permission model and what each role can reach, the runbook for the routine operations, how to deploy, how to restore, what breaks first under load and what to do when it does, and the decisions that were made with the reason for each. The test is not whether the documents exist. It is whether an engineer who has never spoken to us can read them and run the system. They are written during the build, not assembled in the last week.
Questions buyers actually ask
Who owns the code you write for us?
It depends on the agreement, and the proposal names the shape in writing before you sign. Whichever one applies, the handover is the same: the documentation to run the system without us.
Where does our data actually live?
In accounts opened in your name and billed to you: the database, the hosting, the mail sending, the analytics. You pick the region where the account allows it. We hold collaborator access at the level the work requires. Your records never sit in a studio-owned account beside another company's, and revoking our access does not stop the system.
What happens to the system when the contract ends?
You remove our access and the system keeps running, because it was already running in your accounts. You keep the repository, the documentation and the operating runbook. Where we retain a platform under a licence, the end terms are in the same agreement: what continues, for how long, and how an export is produced.
Do you have a security certification?
No, and we will not imply one. A certificate is issued by an auditor against a scope and a date, not by a studio about itself. What we build is what an audit examines: role-based access control, two-factor authentication, row-level permissions, an audit trail of every state change, and the documentation describing all four.
Who on your side has access to our production system?
The two partners, and nobody else. There is no separate delivery team and no subcontractor holding a key. Agents write code under our direction; what reaches production is reviewed and deployed by one of us, from a named account with two-factor authentication. You can list every access in your own account and revoke it without asking.
How do you stop an AI agent from reading data it should not?
The agent gets its own identity and goes through the same permission model as a person, with no service key that bypasses the rules. It is scoped to the tables and fields its task needs, read-only unless a write is part of the task, and blocked from whole categories of record. Every call is logged.
The possible part of the impossible.
If you have an idea that shouldn't work, bring it. We will tell you which part is genuinely impossible and which part is only hard. Most of it is the second one.