System Architecture & Technical Design ServicesDecide before you spend.
Architecture review, system design, and technical due diligence for teams about to commit to something expensive — or already carrying a decision that is not holding.
Why does the same architecture decision keep coming back?
Architecture decisions are cheap to make and expensive to carry. Most teams learn the price about a year after the meeting.
- 01The rewrite argument has no evidence behind it
- Half the team wants to refactor, half wants to start again, and nobody has measured what is actually wrong. The decision goes to whoever argues hardest, which is not correlated with being right.
- 02The design was right for a team that has moved on
- Choices made for five engineers and one customer are now carrying thirty engineers and an enterprise contract. The constraints changed; the architecture did not, because changing it was never anyone's quarter.
- 03The scaling plan is a feeling
- Nobody knows where the system breaks because nobody has pushed it there. Capacity conversations run on intuition, and the first real answer arrives during an outage.
A few weeks of evidence ahead of the decision is the cheapest engineering you will ever buy.
Advice from people who still build.
The engineers doing the review also ship production systems, so recommendations come from people who would have to live with them. Architecture advice from someone who has not built in five years is theory with invoicing.
A decision record is only useful if it captures what was not chosen and why. That is what stops the same argument being re-litigated every six months by whoever joined most recently.
A direction without a number attached is an opinion. Every option we put in front of you comes with an estimate, a sequence, and an honest read on what it puts at risk.
The review is priced as its own engagement rather than as a qualifying call for one. That is deliberate: it makes "change nothing yet" an outcome we are paid to be willing to reach.
What architecture services does Devarithm offer?
These are engagements, not a menu to combine. Most teams need exactly one of the first four, and which one depends on whether the decision is ahead of you or behind you.
Architecture Review & Assessment
An outside read on the system you have: where it is sound, where the risk actually sits, and what it will cost to carry as it is. Findings come with evidence rather than adjectives.
- Assessment across application, data, infrastructure, and delivery
- Risk register ranked by likelihood and cost
- Measured findings, not impressions
- Written recommendation with a sequenced roadmap
System Design & Decision Records
The design for something you have not built yet — topology, data model, boundaries, and integration surface — with each significant decision recorded alongside the option it beat.
- Target architecture and system diagrams
- Architecture decision records, including rejected options
- Data model and service boundary design
- Build sequence in dependency order
Scalability & Capacity Planning
Where the system breaks, found deliberately rather than discovered in production, and what each next order of magnitude costs in engineering and in infrastructure.
- Load modelling against realistic growth
- Bottleneck identification with measured evidence
- Scaling roadmap by growth threshold
- Infrastructure cost projection per stage
Technical Due Diligence
An independent assessment of an engineering organisation and its codebase for an investment, an acquisition, or a board that needs a read it did not get from the team being assessed.
- Codebase, infrastructure, and delivery assessment
- Key-person and knowledge-concentration risk
- Remediation cost and timeline estimates
- Findings written for a non-technical reader
Build-vs-Buy & Stack Selection
The comparison done properly: total cost of ownership over three years, integration surface, exit cost, and what each option means for your own team rather than in the abstract.
- Option comparison against your real constraints
- Three-year total cost of ownership modelling
- Integration, migration, and exit-cost analysis
- Written recommendation with the reasoning attached
Implementation Support
Optional, and deliberately separate. Design review and technical oversight while your team executes — so the architecture that gets built is the one that was agreed.
- Design review at each milestone
- Code and pull-request review on critical paths
- Decision support as constraints change
- Available whether or not we do the build
About to commit to something expensive?
A few weeks of evidence ahead of the decision costs a fraction of building the wrong thing well.
No commitment required. No pitch deck. Just a focused 30-minute conversation.
How does Devarithm run an architecture review?
An architecture engagement is short by design. If it takes a quarter to tell you what to do, the decision has already been made without it.
- 01Days 1–3
Context & Constraints
We write down the actual question, the constraints that are real, and what a good answer would have to satisfy. Teams regularly find this stage alone changes what they were about to do.
You getWritten problem statement and decision criteria
- 02Week 1–2
Review & Analysis
Codebase, schema, infrastructure, and delivery process, plus conversations with the people who hold the context that was never written down. Where something is claimed to be slow or risky, we measure it.
You getFindings with evidence, ranked by risk
- 03Week 2–3
Options & Trade-offs
Two or three viable paths, each costed, each with what it puts at risk stated plainly. Including, where it is honest, the option of changing nothing yet.
You getCosted options with trade-offs written down
- 04Week 3–4
Recommendation & Roadmap
A clear recommendation, the decision records behind it, and a sequenced roadmap your own team can execute. We present it to whoever needs to be convinced, including a non-technical board.
You getRecommendation, decision records, and roadmap
- 05Month 2+
Implementation Support
Optional and separately scoped: design review as the work proceeds, so what gets built matches what was decided. Available whether your team executes it or we do.
You getOngoing design review and decision support
What does an architecture assessment cover?
Five surfaces, because architecture problems rarely stay in one of them. A data-model decision shows up as a delivery problem, and a delivery problem is usually somebody else's architecture decision.
- Application
- Module boundariesCoupling & dependenciesTest coverageDependency health
- Data
- Schema designQuery patternsGrowth & retentionConsistency model
- Infrastructure
- Deployment pathEnvironment parityObservabilityCost structure
- Delivery
- Release cadenceReview processIncident responseDocumentation
- Security & Compliance
- Access modelData handlingAudit surfaceRegulatory exposure
Every novel component spends an innovation budget you would rather spend on the product. We recommend the unexciting option unless the problem genuinely requires otherwise, and we say which it is.
Splitting a system trades a code problem for a network problem, and the network problem is harder to debug. It is a trade worth making sometimes, and it is never a graduation.
Rewrites take longer than estimated, ship no value until the end, and usually recreate the original decisions under time pressure. Occasionally the evidence does point there — and then we show you the evidence.
Who is this service built for?
This is also a filter. If none of these describe you, the discovery call will be short and free, and we will tell you honestly.
- Teams About to Spend Heavily
- A rebuild, a platform migration, or a new system is approved and about to start, and the design has never been reviewed by anyone outside the room it was made in.
- A costed design, decision records, and the option you had not considered
- Companies Carrying a Decision That Is Not Holding
- Something chosen two years ago is now the reason releases are slow, and the internal argument about what to do has stalled.
- Measured evidence, a tiebreak with reasoning attached, and a sequenced way out
- Investors & Acquirers
- You are about to put money into a company whose engineering you have only heard about from the people being assessed.
- Independent diligence, a risk register, and remediation costs in plain language
- CTOs Who Need an Outside Read
- You have a view and you need it tested by someone with no stake in the internal politics before you commit the team to it.
- A fast, evidence-based second opinion — including when it disagrees with you
You are not obliged to have us build it.
The review is priced as its own engagement and written for your team to execute. That is deliberate — it is what makes "change nothing yet" an answer we can actually give.
Thirty minutes to scope it, no obligation.
How can you engage Devarithm for architecture work?
Fixed-scope engagements with a defined deliverable, priced as advisory work in its own right. There is no obligation to have us build what we recommend, and the pricing is structured that way on purpose.
An outside assessment of the system you have, with findings, risks, and a recommendation you can act on without us.
- Assessment across all five surfaces
- Risk register ranked by likelihood and cost
- Written recommendation and sequenced roadmap
- Best for: a decision you are about to make
A complete target architecture for something you have not built yet, with the decisions recorded and the build sequenced.
- Target architecture and system diagrams
- Decision records including rejected options
- Build sequence in dependency order
- Best for: a new system or a major rebuild
Independent assessment for an investment, acquisition, or board decision, written to be read by people who do not write code.
- Codebase, infrastructure, and delivery assessment
- Key-person and knowledge-concentration risk
- Remediation costs and timelines
- Best for: investment, acquisition, or a board ask
What actually moves your number: system size, how much documentation already exists, whether the original decision-makers are reachable, and how many options you want fully costed.
Get the decision right first.
Tell us what you are about to commit to, or what is not holding. We will tell you what a review would cover, what it costs, and whether you need one at all.
No commitment. No 50-slide deck. A focused 30-minute call.
Frequently Asked Questions
What is software architecture?
Software architecture is the set of decisions about a system that are expensive to reverse — how it is divided into parts, how those parts communicate, how data is modelled and stored, and what it runs on. Everything downstream inherits those choices, which is why they are worth deciding deliberately rather than by accumulation.
What does an architecture review cover?
Five surfaces: application structure, data, infrastructure, delivery process, and security. Each is assessed against your actual constraints and growth expectations, and the findings come with measurement rather than impressions. You receive a ranked risk register, a written recommendation, and a sequenced roadmap.
How long does an architecture review take?
Two to four weeks. The engagement is deliberately short — if it takes a quarter to produce a recommendation, the decision will have been made without it.
How much does an architecture review cost?
Architecture reviews run ₹1.5L–₹5L (roughly $1,800–$6,000). A full system design engagement runs ₹3L–₹10L and technical due diligence ₹2L–₹6L. System size and how much documentation already exists are the main cost drivers.
Should we rewrite or refactor?
Almost always refactor, and the evidence usually says so once someone measures rather than argues. Rewrites ship no value until they finish, take longer than estimated, and tend to recreate the original decisions under deadline pressure. When the evidence genuinely points to a rewrite, we show you the evidence rather than the opinion.
What is technical due diligence?
An independent assessment of a company's engineering — codebase quality, infrastructure, delivery practice, security posture, and key-person risk — carried out for an investor, acquirer, or board. The deliverable is a risk register with remediation costs, written so a non-technical reader can act on it.
What do we actually receive at the end?
A written recommendation, the architecture decision records behind it, system diagrams, a ranked risk register, and a roadmap sequenced in dependency order. Everything is written to be executed by your own team without us.
Do we have to hire you to implement the recommendation?
No, and the pricing is deliberately structured so that we do not need you to. The review is a standalone engagement, the deliverables are written for your team to execute, and "change nothing yet" is a conclusion we are willing to reach.
Will you review a system built in a stack you did not choose?
Yes. Architecture problems are mostly about boundaries, data, and delivery rather than language choice, and those translate across stacks. Where a specific technology matters to the finding, we say so explicitly.
What do we need to provide to get started?
Read access to the codebase and infrastructure, whatever documentation exists, and time with two or three people who hold the context. If the original decision-makers have left, we will say how that limits the findings rather than working around it quietly.
You might also need
Backend Engineering
When the review concludes the data layer or service boundaries are the problem, and you want the fix executed.
Cloud & DevOps
When the finding sits in the deployment path, environments, or cost structure rather than in the code.
SaaS Product Development
When the recommendation is to build, and you would rather the team that designed it also ships it.