Know where your technology stands before you commit the next budget.

Worth doing before a decision that is hard to undo.

An assessment pays for itself when a large commitment is coming and nobody inside the company can say with confidence whether the current systems will hold up.

Good timing

• Before a platform migration or a major rebuild.
• Before your first serious AI initiative.
• Before replacing a core vendor or renewing a large contract.
• During acquisition diligence or a post-merger integration.
• Ahead of a funding round or an annual budget cycle.
• When technology spending keeps rising and results don’t.

When it isn’t the right tool

If you already know what to build and simply need more engineers, hire engineers. If the question is narrow, such as a second opinion on one vendor, a shorter conversation may be enough. I’ll tell you which on the first call.

What I look at, and what you get back.

Areas reviewed

• Architecture, integrations, and data flows.
• Scalability, reliability, and security exposure.
• Vendor contracts, implementation quality, and build-or-buy choices.
• Data readiness for analytics, automation, and AI.
• Team structure, release process, and quality practices.

Deliverables

• A current-state review of your architecture.
• A gap and risk analysis, ranked by consequence.
• A prioritized roadmap: what to do first, what to defer, and what to drop.
• A summary written for your board or investors.

The report is written so your own team, or any partner you choose, can carry it out.

How the two to four weeks are spent.

1. Scope. We start with the decision you’re facing. I write a short scope covering the questions the assessment will answer, what is in and out, and the fixed fee.
2. Review. I read your architecture and documentation, look at systems and code where they bear on the questions, go through vendor contracts, and interview the people who run your technology day to day.
3. Findings. Each finding records the evidence, the consequence if nothing changes, a recommendation, and a condition that shows when it has been resolved.
4. Roadmap. Findings are ranked and sequenced into a plan your team can follow, whether or not I stay involved.

What I’ll need from you

• A sponsor who can make introductions and decisions.
• Read access to architecture documents, code repositories, and cloud or vendor consoles, as relevant.
• Key vendor contracts and a view of recent technology spend.
• An hour or so with each of the people who build and run your systems.

What a finding looks like.

Every recommendation in the report uses the same structure, so it can be checked later rather than argued about.

Finding 03 · Publishing platformPriority: High

Finding

The planned CMS rebuild will not fix the publishing delays it is meant to fix.

Evidence

Slow publishing traces to cache settings, a workflow queue limit, and image processing on the request path, plus a missing connection between the CMS and the syndication service. The platform itself has capacity to spare.

Consequence

The rebuild would cost six figures and take eight months or more, and editors would keep waiting in the meantime.

Recommendation

Put the rebuild on hold. Fix the configuration, build the integration, and revisit the platform question in twelve months with measured usage.

Acceptance condition

Approved articles go live within two minutes at peak volume, sustained for 30 days.