Technology consulting
Sooner or later something you have built gets examined. A customer’s security team sends a questionnaire. An auditor asks for evidence. A new engineer opens the repository and tries to understand it. We help you make the decisions now that make those moments uneventful.
Six areas, every engagement
| Ref | Area | What we look at |
|---|---|---|
| AC-01 | Access control | Who can reach what, and whether you can prove it after the fact. Roles, tokens, service accounts, and the ones nobody remembers creating. |
| DA-02 | Data handling | Where customer records actually live, how long they stay, and who can read them. Row-level policies, backups, and what leaves your systems. |
| CH-03 | Change management | How code gets from a laptop to production, and what stands between a bad change and your customers. |
| MO-04 | Monitoring | What you would actually see at 3am if something went wrong, and whether anyone would be looking. |
| VE-05 | Vendors and dependencies | The risk you inherit from every service you sign up for and every package you install. |
| BC-06 | Continuity | What happens when a provider goes down, how fast you come back, and who makes the call. |
These are the same six areas whether we are reviewing something you already run or building something new. They come from the audit side of the table, which is where this practice started.
Services
One to three weeks, fixed scope
We read everything, then tell you what actually matters.
What this involvesA few days, start to finish
Set the project up so the review is boring later.
What this involvesMonthly, scaled to what you need
We build alongside you, with the review discipline built in.
What this involvesMonthly retainer
A standing technical partner who already knows your system.
What this involvesHow we work
Thirty minutes on what you are building and what is worrying you. If we are not the right help, we will say so and point you somewhere better.
What we will look at, what we will deliver, what it costs, and when it is done. A fixed number, agreed before any work starts.
We read, we build, or both. You see progress as it happens rather than at the end, and you can change direction while changing direction is still cheap.
Findings, decisions, and reasoning written down in your repository. The goal is that your team can carry it forward without us in the room.
Who you work with
defthat is led by Dillon Frolek. The day job is IT analysis and running SOC audits, which means the work here is shaped by having sat in the seat where somebody has to produce the evidence and it is either there or it is not.
That background changes how the building goes. Access rules get written down as policy instead of scattered through the code. Decisions get a paper trail while they are still fresh. It is not slower, it just means the awkward questions have answers ready when they arrive.
We use AI-assisted development heavily and openly, because it is genuinely how the work moves fast now. It does not change who is accountable for what ships.
Free tool
Answer a few questions about what you are building and get a configured .claude/ folder, a CLAUDE.md written in your own domain language, and a starting roadmap. Free, no account needed. It is a useful head start, and it is a fair sample of how we think.