Skip to content
Comtau
Book a callBook a call

Software Architecture Consulting

Software architecture consulting for systems that have to keep working

Senior architects design the target architecture, document the decisions and stay to support implementation. Not a slide deck you have to translate yourselves - a system your team can build from.

For engineering and product leaders whose system is starting to push back: scaling limits, slow delivery, fragile integrations, or a SaaS platform that needs to hold more tenants than it was built for.

Talk to an architectSee how we work
  • Architecture-first
  • Hands-on implementation support
  • ADRs & C4, not slides

Powered by Comtau Inc.

  1. PersonCustomers
  2. ContainerWeb application
  3. Decision in focusCore services
  4. DatastorePrimary database
Illustrative C4-style container sketch. A full engagement produces a documented, buildable system - not just a diagram.

Problems we solve

Symptoms of an architecture that no longer fits

These usually show up as delivery or scaling problems long before anyone calls them architecture problems.

  • Scaling limits

    You seeA capacity conversation before every big launch or funding round.

    UnderneathThe system holds up at today’s load but visibly strains at the next milestone.

  • Slow delivery

    You seeEstimates that keep growing for work that looks the same size.

    UnderneathEvery feature takes longer than the last one to ship safely.

  • Fragile integrations

    You seeDeploys that need to be coordinated across teams “just in case”.

    UnderneathSystems are wired together directly, so one change breaks another team’s work.

  • Unclear system boundaries

    You seeThe same logic maintained in two places, quietly drifting apart.

    UnderneathNobody can say cleanly which service or team owns a given piece of behaviour.

What we design and review

Architecture consulting services

Six areas, each ending in a decision you can build from - not a recommendation to interpret.

01Architecture design

A target architecture for a new system or a major new capability

Target architecture · Architecture decision records

02Modernization & migration

The path from an existing system to a target architecture

Migration roadmap · Sequencing plan

03System & application design

Service boundaries, data ownership and integration design

Boundary map · Interface contracts

04Scalability & SaaS architecture

Whether the system will hold under the load and tenancy it needs

Scalability assessment · Bottleneck list

SaaS scalability
05Cloud & integration architecture

Infrastructure, deployment topology and third-party integration design

Infrastructure architecture · Integration plan

06AI systems architecture

How AI/LLM components fit the rest of the system

AI architecture brief

AI architecture consulting

How we work

Discovery, decisions, then a system your team can build

Architecture-first means the decisions are made deliberately and written down, not discovered halfway through a sprint.

  1. 01

    Discovery

    Understand the current system, its constraints, and what the business actually needs from it.

    • Current-state assessment
  2. 02

    Decisions

    Make the architecture decisions explicitly, with the trade-offs and the reasoning attached.

    • Architecture decision records
  3. 03

    Target architecture

    Model the target system at the level of detail a team can actually build from.

    • Target architecture (C4)
    • Migration roadmap
  4. 04

    Implementation support

    Stay hands-on through the build, working alongside your engineers or agency.

    • Implementation guidance
    • Risk list

Architecture thinking, shown

From current state to target, one recorded decision at a time

A generic example of how we document architecture: the current container view and its friction points, the decision record that addresses them, and the target view it produces.

Current → decision → target

Illustrative example · not client material

01 · Current state (container view)

    • SPAWeb app
    • ContainerMonolith API1
    • DatastoreShared database2
    • ExternalPayment provider3
  • 1Every team ships through one deployable.
  • 2Reporting and checkout compete for one database.
  • 3Payments are called synchronously inside the checkout request.

02 · Architecture decision record

ADR-007 Decouple billing from checkout

Accepted
Context
  • A slow payment response blocks order creation, and billing load hits the same database as checkout.
Options
  • A · Keep synchronous calls; add timeouts and retries
  • B · Extract billing behind an event queue
  • C · Decompose the monolith into microservices
Decision
  • B. Extract billing with its own datastore; keep the rest as a modular monolith for now.
Consequences
  • + Checkout no longer waits on the payment provider
  • + Billing deploys and scales on its own
  • − Order status must handle “payment pending”
  • − One more component to operate and monitor

03 · Target state (container view)

    • SPAWeb app
    • Modular monolithCore application
    • MessagingEvent queue
    • ContainerBilling service
    • ExternalPayment provider
    • DatastoreCore database
    • DatastoreBilling database
  • Changed by ADR-007. Everything else stays where it is until a decision says otherwise.
Illustrative example. Current state (container view): Every team ships through one deployable. Reporting and checkout compete for one database. Payments are called synchronously inside the checkout request. Decision ADR-007: Decouple billing from checkout. Target state (container view): Changed by ADR-007. Everything else stays where it is until a decision says otherwise.

