Start a project
+1 (425) 560-3363 angelika@apsoftwaretech.com

Technology Consulting · Service 09

Software Architecture & Technical Consulting

Independent architecture and code reviews, technical due diligence and design advice, so big technical decisions rest on evidence, not habit.

Starting from
$2,200
Discipline
Technology Consulting
Shortest timeline
1 to 2 weeks
Clients
Businesses, organizations & founders
Delivery
Remote, worldwide

What this service is

The most expensive mistakes in software are rarely bugs. They're early decisions about structure, data and dependencies that quietly make every later change slower.

Software architecture consulting is an experienced, independent look at how a system is designed and built: how it's divided into parts, how those parts talk to each other, where the data lives, and how code is tested and released. We review what exists, explain what we find in plain language, and recommend changes ranked by the risk they remove and the effort they take.

We work with engineering teams who want a second pair of eyes, with leaders who need to know whether a supplier's proposal holds up, and with investors who need to understand what they're buying. We favor simple designs. Many systems are better served by one well-structured application than by a fleet of microservices, and we'll tell you when the unexciting option is the right one.

More about Technology Consulting

Problems we solve

The situations that bring people to us

You don't need an architect on staff to need an architecture review. These are the usual triggers.

The situation todayWhat changes
Releases keep slowing down and the team blames the codebase A clear diagnosis of where the friction comes from and what to fix first
The system struggles under load and nobody can say exactly why Profiling and load tests that find the real bottleneck before you pay for bigger servers
A supplier has proposed a rebuild and you can't judge whether it's sound An independent assessment of the proposal's design, estimate and risks
You're investing in or acquiring a company whose value is its software Technical due diligence with findings you can factor into the deal
Your team is debating microservices and the discussion is going in circles A reasoned decision that fits your team's size, recorded with its trade-offs
Security was an afterthought, and now a customer is asking hard questions A security architecture review with fixes ranked by real-world risk

What you get

Deliverables

Not every engagement includes every item. Your proposal lists exactly what's in scope, and what isn't.

  1. 01

    Architecture review

    A written assessment of structure, boundaries, data flow, dependencies and hosting, with diagrams of the system as it really is and a ranked list of recommendations.

  2. 02

    Code review

    A sampled, in-depth read of the codebase covering readability, test coverage, error handling, dependency health and the hotspots where changes and defects cluster.

  3. 03

    Technical due diligence report

    For investors and acquirers: product quality, team practices, scalability, security, open-source licensing and key-person risk, written for a non-technical reader.

  4. 04

    Performance and reliability review

    Load tests, profiling, query analysis and failure scenarios that show where the system breaks first, how it recovers, and what it would take to scale.

  5. 05

    Security architecture review

    Authentication, authorization, secrets handling, data protection, dependencies and network exposure examined against common attack patterns such as the OWASP Top 10.

  6. 06

    Architecture decision records

    Short, dated documents capturing each significant choice, the options considered and the reasons, so future developers understand why the system looks the way it does.

  7. 07

    API and data design review

    Endpoints, contracts, versioning, schemas, indexes and data ownership checked for consistency, performance and how well they'll cope with change.

  8. 08

    Engineering practices assessment

    How code gets from a developer's laptop to production (branching, CI/CD, automated tests, environments, monitoring and incident handling), with practical improvements.

Visual model

What an architecture review looks at

How the pieces typically fit together on this kind of engagement.

What an architecture review looks atLayer 1: Your goals and constraints (Growth, risk, budget and team size). Layer 2: Structure (How parts connect), Data (Where data lives), Security (Who can do what), Delivery (How code ships). Layer 3: Ranked findings (By risk removed and effort), Decision records (Each choice and its reasons). Layer 4: Your roadmap (Fix now, plan next, leave alone)Your goals and constraintsGrowth, risk, budget and team sizeStructureHow parts connectDataWhere data livesSecurityWho can do whatDeliveryHow code shipsRanked findingsBy risk removed and effortDecision recordsEach choice and its reasonsYour roadmapFix now, plan next, leave alone
Your goals and constraintsGrowth, risk, budget and team size
StructureHow parts connect
DataWhere data lives
SecurityWho can do what
DeliveryHow code ships
Ranked findingsBy risk removed and effort
Decision recordsEach choice and its reasons
Your roadmapFix now, plan next, leave alone
Each area is assessed on its own and against your goals, because serious problems tend to sit where the parts meet.

Common use cases

Where this work usually applies

Practical patterns rather than industry labels. The shape of the problem matters more than the sector.

  • Use case 01

    Pre-investment due diligence

    A fast, discreet assessment of a target company's product and engineering team, written up for investors and their deal team.

  • Use case 02

    Second opinion on a supplier's proposal

    Before you approve a rebuild or a large change request, an independent check of the design, the estimate and the assumptions behind both.

  • Use case 03

    Preparing for a growth spike

    A launch, a major new customer or a seasonal peak ahead: load tests and capacity planning that show whether the system will cope, and what to fix if it won't.

  • Use case 04

    Monolith or microservices decision

    A structured look at your team, your domain and your scaling needs. For many teams the answer is a modular monolith, split later only if a real need appears.

  • Use case 05

    Rescuing a troubled project

    A delivery that's late, over budget or stuck: an honest review of the code, the plan and the team's practices, ending in a recovery path or a clear case for stopping.

  • Use case 06

    Answering a security questionnaire

    A large prospect has sent a long list of security questions. We review the architecture against it, close the gaps that matter and help you answer accurately.

Our approach

