MSAOne

Engineering

We build, integrate and operate software in the cloud. Whoever designs the architecture leads the delivery.

We deliver as a project or with engineers placed on the client’s team. We build and operate our own software, and the flow we use on it is the same one we bring to clients. The completion criterion does not change: software in production, with a team able to maintain it.

Talk to a specialist

Custom software

New or modernized software in production, with a pipeline, infrastructure as code and the client team ready to evolve it.

What we do

  • Building applications

    We define the architecture, the contracts between services and the path to production before we start building. The application is born with state outside the process, configuration outside the code and deploys without a maintenance window.

  • Modernizing what already runs

    We move existing applications, in stages, to an architecture that can take the next step in volume. Changes ordered by gain, without stopping the current operation.

  • AI in the engineering flow, with senior review

    We use coding agents every day and put everything through senior review before merge. The speed comes from the tool. Accountability for what runs in production stays with whoever reviews.

  • Infrastructure as code from the start

    The pipeline and the Terraform go into the first commit, together with the application. An environment that can be rebuilt from scratch never becomes a dependency on one person or one console.

Where we usually come in

  • Volume doubled and the system cannot keep up

    Every peak becomes an incident: the server holds sessions, there is a single database and deploys need a maintenance window. Scaling it as it is costs more than redesigning it.

  • Shipping a change takes days, not minutes

    The path to production has manual steps, an environment that only exists on someone’s machine and rollbacks done by hand. Nobody wants to be the one who presses the button.

  • There is no one senior enough for the architecture decision

    There is budget and there is a team. There is no one who has made this decision before and will answer for it.

Tools

  • Terraform
  • CI/CD
  • Claude Code
  • Amazon ECS
  • Amazon EKS
  • AWS Lambda
  • Amazon RDS
  • Amazon CloudWatch

Systems integration

Systems that exchange data under a defined contract, with a trace of every message and no retyping between them.

What we do

  • Contract before integration

    Format, versioning, authentication and what happens when one side changes, defined before the systems are connected. REST, FHIR, HL7, events or files, whatever the other side accepts.

  • Integrating what was never built to integrate

    Legacy with no API, a shared database, a file on a network share. We put an integration layer in front instead of touching what nobody wants to touch.

  • Messaging and asynchronous processing

    Queues and events when the volume or the downtime of one side cannot block the other. Reprocessing and idempotency designed from the start, not after the first duplicate.

  • A trace of every message

    What went out, what arrived, what failed and why, recorded and visible. Integration without a trace becomes a support ticket without an answer.

Where we usually come in

  • A third-party system needs to talk to the MV platform

    A lab, imaging, pharmacy or government data network needs to exchange information with SOUL MV over FHIR or HL7, without retyping and without a spreadsheet in between.

  • The same data is typed into two systems

    Each system works on its own. Between them, someone retypes, exports a spreadsheet or checks by hand, and the error shows up at month-end close.

  • The integration exists, but nobody knows what it does

    A script from years ago moves the data. When it fails, the user is the one who notices; when it needs to change, nobody dares to touch it.

Tools

  • FHIR
  • HL7
  • REST
  • OpenAPI
  • Amazon API Gateway
  • Amazon SQS
  • Amazon EventBridge
  • AWS Lambda
  • Terraform
  • Amazon CloudWatch

Cloud and operations

An organized cloud environment, operated against reliability objectives and with cost in the hands of whoever decides.

What we do

  • Architecture and migration

    Accounts, identity, network, security and governance defined before migrating. We migrate in waves, each with acceptance criteria and a way back. On AWS, with AWS Organizations, Control Tower and IAM Identity Center.

  • Infrastructure as code

    Every change to the environment goes through reviewed code and up the same pipeline, from development to production. A gap between what is in the repository and what is running is detected, not discovered.

  • Operations and SRE

    Metrics, logs and traces with OpenTelemetry; SLIs and SLOs agreed with whoever answers for the system; incident response with defined roles and blameless review. An alert only exists if someone acts when it fires.

  • FinOps

    Cost by account, environment and product, with an owner. We cut the waste and leave behind budgets, alerts and periodic review, so the spend does not come back the next cycle. Usage commitments only over consumption already observed.

  • Security prepared for an audit

    Account segregation, least-privilege access and an audit trail designed with LGPD and ISO 27001 on the table, before anyone asks for evidence.