After the decision

How an accepted ADR becomes implemented architecture

A decision record is an input, not the finish line. Each accepted ADR is decomposed into bounded work, and the result is checked against the decision it came from.

Architecture consultingImplementation, by your team or Comtau

  1. Accepted ADR

    The decision, the options rejected and the consequences, approved before anything depends on it.

    Output: Architecture decision record

    Gate: Approved by your technical owner

  2. Decomposition

    Split the change into bounded units, each stating what it may touch and how it will be checked.

    Output: Scoped implementation plan

    Gate: Order and scope agreed

  3. Implementation

    Implementation, by your team or Comtau

    Your engineers build with Comtau’s guidance, or Comtau implements units with AI-assisted engineering under human control.

    Output: Implemented units

    Gate: Execution stops if a unit outgrows its scope

  4. Conformance check

    Implementation, by your team or Comtau

    Tests, plus an independent review of the result against the architecture it was meant to implement.

    Output: Verification evidence per unit

    Gate: Checks pass; reviews have no blocking findings

Have an architecture decision that shouldn’t be made by guessing?

Tell us what the system needs to do next. We’ll tell you plainly whether this is a design engagement, a review, or something else.

Talk to an architect

Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.

What you get

Architecture decisions you can hand to a team

Every engagement leaves you with artefacts, not just a conversation.

  • Target architecture

    The system you are building towards, modelled at context, container and component level

    C4-style architecture model

  • Architecture decision records

    Why each major decision was made, and what was rejected

    ADR set

  • Migration or modernization roadmap

    The sequence of change from the current system to the target one

    Phased roadmap

  • Risk list

    What could go wrong in the build, and what to watch for

    Risk register

  • Implementation guidance

    How the target architecture translates into day-to-day engineering decisions

    Guidance for your team or agency

When to bring one in

Consultant vs in-house architect

The two are not competing options - most engagements end with the in-house team owning the architecture going forward.

Seniority available
External consultantSenior architect on demand, without a full-time hire
In-house architectDepends entirely on who you have hired
Time to impact
External consultantFast - brought in for the decision that needs to be made now
In-house architectSlower if the role or seniority still needs to be built
Cost model
External consultantScoped to the engagement
In-house architectOngoing salary and hiring cost
Continuity
External consultantBounded to the engagement, with a documented handover
In-house architectPermanent, as long as the person stays
Knowledge transfer
External consultantDeliberate: ADRs, models and guidance built for your team to keep
In-house architectHeld in one person unless it is written down

Bring in a consultant when

  • A major decision has to be made correctly the first time, and no one internally has made it before.
  • The team needs a second, senior opinion before committing months of build time.
  • You want the target architecture documented, not just decided in someone’s head.

SaaS architecture & scalability

Profile before you re-architect

Not every scaling problem is an architecture problem, and not every fix is microservices. We start by finding out which parts of the system are actually the bottleneck.

  • Traffic step-change

    A new customer, channel or launch pushes load well past what the system was tuned for.

    A single big account nearly takes the platform down.

  • Latency creeping up

    Response times degrade under load in ways that are hard to reproduce.

    Support tickets about “slowness” with no obvious single cause.

  • The monolith ceiling

    One codebase and one database now serve every team and every tenant.

    Every deploy risks every customer, every time.

  • Cost outpacing revenue

    Infrastructure spend grows faster than the customer base that drives it.

    A cloud bill that is hard to explain to the board.

What a SaaS scalability audit checks

Data layer

Whether the database design will hold under growth

Read replica / partitioning assessment

Caching

Where caching would remove load without adding fragility

Caching recommendations

Queues & async design

Whether synchronous calls are creating unnecessary coupling and load

Event-driven design options

Multi-tenancy model

How tenants are isolated, and what that costs at scale

Tenancy model assessment

Load testing

Whether the system has been tested against a defined service level, not just “it worked last time”

Load test plan against SLOs

Observability

Whether you can see a bottleneck before a customer reports it

Observability gaps

Cost (FinOps)

Where infrastructure spend is disconnected from actual usage

Cost review

Where SaaS systems usually strain

Generic reference, not a client system

  1. L1Edge & API

    CDNGatewayRate limits

    Typical bottleneck: Chatty endpoints and no per-tenant limits, so one account can saturate the API.

  2. L2Application services

    WebWorkers

    Typical bottleneck: Synchronous calls chained across services inside a single request.

  3. L3Async & queues

    QueueScheduler

    Typical bottleneck: Heavy jobs running inline instead of on a queue that can absorb spikes.

  4. L4Caching

    CacheRead models

    Typical bottleneck: Hot reads hitting the primary database on every request.

  5. L5Data layer

    Primary DBPartitionsReplicas

    Typical bottleneck: One database serving every tenant, every workload and every report.

