AI Systems

AI that does a specific job, in production.

5 capabilities

We build AI for defined tasks within existing workflows. Our work includes Veravox, the live translation product we designed, built, and operate.

Real-time speech translation

Live audio is transcribed, translated, and synthesized as Spanish speech in one streaming pipeline. Veravox applies this approach to long-form, one-way translation and currently runs in production.

Document AI and knowledge search

Turn contracts, records, manuals, and email into something a team can actually query. Extraction, classification, and retrieval wired into the systems people already use, rather than a separate tool nobody opens.

Transcription and summarization

Meetings, calls, and lectures converted to accurate, searchable text, with structured summaries routed wherever they need to land.

Retrieval-augmented assistants

Assistants grounded in approved documentation so responses can cite their sources. Retrieval and evaluation are scoped to improve accuracy and surface unsupported output.

Model integration and evaluation

Choosing the right model for the job, measuring whether it is actually working, and building the fallback path for when it is not.

AWS & Cloud

Infrastructure designed for repeatable deployment, visibility, and cost control.

6 capabilities

Our AWS work uses infrastructure defined in code, including this site and Veravox. This supports repeatable deployment, reviewable changes, and documented handoff. We hold AWS Solutions Architect, Developer, and AI Practitioner certifications.

Infrastructure as code

Terraform with remote state, so environments are reproducible and every change is reviewable. No hand-clicked consoles, no configuration that exists only in somebody’s memory.

Serverless and containers

Lambda and API Gateway where traffic is spiky, ECS where workloads are steady. Chosen on the shape of the problem rather than fashion, because the difference shows up on the monthly bill.

Content delivery and edge

CloudFront with origin access control, TLS requirements, and managed security headers to improve delivery performance and restrict direct origin access.

Identity and access

Cognito for authentication with external identity providers, and scoped IAM roles with explicit least-privilege policies for everything else.

Monitoring, logging, and cost control

CloudWatch metrics and structured logs with defined retention, so you can answer what happened and what it costs without guessing.

Migration and modernization

Moving existing sites and applications onto managed infrastructure with a documented cutover and a rollback path. The migration plan is tailored to the current application and its operational constraints.

Power Platform

Line-of-business applications without a two-year build.

6 capabilities

For organizations that already use Microsoft 365, Power Platform may be a practical alternative to a bespoke application. We evaluate that fit against workflow, data, interface, governance, and support requirements.

Canvas apps

Pixel-controlled apps built for a specific task and a specific screen size. The right choice when the workflow is opinionated and the interface needs to match how people actually work, especially on tablets and phones in the field.

Model-driven apps

Applications generated from the data model, with the security roles, forms, views, and business rules coming from Dataverse. The right choice when the data relationships are complex and consistency matters more than bespoke layout.

Dataverse modelling

Tables, relationships, business rules, and role-based security designed properly up front because the data model drives the behavior of a model-driven app.

Power Automate

Approvals, notifications, document routing, and scheduled jobs connected across Microsoft 365 and outside systems, with error handling that surfaces failures instead of swallowing them.

Power BI

Dashboards and paginated reports built on a clean semantic model, so numbers reconcile and nobody maintains a shadow spreadsheet.

AI Builder

Form processing, prediction, and classification added to existing flows and apps where a full custom model would be overkill.

Web Applications

Sites that maintain themselves and stay fast under real conditions.

5 capabilities

Not brochure pages. Applications with content pipelines behind them, so what visitors see stays current without anyone editing markup every week. Performance and accessibility are requirements of the build, not upsells afterwards.

Content automation pipelines

Media, events, and publications syncing automatically from the sources you already use. On the Kress build this replaced weekly manual editing with three pipelines and a 90-day forward scheduling horizon.

Performance engineering

Payload budgets, image pipelines, compression, and caching strategy treated as part of the build. Our Kress Memorial reference build has recorded a 100 Lighthouse score across performance, accessibility, best practices, and SEO.

Accessibility

Semantic structure, keyboard paths, focus management, and contrast checked against WCAG AA. This matters both ethically and because public institutions are frequently obligated to it.

Technical SEO

Structured data, canonical URLs, sitemaps, and metadata built into the templates so search engines can read the site the way users do.

Lead capture and integrations

Forms with real spam defence, attribution tracking, and routing into whatever the team already checks, such as email, a CRM, or a queue.