Where we usually come in

  • The environment grew without structure

    Accounts created as needed, access granted to whoever asked, and nobody knows anymore what is running. Before growing, it needs order.

  • Every deploy goes through the same person

    Deploys, incidents and routine tasks run on the memory of whoever knows the environment by heart. Vacations become a risk.

  • The cloud bill went up and nobody can explain why

    Spend grows faster than usage, cost has no owner, and nobody remembers the architecture decision that caused it.

Tools

  • AWS Organizations
  • AWS Control Tower
  • IAM Identity Center
  • Amazon EKS
  • Amazon ECS
  • Amazon RDS
  • Terraform
  • OpenTelemetry
  • Prometheus
  • Grafana
  • Amazon CloudWatch
  • AWS Cost Explorer
  • AWS Budgets

Data and dashboards

The data your systems already produce, gathered in one place, reliable and on dashboards that decision-makers open every day.

What we do

  • Data extraction and integration

    We pull data from the systems the company already operates, including third-party systems and SOUL MV, through APIs, databases or files. Automated loads, with a trace of every run.

  • An analytical base with an owner

    One place, with the data cleaned and versioned. Business rules written once, not in every spreadsheet; access by role, with LGPD on the table.

  • Operational and management dashboards

    The indicators the operation and the leadership follow: occupancy, queues, billing, cost. Refreshed automatically, with nobody assembling the number by hand.

  • Data migration between systems

    When a system is replaced or implemented, we carry the history over without losing or corrupting it: mapping, validation and reconciliation before the cutover.

  • Data ready for AI

    Quality, catalog and access permissions resolved before a model is connected to the data. It is what separates a pilot from a product.

Where we usually come in

  • The indicator is assembled by hand every week

    Someone exports from three systems, merges it in a spreadsheet and checks it. When the number diverges, the meeting turns into an argument about the source.

  • Each department has its own truth

    Finance, operations and the board look at different numbers for the same question, because each one calculates it its own way.

  • The data exists, but it is locked inside the system

    The system stores everything and lets nothing out: no API, no report in the shape you need, no history.

Tools

  • Amazon S3
  • AWS Glue
  • Amazon Athena
  • Amazon Redshift
  • Amazon QuickSight
  • Grafana
  • Terraform

AI and agents

AI inside the product or the operation, with cost per use case, measured quality and a way to switch it off without taking down the rest.

What we do

  • Integrating AI into what already exists

    We connect models to the systems and data the company already operates, through the APIs it already has. The model reaches internal data through tool use and MCP, with the permissions of whoever asked; no copying databases into the AI.

  • Agents in production

    An agent running in production needs an identity, minimal permissions, state, an execution trace, a spending limit and a way to be interrupted. We build with all of that from day one, not after the first incident.

  • Evaluation before scaling

    Before scaling, there is a set of real cases with the expected answer, written with the people who use the system. Changing prompt, tool or model without running that set is guessing.

  • Team enablement

    We bring coding agents into the client’s engineering flow, with review, tests and control over what reaches production. The team leaves able to design, version and evaluate its own agents.

Where we usually come in

  • The pilot worked and never left the pilot

    It convinced in the demo. To get into the product it still needs access control, integration with what already exists, measurement and someone to operate it.

  • AI is already in production and nobody measures it

    Cost per call, latency and answer quality are on no dashboard. Expanding its use without that is new debt.

  • Coding agents reached the team before the rules did

    Everyone already uses them. Nobody has defined what goes through review, what may go to production and who answers for the result.

Tools

  • Amazon Bedrock
  • Amazon Bedrock AgentCore
  • Anthropic Claude
  • Claude Code
  • MCP
  • AWS Lambda
  • Amazon ECS
  • Amazon CloudWatch
  • Terraform

How we work

Every engagement goes through three phases, Diagnosis, Execution and Support, described in How we work.

In Engineering we deliver in two models: Project, with scope and completion criteria agreed up front under our lead, and Placement, with selected engineers inside a project led by the client.