Software architecture consulting for systems that have to work.

Architecture is a set of decisions your team can execute.

Software architecture consulting means examining the way your product is structured and the constraints it must survive, then making the choices explicit. The useful output is a direction your team can check: what should be built, which parts can stay, where the risks sit and what evidence would change the recommendation.

A diagram alone does not settle those questions. A mobile application that must work without connectivity needs a different design from one whose users are always online. A video platform running on edge devices has a different cost model from central processing. A regulated product needs its approval requirements considered while the workflows are still being designed.

I work with founders, engineering leaders and product teams facing those decisions. Engagements are remote and available to clients worldwide, including teams in the US and UK. The operating constraints come from your business and users; they do not come from a preferred technology stack.

A new product, an inherited system or a costly next step.

You have an idea, but no buildable specification.

You know the problem and the intended users. You need the boundaries, data flows, integration requirements and delivery assumptions worked out before asking someone to build it. The scoping week turns that problem into an architecture, a written specification and a fixed quote for the proposed work.

Your team needs an independent architecture review.

The product exists, but changes are becoming harder, deployment feels fragile or responsibilities between components are unclear. A review examines the relevant code and operating evidence alongside the intended behavior. The aim is to identify the constraints that matter, so the next change addresses the cause.

You are weighing repair against a rebuild.

A rewrite can look attractive when nobody trusts the existing system. It also risks discarding decisions that still serve the business. I look for what can be retained, what needs a different design and which unknowns need investigation. If the system is already failing in production, the software project rescue diagnostic is the more direct starting point.

Written scope before a larger commitment.

The first engagement is a paid week at a fixed fee, agreed before work starts. For a new build, the established deliverables are an architecture, a written specification and a fixed quote. For a review, the deliverable is what the evidence supports in writing, including unresolved questions and the next step needed to answer them.

• The problem and constraints: intended users, critical workflows, deployment environment and the outcomes the system has to support.
• The technical direction: the relevant component boundaries, data movement and integration choices, with the reasoning behind them.
• The risks and unknowns: what has been established, what remains uncertain and where further evidence is required before a decision.
• A practical next step: a written scope for implementation where appropriate, or a handover your existing team can use.

The exact review boundary is agreed from your situation. One week cannot establish every property of a large platform. The point is to make the important decision tractable and to state the limits of the evidence clearly. A follow-on build is separately scoped, fixed price and milestone-paid against a written definition of done.

Decisions made under real operating constraints.

The humanitarian duty-of-care platform needed offline safety behavior for staff in conflict-affected regions. The published case describes offline panic alerts, movement-risk approvals and a system live since 2022. It is a useful example of architecture starting from a user's worst operating conditions.

The field-service ERP for a network of 7,000+ ATMs connected enterprise operations, mobile field work and a client portal with telemetry, surveys and audit reporting. Its relevance is the relationship between the software and the people maintaining machines across a distributed network.

The UAE telehealth platform went through health-authority certification and handover to the client's team. That experience informs how I approach approval and operations constraints. It is not a claim of US or UK regulatory certification. You can also read the architecture lessons from the certification process.

Questions that define a useful review.

Do you need access to our repository?

A new-product scoping week can begin with workflows and requirements. An existing-system review needs the relevant implementation and evidence to support technical findings. Share a short description first; the required access and review boundary can be agreed before the paid work begins.

Can our own team implement the findings?

Yes. Written reasoning is intended to be checked and used by your team. If the next step belongs with them, I will say so. If you want implementation support, that is scoped separately. For continuing technical direction, the main consulting engagement page also describes the advisory retainer.

What should we send first?

Tell me the decision you need to make, the deadline, what exists today and which constraint worries you most. A product outline, architecture diagram or concise account of the failure is more useful than a sales deck. If the central question is how to ship an AI feature, start with AI integration consulting.