The questions worth asking first

Do you use AI to write my code?

Yes, and I will tell you where. AI is very good at the parts of programming that are pattern and volume: boilerplate, transformations, the fourth variation of something you have already written three times. That is real leverage and pretending otherwise would be posturing.

What it is not is the part that decides what your system should do. It is a prediction machine. It produces the most probable next thing, which is not the same as the correct thing, and it is confidently wrong in exactly the places a system fails quietly. The data model, the failure cases, the security boundaries, and the review of every line before it ships are mine.

There is a self-interested reason for that line, and it is worth saying out loud: a skill you stop using is a skill you lose. The judgment you are hiring me for is the one thing I cannot afford to outsource, so I do not.

Does my business data go into an AI prompt?

No. What an assistant sees is code and structure: table shapes, column names, the logic being written. It does not see the rows that flow through them, and it does not see your customers.

When realistic data is needed to build against, the default is synthetic. I generate records that match the shape and distribution of yours without being anyone. That is a stronger guarantee than stripping names out of real data, and on a dataset the size a small business has, it is also the only guarantee that holds up.

Why synthetic rather than anonymized?

Because anonymization is a higher bar than it sounds, and most of what gets called anonymized is not. Removing names and hashing an email address is pseudonymization: reversible, and still personal data under every privacy regime that matters. Genuine anonymization has to survive three separate tests, that nobody can be singled out, linked across datasets, or inferred about.

The harder problem is quasi-identifiers. Not the name, but the combination of ordinary fields that turns out to be unique. The classic result is that a ZIP code, a date of birth and a gender identify roughly 87 percent of the US population, none of which is a name.

Small datasets make this worse rather than better. Two hundred bookings at one studio contain far more unique combinations than two hundred thousand at a chain, so the same technique that anonymizes a large dataset leaves a small one re-identifiable. Synthetic data sidesteps the entire question, because there is no real person in it to find.

What if real data is genuinely required?

Then it is minimized before it moves, and you know about it first. Direct identifiers come out, quasi-identifiers get generalized rather than kept exact, a date becomes a month and an address becomes a region. I take the smallest sample that answers the question rather than a full export.

And I will say plainly what that gets you: reduced risk, not zero. Anyone who tells you a de-identified extract of a small dataset is risk free is either not thinking about it or selling you something.

Will my data train someone else’s model?

No. Nothing of yours is submitted to a service that trains on its inputs. This is a question about which tools I use and how they are configured, not a promise about how carefully I will behave, which is why it is on the terms page rather than only here.

How do I know the database is actually locked down?

Every table has row level security switched on, and the posture is deny by default rather than allow with exceptions. The payment records table has no public policy at all, which is deliberate: there is nothing to accidentally relax later, because there is no rule there to weaken.

The key your website carries in a visitor’s browser can write one thing and read nothing. The key that can read everything never reaches a browser and never leaves my machine. That split is the property that makes the same system safe to hand to you, because anyone can read the JavaScript on a website and the security cannot depend on them not doing that.

What about secrets and credentials in the code?

No key, password, or connection string is committed. Configuration lives outside the code and is ignored by version control, and the code ships with obvious placeholders so an unfinished setup announces itself rather than failing silently in production.

This website is the example. It links out to Stripe rather than embedding it, holds no payment key of any kind, and shows an honest fallback rather than a broken button when something is unconfigured.

What happens to your access when we are finished?

It ends. Everything runs on your accounts and your infrastructure from the start rather than being migrated to you at the end, so handoff is a matter of changing the passwords and removing me. I keep no standing access to a system I have handed over, and there is no dependency on me that has to be unwound.

Are you SOC 2 or CMMC certified?

No, and I would be careful with anyone my size who says they are. SOC 2 is an audit performed by a licensed accounting firm that produces a report, not a status you can adopt. CMMC is a Department of Defense program for contractors holding federal contract information. Neither is something a solo practice self declares, and a badge without the report behind it is worth nothing to you.

What I can do is show you the controls and let you judge them, which is what the answers above are. If your procurement process needs specific controls evidenced, ask before we start rather than after, and I will tell you honestly whether I meet them.