Across every layer

  • Observability
  • Load tests vs SLOs
  • Cost per tenant
Typical bottleneck point to profile before choosing a re-architecture option.

Multi-tenancy

Choosing a tenancy model

Pooled, siloed and hybrid tenancy each trade isolation against cost and complexity differently.

  • Pooled

    Tenant isolation
    Lowest - tenants share infrastructure and, often, a database
    Cost efficiency
    Highest - resources are shared across all tenants
    Operational complexity
    Lower, until noisy-neighbour issues appear
    Best fit
    Many small tenants with similar usage patterns

  • Siloed

    Tenant isolation
    Highest - each tenant has dedicated infrastructure
    Cost efficiency
    Lowest efficiency - capacity is not shared
    Operational complexity
    Higher to operate at scale
    Best fit
    Large or regulated tenants that require strict isolation

  • Hybrid

    Tenant isolation
    Tiered - isolation matches tenant size or plan
    Cost efficiency
    Balanced against the isolation each tier needs
    Operational complexity
    Highest to design, more maintainable to run
    Best fit
    A mixed customer base spanning small and enterprise tenants

Re-architecture options, chosen after profiling

  • Multi-tenant design

    Choose or change the tenancy model so isolation matches what each tier of customer needs.

  • Data partitioning

    Split data by tenant, workload or time so one database stops carrying everything.

  • Infrastructure & autoscaling

    Scale the layers that are actually saturated, with cost tracked against usage.

  • Strangler-fig decomposition

    Extract services one boundary at a time, only where profiling shows a real need.

Situation → engagement

  1. You don’t yet know where the bottleneck is

    Scalability audit

    Bottleneck list and re-architecture options

  2. You know the bottleneck and need it fixed safely

    Remediation design and support

    Target architecture, ADRs and a sequenced plan

  3. Growth is steady and you want someone watching

    Ongoing architecture advisory

    Regular reviews against load, cost and SLOs

Scope a scalability audit

Why Comtau

Senior architects who stay for the build

Architecture is the core of what Comtau does, not a pre-sales step for a development contract.

  • Architecture-first

    Decisions are made deliberately, written down as ADRs and C4 models, and revisited when the context changes.

  • Hands-on depth

    The same people design the architecture, review the code against it and support the team implementing it.

  • Decisions carried into delivery

    From diagnosis to implementation, including systems with AI and LLM components. When Comtau builds, each unit is scoped from an ADR, independently reviewed and closed with evidence.

Related services

  • Software Architecture Review

    You have an existing system and want an independent assessment, not a new design.

    Learn more

  • AI Architecture Consulting

    The system you’re designing is built around LLMs, agents or a retrieval layer.

    Learn more

  • Technology Strategy Consulting

    The question is bigger than one system - it’s the multi-year technology roadmap.

    Learn more

  • Technical Debt Assessment

    The system works, but years of shortcuts are now slowing everything down.

    Learn more

FAQ

Software architecture consulting questions

What does a software architecture consultant actually do?

They assess the current system, make the architecture decisions a growing system needs, document them as ADRs and a target architecture, and stay to support the team that builds it.

How is this different from a software architecture review?

A review assesses an existing system and produces findings and a roadmap. This page is about designing or evolving the architecture itself. If you want an independent assessment first, see Software Architecture Review.

Do you also implement the architecture, or only design it?

Both, by design. The same senior people who make the architecture decisions can stay hands-on through implementation, working alongside your team or agency - that continuity is the point.

What do you produce for a SaaS scalability engagement?

A scalability assessment across the data layer, caching, queues, tenancy model, load testing and cost, followed by re-architecture options and a sequenced remediation plan.

Do you work with our in-house engineers?

Yes - that is the most common setup. Architecture decisions are made with your team, not handed down separately, so the people building the system understand why it is designed the way it is.

How is the engagement scoped and priced?

Engagements are scoped to a specific architecture question or system, not sold by the hour. See Fractional CTO cost & engagement models for how Comtau structures engagements.

Do you have a point of view on microservices?

Yes: it is not the default answer. We profile the system first, and say plainly when a modular monolith, a data-layer fix or a caching change solves the actual bottleneck more safely than a decomposition project.

Get a senior architect looking at this with you

Tell us what the system needs to do next. We’ll help you work out whether this is a design engagement, a review, or something else entirely.

Talk to an architectSee Software Architecture Review

Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.

What happens next

  1. 01You describe the system and the decision ahead of it
  2. 02We identify what needs to be assessed or designed
  3. 03We define the useful next engagement