Security

Security controls matched to the system and its risk.

6 capabilities

Our standard approach covers identity, credentials, transport, origin protection, abuse controls, and logging. Additional controls are scoped when the workload or regulatory context requires them.

Secrets management

Credentials are managed in AWS Secrets Manager and injected at runtime rather than stored in application code, the repository, or shared documents.

Least-privilege access

Scoped IAM roles with explicit policies, so a compromised component cannot reach past what it legitimately needs.

Transport and origin protection

TLS 1.2 as the minimum, HSTS, managed security headers, origin access control, and storage with public access blocked at the account level.

Bot and abuse defence

reCAPTCHA Enterprise plus server-side validation on public forms, so scoring happens where it cannot be bypassed by skipping the browser.

Audit logging and retention

Application and access logs with defined retention, so there is an answer when someone asks what happened and when.

Hardening for regulated workloads

Where the data justifies it: WAF, Content-Security-Policy, customer-managed encryption keys, tightened retention, and selecting only BAA-eligible services. Scoped per engagement rather than promised as a blanket certification.

How we build

A real stack, taken apart

This is the architecture used for this site and Veravox, not a conceptual illustration. Pull it apart layer by layer, or switch on the security overlay to see which controls sit on which components.

Exploded view of a four-layer AWS architecture: edge, application, data, and foundation.

Drag to rotate · click any service

A still render of the interactive model, which needs a larger screen and WebGL. Every layer and component in it is written out in full just below.

Every layer, in full

01

Edge

Where requests arrive

Every request hits the edge first. Traffic is terminated close to the user, served from cache where possible, and never reaches the origin directly.

  • Route 53 DNS with health checks and a single canonical hostname; other hosts redirect rather than serving duplicate content.
  • CloudFront Global CDN terminating TLS, applying the managed security-headers policy, and caching static assets at the edge. TLS 1.2 floorOrigin access control
  • ACM certificates Certificates issued and rotated automatically. Nothing expires because somebody forgot a renewal date. TLS 1.2 floor
02

Application

Where the work happens

Request handling, authentication, and business logic. Serverless where traffic is spiky and containers where it is steady, based on the shape of the workload.

  • API Gateway Routes requests to compute, with access logging and throttling applied before anything reaches application code. Audit logging
  • Lambda / ECS The application itself. Lambda for spiky traffic, ECS for steady workloads. Both deploy from the same container-or-artifact pipeline. Least-privilege rolesRuntime secret injection
  • Cognito Managed authentication with external identity providers. Password storage and token issuance are not problems worth solving from scratch. Managed authentication
03

Data

Where state lives

Records, files, and credentials. Each has a different access pattern and a different blast radius if it leaks, so each is isolated separately.

  • DynamoDB Structured records with encryption at rest and point-in-time recovery. Accessed only through scoped roles, never a shared credential. Least-privilege rolesEncryption at rest
  • S3 Object storage with public access blocked at the account level and reachable only through the CDN origin access control. Origin access controlEncryption at rest
  • Secrets Manager Credentials injected at runtime. Never in application config, never in environment files committed to git. Runtime secret injection
04

Foundation

What holds it up

Identity, networking, observability, and the code that defines all of it. This is the layer clients never see and the one that determines whether the rest is maintainable.

  • IAM Scoped roles with explicit least-privilege policies for every component, so a compromise cannot reach past what that component legitimately needs. Least-privilege roles
  • VPC Private subnets and controlled egress. Internal traffic does not traverse the public internet unless it has a reason to.
  • CloudWatch Metrics, structured logs, and alarms with defined retention provide a record of what happened and when. Audit logging
  • Terraform Every resource above is defined in code with remote state. Reviewable, diffable, and reproducible from scratch.
How it works

Engagements based on your requirements

Scope depends on your current systems, operational requirements, and delivery goals. An initial call helps us identify the appropriate next step.

  1. 01

    Discovery

    We learn what you have, what it costs you, and where the time is actually going. Fifteen minutes to start.

  2. 02

    Build & demo

    We build it and show you something working, so you see exactly what you are getting before anything goes live.

  3. 03

    Launch & operate

    We go live, provide the documentation and access defined in the agreement, and support the approved operating scope.

Discuss your requirements

Tell us what needs to change. We will review the request and recommend a practical scope, including a simpler option when it meets the requirement.