Independent architecture review for security and reliability

A written, independent opinion on your system: where it can be breached, where it will fail, and the smallest fix for each. I sell no cloud services, no tools, and no build work, so the review has nothing else to sell you.

A fictional order platform, marked up the way your design would be.
Cloud account: productionCustomersweb and mobileLoad balancerApp serverszone A onlyOrders databaseone instance, zone ABackupssame account and regionDeploy pipelinepermanent admin keyABCD
  1. AThe app servers and the database sit in one zone. A zone outage takes the whole service down. Spread the app across zones and add a standby database.
  2. BBackups live in the same account and region as the database. One stolen admin credential, or one regional failure, takes both. Copy them to a separate account with delete protection.
  3. CThe pipeline deploys with a permanent admin key. Anyone who can read the pipeline settings owns production. Use short-lived credentials scoped to deploy only.
  4. DNobody has restored these backups, and no recovery time or data-loss target is written down. You would learn both numbers during the outage.

Why independent

Many firms will review your architecture for free. The build work that follows pays for it, so the review has a reason to find a build. Mine is paid for by you. It can say the design is sound, that the fix costs nothing, or that the vendor's proposal is twice the size you need.

You also get something a free review rarely gives you: a written opinion that stands on its own in front of your board, your enterprise customer, your auditor, or your investor.

I do not build, operate, resell, or take commissions. The review is the only thing I sell.

What I review

Security and reliability fail at the same joints: identity, change, and recovery. Most teams review them separately, or review one and assume the other. I review them together, in the design and in the infrastructure code.

  • Identity and access: who and what can reach each system, with which credentials, for how long.
  • Boundaries and exposure: network paths, public endpoints, and what sits between an attacker and your data.
  • Data protection: encryption, secrets handling, and where sensitive data travels.
  • Failure domains: what a zone, region, dependency, or vendor outage takes down with it.
  • Recovery: backups, recovery time and data-loss targets, and whether a restore has ever been tested.
  • Change safety: the deploy pipeline, its credentials, and what stops an unsafe change.
  • Detection and response: logging, alerting, service level objectives, and who gets paged.

I look at code and configuration files, not only diagrams.

When I can help

  • After an outage, when customers want an explanation and the team wants to know what else is fragile.
  • When a vendor or an integrator has proposed a design and you want an independent read before you sign.
  • Before a build or a migration, while changing the design is still cheap.
  • Before an audit or an enterprise customer's security review.

Two ways to work with me

Everything starts with a short call. If the work fits, you get a one-page scope and a quote within two working days.

Architecture review

Two to four weeks, fixed scope. Full review, or security only, or reliability only.

I work from your design documents, infrastructure code, and read-only access under a role you control. The subject can be your running system, a design you are about to build, or a vendor's proposal. You receive:

  • A written review with findings ranked by severity, each with its evidence and the smallest fix.
  • A threat model with a data flow diagram your team can keep current.
  • A resilience assessment: how the system fails, and the recovery it can achieve against the recovery you need.
  • Findings mapped to the framework you answer to: SOC 2, ISO 27001, HIPAA, PCI DSS, NIST CSF, or CIS.
  • A readout call with whoever decides what gets fixed.

Monthly review

Monthly, cancel with 30 days' notice.

Systems drift. Send me design documents, pull requests, and vendor proposals as they come up, to an agreed number each month. I review each one in writing within an agreed turnaround. Once a month we spend an hour on the decisions coming next, and you get a short summary of what changed and what I flagged.

Your team owns the designs and the decisions. I review them. That keeps the opinion independent.

FAQs

Is this a penetration test?
No. I review the design and configuration. I do not attack the running system. If you need a penetration test as well, the threat model tells the testers where to aim.
Is this an audit?
No. I cannot issue a SOC 2 report or an ISO certificate. The review gives you written evidence of design review and risk assessment, mapped to your framework, which auditors and enterprise customers ask for.
What access do you need?
Read-only, through a role you create and can revoke. I never need production data or write access. The contract includes a security addendum that says so.
Do you fix what you find?
Your engineers do, from a remediation plan written for them. Staying out of the build keeps the review independent.
Is the monthly review a fractional architect?
No. A fractional architect owns your architecture and sells you hours. I review what your team designs, to an agreed number of requests, and stay independent of the result.
What does it cost?
The quote depends on how many systems, environments, and platforms are in scope. You get the number in writing before you commit to anything.