How we handle this kind of work

The parts of our method that matter most for software architecture.

  1. 01

    Read the code, not just the diagrams

    Diagrams show what people intended. The code, the database and the deployment pipeline show what actually exists, so that's where we spend our time.

  2. 02

    Prefer the simplest design that works

    Every extra service, queue and database is something to run, monitor and pay for. We recommend added complexity only when a specific, current problem demands it.

  3. 03

    Rank findings by risk and effort

    A list of every imperfection helps nobody. You get a short list of what matters, why it matters, roughly how long each fix takes and what can safely wait.

  4. 04

    Record the why, not just the what

    Decision records capture each choice with its context and the alternatives. A year later, a new developer can see the reasoning and change course safely if the context has changed.

  5. 05

    Respect the team that built it

    Most codebases make sense given the deadlines and knowledge they were built under. We review alongside your developers and aim to leave them stronger, not defensive.

Project stages

From first conversation to delivery

Each stage has a defined output and a review point, so you always know where the work stands.

How our process works
  1. 01

    Scope

    Agree the questions to answer, the systems in scope, who receives the findings and any confidentiality terms.

  2. 02

    Explore

    Read-only access to code, configuration, pipelines and infrastructure, mapped into a diagram of the system as it really is.

  3. 03

    Interview

    Conversations with developers, product owners and operations staff about what's hard, what breaks and what they'd change.

  4. 04

    Measure

    Load tests, profiling, dependency and vulnerability scans, and test coverage checks, wherever the questions call for evidence.

  5. 05

    Report

    A written report with ranked findings and decision records, walked through with your team, leadership or investors.

  6. 06

    Follow through

    Optional support while changes are made: design reviews, pairing with your developers and a check that the fixes worked.

Capabilities

What we bring to this work

Only the capabilities that matter for this service, and nothing we wouldn't actually recommend.

Review

  • Architecture and code reviews
  • Technical due diligence
  • Security architecture review
  • Dependency and open-source license audits
  • API and data model review
  • Supplier proposal assessment

Design

  • Modular monolith and service boundaries
  • Scalability and capacity planning
  • Performance profiling and load testing
  • Event and integration design
  • Data modeling and storage choices
  • Architecture decision records

Engineering practice

  • CI/CD pipeline design
  • Test strategy and coverage
  • Environment and release management
  • Observability and alerting
  • Incident review practices
  • Developer onboarding documentation

Delivery and engagement

Typical timelines

Timescales depend on the size of the codebase, the number of systems in scope and how quickly access is granted. Due diligence can be planned around a deal timetable if we hear about it early.

Focused review of one system or proposal1 to 2 weeks
Technical due diligence1 to 3 weeks, aligned to the deal timetable
Full architecture and engineering practices review3 to 6 weeks

Who it's for

Typical clients for this work

We work with companies, organizations and individuals. The requirement matters more than the size of the buyer.

Businesses

  • Companies whose product has grown faster than its architecture
  • Teams about to commit to a major rebuild or re-platform
  • Firms that rely on an outside supplier and want independent oversight
  • Businesses answering enterprise security questionnaires

Investors and acquirers

  • Private equity and venture investors assessing a software company
  • Companies acquiring a business whose value sits in its code
  • Boards that need an independent technical opinion before approving major spend

Engineering teams

  • Technical leads who want an experienced reviewer to test their thinking
  • Small teams without a dedicated architect

Related services

View all ten services
06 Development

Legacy Software Modernization

Make aging software safe to change again: an honest assessment, tests around what works, then upgrades or staged replacement with no big-bang cutover.

From$2,900
08 Consulting

Cloud Strategy & Migration

Decide what to move, rebuild, keep or retire, model the real costs, then migrate in planned waves with a tested way back at every step.

From$2,300
01 Development

Custom Software Development

Purpose-built applications that model your real operation (your data, your rules, your terminology), owned outright by you.

From$3,200

Service FAQ

Questions about software architecture

See all frequently asked questions
Should we move to microservices?

Probably not yet, and possibly never. Microservices help when many teams need to deploy independently, and they bring network failures, data consistency problems and higher running costs with them. For many teams, a well-structured modular monolith is faster to build and cheaper to run, and it can be split later along clean boundaries if the need becomes real. We'll look at your situation and record the reasoning either way.

How do you handle confidentiality during due diligence?

We sign confidentiality agreements before any access is granted, use read-only access wherever possible, and share findings only with the people you name. If you want to, we can also prepare a version of the report that's suitable to share with the target company.

Will the review turn into criticism of our developers?

No. We review systems, not people. Most codebases reflect the deadlines and constraints they were built under, and our findings say so. An outside review is often the easiest way for a team to get time approved for improvements it has wanted for a while.

Can you check a supplier's work on our behalf?

Yes, and it works best when the supplier knows about it. We can assess a proposal before you sign, review delivered code at agreed milestones, or look at a project that's drifting. The findings are factual and written to be fair to both sides, so the conversation stays about the work.

What does the $2,200 starting price cover?

A focused review of one system or one supplier proposal, with the code and architecture read in depth, interviews with the key people and a written report of ranked recommendations. Due diligence, load testing and broader reviews are scoped and quoted separately.

Starting from
$2,200

Final pricing depends on the size of the codebase, the number of systems involved and how much testing the questions require. Reviews are quoted as a fixed fee before any work begins.

Have a project in mind?

Tell us what you're trying to achieve. We'll come back with a clear view of the scope, the approach and the cost, and if we're not the right fit, we'll say so quickly.