Software architecture consulting and independent review
A bounded engagement that reads a system — one already running, or one still on a whiteboard — and returns a written architecture document: what the design holds up under, where it gives first, which option to pick, and what each choice costs to reverse. We advise. We do not need to be the ones who build what we recommend.
Who this is for
- Your system copes with today's load, someone senior has said it will not cope with next year's, and nobody inside the team can name which component gives way first.
- The team is stuck between two or three directions — rewrite or refactor, one datastore or another, buy the vendor or build it — and the argument has run out of evidence and turned into preference.
- An acquirer, an investor, or a large enterprise client is about to put an engineer inside your repository and your cloud account, and you would rather know what they will find before they find it.
- There is no code yet, only an architecture on a slide, and the cost of getting the data model or the tenancy boundary wrong is a year of rework you cannot afford.
What usually goes wrong
The problems this work exists to solve
Every option sounds reasonable when it is argued out loud
Verbal architecture debates are won by whoever is most fluent. We put each option through the same written comparison: the constraints it has to satisfy stated in numbers, its failure modes, the migration cost to get there, the operational burden afterwards, and the cost of backing out if it turns out wrong. Decision criteria are agreed and weighted before any option is scored, so nobody can retrofit the criteria to the answer they already wanted. The result is an architecture decision record per irreversible choice, including the options we rejected and why.
Nobody can say where the scaling ceiling actually is
"It won't scale" is not a finding. We build a capacity model from measurements: p95 and p99 per endpoint, write rate per table, row counts and index sizes, connection pool utilisation, queue depth and consumer lag, cache hit ratios. Then we project those to your target load and identify the first binding constraint — in most systems we read it is database connections, a single writer, or lock contention on a hot row, not CPU. The document states each ceiling as a multiple of today's traffic, which is a claim you can test rather than an adjective you have to trust.
The cloud bill grows faster than the business does
A monthly total tells you nothing. We build a unit cost model — cost per tenant, per order, per thousand requests — and separate fixed platform cost from marginal cost per unit of work. That usually surfaces the same handful of causes: cross-AZ and egress traffic nobody accounted for, non-production environments running at production sizing, managed service tiers bought for a peak that no longer exists, and log or trace retention set once and never revisited. We then plot the cost curve at several multiples of current volume, because the architecture that is cheapest today is often the one that scales worst on price.
Build-versus-buy gets decided by whoever is loudest on the call
We cost both sides honestly. The buy case includes integration effort, the data you hand over, residency and sub-processor implications, contractual lock-in, and what exit actually costs. The build case includes maintenance, on-call, the compliance surface you take on by holding the data, and the opportunity cost of the engineers who will own it for years. We compare over a three-year horizon and, separately, on reversibility — a slightly worse decision you can undo in a quarter usually beats a slightly better one you cannot undo at all.
The last consultant recommended a stack that suited the consultant
We write recommendations so that any competent team can execute them, including one that is not us. Two rules keep that honest. First, the boring, widely-operated option wins unless there is a written constraint that rules it out — novelty has to be paid for by a requirement, not by interest. Second, your team's existing skills and the hiring market you actually recruit from are inputs to the decision, not afterthoughts; a design your team cannot staff is a design that fails quietly. If we would be a plausible vendor to build what we recommend, the document says so in plain terms.
Delivery is slow and the team is being blamed for something structural
Slow delivery is often architecture wearing a management costume. We review the delivery system alongside the code: CI duration and flakiness, how long a change waits for review, whether environments resemble production, how many teams have to coordinate to ship one feature, and how much of the week is lost to on-call. Then we trace the coupling back to its source — usually a shared database schema or a shared deployment unit that forces every team into the same release train. The finding names the structural cause and what changing it would cost, which is a different conversation from asking people to try harder.
Scope
What you actually get
The architecture document
The core deliverable. Context and the constraints we were given, current-state diagrams at system and container level, findings ranked by risk and by cost to fix, a target state, and the sequence to reach it. It is written to be read by an engineer and skimmed by a board, and it names the things that are wrong plainly enough to be actionable.
Decision records for the irreversible calls
One record per decision that is expensive to undo: context, the options considered, the decision, the consequences we accept, and the condition that would make us revisit it. These are the artefacts that stop the same argument restarting in six months when someone new joins and asks why.
Capacity and scaling model
A model with measured baselines rather than assumptions, showing the load at which each component becomes the constraint and what the next constraint behind it is. Written so your team can re-run it after they change something, instead of it going stale the day we leave.
Infrastructure cost model
Unit economics of running the system: fixed versus marginal cost, cost per unit of business work, and projections at multiples of current volume. Includes the specific line items driving spend and what each would cost to change, so cost becomes a design input rather than a monthly surprise.
Ranked risk register
Every risk with its likelihood, its blast radius if it lands, and the cheapest mitigation that genuinely reduces it — not the most thorough one. Risks we consider acceptable are listed too, with the reasoning, so that accepting them is a decision on record rather than an oversight.
Sequenced remediation plan
Work ordered by risk reduced per unit of effort, sized in bands of engineering weeks rather than false precision, with a first step that is deliverable on its own. It also lists what not to do: the tempting rewrites and platform migrations that would consume a year and move no risk.
Readout and Q&A record
A working session with your engineers and a separate one with whoever holds the budget, because the questions differ. Corrections and answers raised in those sessions are folded back into the final document, so the version you keep is the one that survived your team's scrutiny.
Technology
Technology options
We are technology-agnostic. These are the choices we reach for, and how the decision actually gets made.
What we ask for as evidence
We can review from documents and interviews alone, but the findings stay hypothetical and the document will say so. With telemetry and billing data the same findings become measured claims. Where access is restricted for good reasons, we record which conclusions are therefore unverified rather than quietly guessing.
Tooling we read the system with
The preference is always to read the telemetry you already have, because that reflects real traffic. Where a critical path is not instrumented, we may instrument a narrow slice for the duration of the review — and the absence of that instrumentation becomes a finding in its own right.
Decisions we are most often asked to settle
The default answer is the option with the smallest operational surface. Distribution, eventual consistency and self-hosting all have to be earned by a constraint that is written down. If we cannot state the constraint that justifies the complexity, we recommend against the complexity.
Formats the document uses
Format is chosen for whoever maintains it after us. A diagram your team cannot update is worse than no diagram, because it will be believed after it stops being true. Everything is delivered in text-and-source form that lives in your repository, not as slides.
How it runs
The shape of the engagement
- 01
Agree the questions before the work starts
We write down the specific questions the document has to answer and get them signed off. An unbounded review produces a document that is broad, polite and useless. Three sharp questions produce something a team can act on the week they receive it.
- 02
Gather access and evidence
Read-only access, telemetry exports, billing data, incident history, schema. We interview engineers separately from management, because the two groups reliably describe different systems, and the gap between those two descriptions is itself one of the more useful findings.
- 03
Reproduce the claims
We do not take the architecture diagram's word for it. We profile the slow path, read the query plans, check the instance sizes actually provisioned against what was believed, and replay load where it is safe. It is common to find at least one component behaving differently from how the team describes it — which is why we reproduce the behaviour rather than take the diagram's word for it.
- 04
Put options in front of the team, with numbers
A working session where we bring the candidate options and the evidence, and your engineers argue with both. This is deliberate. A decision your team helped reach gets implemented; one handed down as a recommendation gets quietly ignored after the invoice clears.
- 05
Draft, circulate, correct, then read out
The draft goes to your team for factual correction first — we would rather be wrong in a draft than in the version that reaches your board. Then the readouts, then the final document with the session's questions folded in.
- 06
Checkpoint once execution begins
A follow-up session a few weeks in, once the plan meets reality and produces questions the document did not anticipate. This is included in the engagement, not sold as a new one.
Engineering
Architecture, security and performance
The decisions that are expensive to change later, and where we stand on them.
Architecture
- Review time goes where reversal cost is highest
- We spend the engagement proportionally to how expensive a decision is to undo, not to how interesting it is to discuss. The data model, the tenancy boundary, the identity and authorisation model, and the choice of which system is the source of truth for each entity are the ones that are painful to change once there is production data. Frameworks, languages and deployment tooling can be replaced later at bounded cost. A review that spends its best days on framework choice and skims the data model has been done backwards.
- A service split is an organisational decision before it is a technical one
- Most proposals to split a system are trying to solve deployment coupling or unclear ownership. So we check where the coupling actually lives first — and it is usually the database, in shared tables and cross-schema joins. Splitting the code while keeping one shared database buys you every distributed-systems failure mode and none of the independence. Often the correct recommendation is enforced module boundaries inside a single deployable, with the build failing on a boundary violation, and a split only for the component that genuinely needs its own scaling or release cadence.
- Event-driven designs have to be earned by a requirement
- Event sourcing and CQRS are right where replay and an immutable audit trail are genuine requirements — payment ledgers, clinical records, anything a regulator will ask to reconstruct. They are the wrong answer when used simply as a way to decouple two teams. When we do recommend them, the document states the bill: idempotency handling in every consumer, a schema evolution policy for events, the operational work of managing consumer lag, and the fact that eventual consistency stops being an internal detail and becomes something the interface has to show the user.
- A target state without an incremental path is a wish
- Any target architecture we recommend comes with a first increment that ships in weeks and leaves the system working even if nothing after it is ever built. We reject target states that only pay off on completion, because two years is longer than most roadmaps survive intact. Where the change is large, the plan is a strangler sequence with a named seam, a routing strategy, and a defined period where both paths run and are reconciled.
- Rejected options are documented as carefully as chosen ones
- The most durable part of an architecture document is the list of what we considered and turned down, with the reasoning attached. Without it, every new senior hire reopens the same debate, and the team relitigates a settled decision with less context than the people who settled it. We also record the trigger that should reopen each decision — a load threshold, a regulatory change, a vendor's pricing move — so revisiting it becomes a scheduled event rather than an argument.
Security
- We work from data flows, not a questionnaire
- The security portion of a review starts by classifying what data the system holds and mapping where it moves, then drawing the trust boundaries it crosses. That produces a threat model tied to your actual design. A control checklist answered from a spreadsheet tells you what is documented; a data flow map tells you what is reachable, and those two answers are frequently not the same system.
- The question we answer is what one stolen credential reaches
- We review IAM roles and policies, service accounts, long-lived access keys, CI tokens, and the paths by which a human reaches production. Then we state the blast radius plainly: what a single compromised laptop or leaked pipeline token can read, write or delete before anyone notices. Least privilege is easy to claim in a policy document and rarely survives being traced through an actual role graph.
- Reducing regulated scope beats hardening everything
- Where card data, health records or identity documents are involved, the highest-value architectural finding is usually a boundary that keeps regulated data out of most of the system — a tokenisation vault, hosted payment fields, a segmented store with its own access path. Shrinking the number of components in scope for PCI DSS or HIPAA is cheaper, and stays cheaper, than applying enterprise-grade controls uniformly to a system that did not need to touch the data in the first place.
- Residency and jurisdiction get settled in the diagram
- Under the DPDP Act and GDPR, where data physically sits, which sub-processors touch it, where backups and read replicas live, and what leaves the region in analytics exports are all architectural properties. They are cheap to decide before the schema is written and expensive to retrofit once a system is multi-region and a queue is already replicating across borders. We check these early because a residency finding late in a review usually invalidates part of the target state.
- Findings are reported with severity, and not sold back to you
- You get security findings ranked by exploitability and impact, with the cheapest effective mitigation named — not a raw scanner export padded with informational noise. If we find something serious outside the agreed scope, we report it anyway. We also do not make remediation work by us a condition of the report; the fixes are written so your own team or another vendor can carry them out.
Performance
- A target load in real units, before any design work
- Nothing can be designed against the word "scale". We ask for numbers in your domain: orders per minute at peak, concurrent sessions during a live class, claims processed per overnight batch window, and the shape of the peak against the average. If nobody has those numbers, deriving them with your commercial team is part of the engagement, because a capacity model built on an invented figure is worse than no model at all.
- The first constraint is usually the database
- Before recommending anything with "distributed" in the name, we read the query plans, the slow query log, connection pool behaviour under peak, index coverage against actual predicates, and where an ORM is issuing N+1 queries behind a clean-looking interface. Indexing, pooling and pagination fixes costing days will often unlock several times the current load — and the proposed rewrite would have cost a year and shipped the same query patterns.
- Tail latency is what users actually experience
- We measure p95 and p99 per endpoint and per downstream dependency, never averages. A healthy median sitting next to a p99 an order of magnitude worse is a signature, and it almost always points at one of three things: a queue that saturates at peak, a retry policy amplifying an already-degraded dependency, or a cold cache path with no timeout. Averages hide all three, which is why they appear in so many dashboards that failed to predict an outage.
- Caching is a correctness decision, not a performance trick
- Before any cache is recommended, we specify per data item who invalidates it, on what event, and how stale the interface can tolerate it being. A cache added for latency without an invalidation owner is a bug with a delayed fuse, and it typically detonates as a support ticket about data that changed for one user and not another. Where staleness cannot be tolerated, we say so and look at the query instead.
- Headroom is stated as a multiple, so it can be tested
- Findings read as "this holds to roughly this multiple of today's write rate, at which point connection saturation becomes the constraint, and behind that the single writer". That is falsifiable — your team can load test it and prove us wrong, which is the point. Vague conclusions about scalability cannot be checked, cannot be planned against, and cannot be prioritised against anything else on the roadmap.
Size of work
Where your project probably sits
A rough map so you can locate yourself before talking to us. Actual scope comes from a conversation, not a table.
| Level | Example | Engagement shape |
|---|---|---|
| Focused review | A second opinion on one decision: which datastore a new service should use, whether a proposed queue design handles retries and duplicates correctly, or whether a vendor's integration model fits your data residency obligations. | One engineer, one specific question, the code and telemetry that bear on it, one working session and a one-page recommendation. From about Rs 25,000. Broader reviews sit in the band below. |
| Full system review | A product in production that has to hold several times its current load, or a pre-funding technical assessment covering code health, infrastructure, cost and security posture before a diligence team looks at it. | Typically two to four weeks. Evidence gathering, separate engineer and management interviews, hands-on measurement, then the full architecture document with capacity and cost models, a ranked risk register, a sequenced plan, and readouts to both the engineering team and the board. |
| Platform assessment | Several products sharing identity and billing, an acquired codebase that has to be merged rather than run alongside, or a move to multiple regions with residency constraints in each. | Six weeks or more, run in phases with an interim readout so you are not waiting until the end for the first useful answer. Adds cross-system data ownership, integration boundary design, migration sequencing, and a review of team boundaries against the intended architecture. |
| Retained advisory checkpoints | The document is written, your own team is executing against it, and you want the design decisions reviewed as they are made rather than after they ship. | A recurring session at an agreed cadence plus asynchronous review of decision records and the pull requests that matter. Bounded and cancellable at any point. If what you actually need is someone accountable for engineering outcomes every week, that is a fractional CTO engagement, not this one. |
Honest limits
When this is not what you need
Telling you this early is cheaper for both of us than discovering it in month two.
- You need a document that endorses a decision already taken. We write what the evidence supports, and if the evidence contradicts the plan the document will say so in front of whoever commissioned it. If the purpose is ammunition for an internal argument, buy it from someone else.
- You need the change executed, not decided. This engagement ends at a document, a plan and a decision on record. Actually performing the migration, splitting the system or rebuilding the platform is delivery work — see software modernization or a dedicated development team.
- You want someone in the room every week, owning technical outcomes and making the calls as they arise. That is continuous leadership on a retainer, which is the fractional CTO engagement. A review is deliberately bounded: it starts, it answers agreed questions, and it ends.
- The system is failing right now and users are affected. An architecture review is poor incident response — it is slow by design and needs access to a stable system to measure. Stabilise first, then review, ideally with the incident timeline as one of the inputs.
Related work
Projects in this space
Payment platform
Built so that card data stays inside a narrow, separately scoped path — exactly the kind of boundary decision an architecture review exists to settle before code is written.
Read the case study: Payment platformHeadless commerce migration
A storefront moved to a headless architecture, where catalogue, cart and checkout boundaries had to be drawn and sequenced before any migration began.
Read the case study: Headless commerce migrationPatient records integration
Clinical records integrated across hospital systems nobody controlled end to end, making the integration boundary and data ownership the whole design problem.
Read the case study: Patient records integration
Questions
Common questions
What do we actually receive at the end?
A written architecture document containing current-state diagrams, findings ranked by risk and cost to fix, a target state with an incremental path to it, a capacity model, an infrastructure cost model, a risk register and a sequenced remediation plan. Alongside it come decision records for each irreversible choice. Everything is delivered in a format that lives in your repository so your team can keep editing it. There are also readout sessions — one for engineers, one for whoever holds the budget — and the questions raised there go into the final version.
How is this different from hiring a fractional CTO?
A fractional CTO is ongoing embedded leadership: present every week, accountable for outcomes over quarters, involved in hiring and vendor management. This is a bounded engagement with a start, an end and a specific question to answer. It produces a document and a decision, then it stops. Some clients run a review first precisely to work out whether they need continuous leadership at all, and quite often the review shows they do not.
Will you recommend technology you happen to want to build with?
We are technology-agnostic and the document is written to be executable by any competent team, including one that is not us. The safeguards are stated in the document itself: the widely-operated option wins unless a written constraint rules it out, and your team's existing skills and hiring reality are decision inputs. If we would be a plausible vendor for the build we recommend, we say so explicitly rather than leaving you to notice.
Can you review a system you did not build?
That is the normal case and it is what the process is designed for. We need read-only repository access, your telemetry and billing data, incident history and a schema dump, plus time with the engineers who work in the system daily. We sign an NDA before any access is granted. Reviewing someone else's system is also easier to do honestly, because we have no prior decision to defend.
Do we have to give you production access?
No. Read-only access to a replica, exported metrics and dashboards, a schema dump and a slow query log will carry most of a review. Where you would rather not grant direct access at all, we can work through screen-shared sessions with your engineers driving. What we will not do is pretend restricted access had no effect: the document records which findings are measured and which are inferred, so you know how much weight each one carries.
Is this useful before any code exists?
It is the cheapest point at which to do it. Pre-build, we review the domain and data model, the tenancy and isolation approach, integration boundaries with systems you do not control, the managed services being considered and what they cost as volume grows, and the residency layout. Decisions in those areas are close to free to change on a whiteboard and very expensive to change once there is production data behind them.
What if we disagree with the recommendation?
That is what the options workshop is for, and it happens before anything is written up as a conclusion. Decision criteria are agreed with your team at the start, so disagreement usually turns out to be about weighting rather than facts, which is a solvable conversation. Where we still disagree at the end, the document records both positions and the reasoning, and your team makes the call. It is your system to run.
Keep reading
Related work and reading
Related services
- Software modernization
Once the document names a target state and a strangler path, this is the page about executing it — migrating in increments while the existing system keeps serving traffic.
- Fractional CTO
If the honest answer is that you need technical judgement in the room continuously rather than one decision settled well, this is the retained version of the same seniority.
- Cloud and DevOps
Where a review's findings are mostly infrastructure — cost model, environments, deployment pipeline, observability gaps — this is the team that implements them.
- Software testing and QA
Reviews often conclude that the real constraint on delivery is test coverage and environment parity rather than the architecture itself.
- Dedicated development teams
The usual next step when the recommendation is sound but you have nobody free to execute it.
Get the second opinion in writing
Tell us the decision you are stuck on, or the system you need read before someone else reads it. We will come back with the questions the document should answer, the access we would need, and a scope — before you commit to anything. Reviews run remotely; we are in Ravet, Pune if you would rather have the readout in the room. Mon-Fri, 10:00-19:00 IST.