An independent architecture review of your software, in one to three weeks.
I review your system, code, data and AWS setup against where the business is heading. Then I tell you plainly what will hurt first and what to do about it, in a written report your team and your board can both read.
Remote across Australia and New Zealand. On-site in South East Queensland.
When a review is worth it
Before a decision that’s expensive to reverse. A review costs a few weeks; finding the same problems after you’ve committed costs a lot more.
- You’re about to raise, sell or sign an enterprise customer, and want to know what technical due diligence will find before someone else does.
- The platform has grown faster than its design. Releases are slower, incidents more frequent, and nobody can say exactly why.
- You’re weighing a rebuild against fixing what you have.
- You’ve inherited a codebase from an agency, a contractor or a team that has moved on.
- You’re moving to AWS, or rethinking how you use it, and want the design checked before the bill grows with it.
- Your product has started handling money or financial data, and you want to know whether it was built for that.
What the review covers
We agree the scope up front. If one part of the system is what worries you, the review concentrates there.
System design
Service and domain boundaries, how data flows between them, what runs synchronously and what doesn’t, and where a failure in one part takes another down with it.
Data and correctness
Data models, tenant isolation, transactions, and whether a retry or a duplicate request can corrupt state. This matters most when the system handles money.
Code and delivery
Structure, tests where they count, code review practice, CI/CD and how a change actually gets to production.
AWS and infrastructure
Account structure, IAM, networking, infrastructure as code, observability and where the cost is going.
Security
Authentication and access, secrets, sensitive data in logs, and exposure through third-party services.
Fit for your team
Whether your team can maintain the design they have, and what they’d need to keep it healthy as you grow.
How the review runs
Fixed scope, a fixed timeline and a quote before we start.
Scoping call
We agree the questions the review must answer, what’s in scope and who I need to talk to. You get a fixed scope and a quote.
Access and interviews
Read-only access to the repositories, cloud accounts and any documentation, plus short conversations with the people who built and run the system.
Analysis
I read the code and infrastructure and trace the critical paths end to end, such as sign-up, billing or a data import, checking what the system actually does against what everyone believes it does.
Written report
What’s working, the risks ranked by impact, and a recommendation for each one. The summary is written for founders and boards; the detail is written for developers.
Walkthrough
I take your team through the findings, answer questions and help turn the top items into a plan.
If you want help acting on the report, it can lead into a design and build or a fractional engagement. There’s no obligation either way. Fractional CTO and tech lead
What I bring to a review
I’ve spent eight years living with the consequences of architecture decisions on platforms that move real money. A review from me is grounded in what breaks in production, not in a checklist.
Property & channel management platform
On Homhero I assessed a live legacy system and planned its replacement while it kept serving customers: the same judgement a review asks for.
- Designed the serverless platform (DynamoDB, Lambda, EventBridge, CDK) while the legacy PHP system stayed live.
- Set the rebuild path to a TypeScript NestJS engine; error reporting cut reported bugs by 50%.
- AWS Lambda
- DynamoDB
- EventBridge
- Cognito
- Angular
- Ionic
Trust accounting SaaS platform
Homtrust taught me where financial systems fail: concurrency, retries and reconciliation. Those are the first things I check in any platform that handles money.
- Owned the double-entry ledger, with ACID online mutations and dedicated ledger processors with dead-letter handling.
- Idempotency keys and unique constraints so a double-submit or crash can never double-debit a ledger.
- TypeScript
- NestJS
- GraphQL
- PostgreSQL
- MikroORM
- AWS CDK
Questions I’m often asked
What do you need from us?
Read-only access to code and cloud accounts, whatever documentation exists, and a few hours of your team’s time across the review, mostly in short interviews.
Is this a security audit or penetration test?
No. I review security as part of the architecture, including access, secrets and how sensitive data is handled, but I don’t run penetration tests. If you need one for compliance, the report will say where to focus it.
Who is the report for?
You. It’s written to be shared with your developers, your board or an investor. The summary doesn’t assume a technical reader; the findings do.
Other ways I help
Want an outside view before a big decision?
Tell me what the decision is and what worries you about the system. I’ll suggest a scope for the review.