Skip to content
Gradmarc Adtech LLP

06 / IT Consulting & Technology Solutions

IT consulting for architecture, technology choices and modernisation

Technical review and technology consulting: architecture, technology selection, APIs, cloud, DevOps, performance and legacy modernisation, delivered as written recommendations.

01What we build

What a consulting engagement covers

  1. 01

    Architecture reviews

    An assessment of how a system is structured, where it is fragile and what to change first.

  2. 02

    Technology selection

    Options compared against your constraints, with a recommendation and the reasoning.

  3. 03

    API strategy

    How systems should expose and consume data, and how to evolve them safely.

  4. 04

    Cloud and DevOps assessment

    Hosting, environments, pipelines and operational practice reviewed for risk and cost.

  5. 05

    Performance audits

    Where time is lost in a slow system, measured before anything is changed.

  6. 06

    Modernisation roadmaps

    A sequence of steps for moving off ageing software without stopping the business.

02Problems we solve

The situations that lead people to us

  • Problem 1

    Build or buy is undecided

    Teams debate without the information to settle it.

  • Problem 2

    A system nobody wants to touch

    It works, but every change is risky and nobody fully understands it.

  • Problem 3

    Slow, fragile deployments

    Releases are manual, infrequent and stressful.

  • Problem 4

    Quotes that cannot be compared

    Vendor proposals use different assumptions, so the cheapest may not be the cheapest.

Deliverables

What you receive

Consulting should end in something you can act on, and something you can hand to someone else.
  1. 01

    A written assessment

    What we looked at, what we found and how sure we are.

  2. 02

    A prioritised risk list

    Problems ranked by likelihood and consequence.

  3. 03

    Options with trade-offs

    Realistic alternatives, with cost, effort and risk for each.

  4. 04

    A recommended path

    One clear recommendation and the reasoning behind it.

  5. 05

    Next steps

    What to do first, who needs to be involved and what to decide.

03Capabilities

What is included in the work

  • Architecture review

    Structure, boundaries, data flow and failure modes.

  • Technology selection

    Trade-offs written down, not decided by preference.

  • API design and strategy

    Contracts, versioning and integration approach.

  • Cloud review

    AWS and hosting set-up, environments and cost drivers.

  • DevOps and CI/CD

    Build, test and release automation.

  • Performance diagnosis

    Measurement first, then targeted fixes.

  • Modernisation planning

    Incremental paths away from legacy systems.

  • Proposal review

    A careful read of another vendor's scope and estimate.

04Technology

The tools this work uses

Capabilities relevant to this service. Not every project uses every tool.
Backend
REST APIs
Database
PostgreSQLMySQLMongoDB
Cloud and DevOps
AWSDockerNginxPM2GitHub ActionsCI/CD

05Process

How a consulting engagement runs

  1. 01

    Understand

    The system, the business around it and what is prompting the review.

  2. 02

    Investigate

    Code, infrastructure and documentation reviewed, with the people who run them.

  3. 03

    Analyse

    Findings separated into facts, risks and judgements.

  4. 04

    Recommend

    Options and a recommended path, written clearly.

  5. 05

    Hand over

    A walkthrough, and the option of Gradmarc delivering the work.

06Concept project

Tessel: a cloud console and architecture review

A concept product designed and built by Gradmarc to show this kind of work. The brand, people and figures in it are fictional; it is not client work.

A monitoring console for a production platform and the architecture review built on top of it: numbered findings on the system diagram, with the proposed changes drawn alongside.

  1. Tessel architecture review: a list of five findings with severities beside a system diagram of CDN, load balancer, web, API, cache, database, queue and worker, with numbered findings and a proposed read replica.
    01Architecture reviewFindings are pinned to the parts of the system they affect.
  2. Tessel production overview: six service health cards, a latency chart with deploy markers, error rate, alerts and a deployment pipeline in its canary stage.
    02Production overviewThe monitoring view the review starts from.

07FAQ

Questions we are asked

Do you only advise, or can you also build?

Both are possible. A review can stand on its own and be used with any team, and Gradmarc can also deliver the resulting work where that is wanted.

What does a review involve?

A review typically involves reading code and documentation, inspecting the infrastructure and talking to the people who run the system, followed by a written report.

Can you review a quote from another vendor?

Yes, this is a common request. The review looks at scope, assumptions and the estimate, and points out gaps, risks and anything that is unclear.

How long does a review take?

It depends on the size and state of the system. The scope and timeline are normally agreed before the work starts.

Can you help us modernise a legacy system?

Yes. A common recommendation is an incremental route that replaces parts in a safe order, so the business keeps running.

Have something worth building?

Tell us about the it consulting project you have in mind. A short brief is enough to start.