Level 3 · Engineering & technical capabilities
Application development & engineering, described technically.
The stack, the contracts, the cloud architecture, the integrations and the modules the application is assembled from — then the process, the security controls, the support model, who owns the source code and what leaving looks like.
Interface
HTML5/CSS3, JavaScript, TypeScript, React
Server & data
REST APIs, JSON contracts, backend functions
Operations
Managed cloud hosting, backups, monitoring, support
Three levels of detail
One offering, documented at three depths.
Read the summary, the service scope, or the engineering detail underneath it. The promise does not change between them — only how far into the evidence you want to look.
Level 03 · Technical
Engineering & technical capabilities
The stack, the interface contracts, cloud architecture, integration patterns, development process, assurance, code ownership and exit — this page.
You are hereTechnology stack
What we actually build with, layer by layer.
Every item below is something we write or configure on a build. Not every engagement uses every one — the stack in use on your application is listed in the handover, with the runtime versions.
Interface layer
What the user sees, and what keeps it fast, accessible and indexable.
HTML5 & CSS3
Semantic, accessible markup and modern CSS layout. Screens are built to reflow from a phone to a wide desktop, so the same application is usable in the field and at a desk.
JavaScript
Client behaviour written as small, single-purpose modules with explicit inputs, rather than one page-wide script that everything else has to work around.
TypeScript
Used where data shapes matter — API payloads, form contracts and shared module boundaries — so a mismatched field is caught at build time rather than by a user.
React
Component-based interfaces with predictable state and a server-rendered first paint, so a page is indexable by search engines and readable before scripts finish loading.
Server & data contracts
Where business rules live, so the browser can never be the authority.
Backend functions
Pricing, approvals, notifications and every other business rule run server-side in focused functions. The browser asks; the server decides.
REST APIs & JSON
Clients and third-party systems talk to documented HTTPS endpoints exchanging JSON. No database credentials, service keys or privileged calls are ever shipped to a browser.
Validation and authorization at the boundary
Every request is schema-validated and checked against the caller's role, tenant and the specific record before it reads or writes anything.
Data modelling and retention
Records, relationships and indexes are designed around the questions the business actually asks, with a retention class agreed for each data set.
Cloud architecture
Managed infrastructure, so there is no server fleet for you to own or patch.
Edge-hosted serverless runtime
Applications run on a managed, edge-hosted runtime with regional points of presence. Capacity scales with demand and there is no machine for you to size, patch or replace.
Environments and secrets
Preview and production are separate environments, and every credential is held server-side in a secret store rather than in application code.
Logging and audit
Application logs, error capture and an audit trail on privileged actions, so an incident or a disputed change can be reconstructed after the fact.
Backup and recovery
Managed backups with a documented restore path. Restores are exercised as part of onboarding rather than assumed to work when they are needed.
Integrations
The application is useful because it talks to the systems already running the business.
OAuth connectors
Google Workspace, Microsoft 365, Meta, LinkedIn, Slack, Stripe, QuickBooks and similar services are connected through OAuth with the narrowest scopes the workflow needs.
Webhooks and scheduled jobs
Inbound webhooks verified by signature or shared secret, and scheduled jobs for recurring billing, digests and syncs — both idempotent, so a repeated delivery never duplicates a record.
Payments and email
Card and ACH payments are priced server-side and confirmed by a signed webhook, never by a browser redirect. Transactional email is sent from the application's own domain.
Failure handling
Retries with backoff, a visible failure state and an operator-visible error record, so a third-party outage does not silently swallow an order or a message.
Reusable modules
Built once, used everywhere — the difference between a codebase and a pile of screens.
Shared component library
Buttons, tables, dialogs, form fields, badges and empty states are built once. A change to a control changes it on every screen that uses it.
Shared server modules
Pricing, permissions, notifications and audit logging each live in one module and are imported by every function that needs them, so a fix lands everywhere at once.
Tenant and role patterns
Every record carries its tenant and its access rule, so a new screen inherits the same isolation instead of re-inventing it — and a cross-tenant read is a bug rather than a default.
Versioned change
Schema and module changes ship with release notes and a rollback path, rather than being edited live on a production data set.
Development process
Scope, architecture, releases, then the running application.
No phase ends without an artefact you can read. By the time the application is live you hold the plan it was built to, the acceptance criteria it was signed off against and the documentation to run it.
Discovery
One or two working sessions with the people who do the job today. We write down the process, the exceptions and the numbers that define success.
Architecture
Data model, roles, integrations and the screens needed for a first working version. You see the plan and the scope before code is written.
Build in releases
Two-week releases of working software, demonstrated on your own data instead of described in a specification deck.
Review and accept
Your team tests against written acceptance criteria. Feedback is triaged into the next release rather than reopening the whole scope.
Launch and hand over
Production environment, backups, monitoring and an access review, then a written handover: architecture diagram, access-control map, retention schedule and runtime inventory.
Operate and improve
Managed support, patching and monitoring, with a quarterly review of how the application is used and what the next highest-value change is.
Engineering assurance
Security, support, ownership and exit — stated with their limits.
A technical claim is only worth the evidence behind it. Each area below says what we do, how it is verified, and where the boundary of the claim sits.
Security engineering
Controls that are enforced in code, not described in a policy.
- Multifactor authentication, strong session handling, role-based permissions and tenant isolation between companies.
- Input validation, output encoding and an authorization check on every protected route and endpoint.
- Least-privilege service credentials, private file storage with time-limited signed links, and audit logging on privileged actions.
- Third-party components inventoried, checked against known vulnerabilities, and remediation recorded per release.
Builds are measured against NIST CSF 2.0, CIS Controls and OWASP guidance. Alignment is not certification, and we do not claim a certification we cannot put evidence behind.
Support and operation
The same team that builds the application runs it.
- Help desk Monday to Friday, 8 a.m. to 6 p.m. Eastern, with ticket ownership and vendor escalation.
- A named technical contact who knows your build, not a rotating queue.
- Error and uptime monitoring with alerting, and severity-based response targets agreed in the scope.
- Releases are tested in a preview environment and deployed with a documented rollback path.
Support hours, escalation paths and response targets are confirmed in the written scope before work starts.
Source code and licensing
Clear ownership, stated once and kept in the agreement.
- The source code written for your custom application is yours.
- The shared platform, component library and reusable modules remain ours, licensed to you — that is what keeps maintenance affordable.
- Handover includes the source repository, an architecture diagram, a plain-language access-control map, a data-retention schedule and a runtime inventory.
- Third-party components keep their own licences, which are listed with the handover.
You are never locked out of your own application: the code you paid for is delivered to you.
Data portability and exit
An exit that is written down before you sign, and honest about its limits.
- Your data exports in open formats (CSV and JSON, with uploaded files) whenever you ask, not only at the end.
- On termination you receive a complete data export, a copy of your custom source code, and a documented transition window.
- Data you ask us to delete is removed permanently, including from derived exports, on the agreed retention schedule.
- Portability has a limit we state plainly: the application runs on our managed platform, and we do not promise that the same code runs unchanged on a different host.
A move to another provider is a rebuild of the hosting layer, not a promise of one-click migration. We will scope that transition with you if you ever want it.
Talk to an engineer
Bring the technical questions to the first call.
Ask for the architecture diagram, the access-control map and the runtime inventory from a recent build. We would rather answer them before you sign than after — and a complimentary assessment is the fastest way to size what you need.
Coverage in motion
What is covered between the calls.
The service lines say what we run. This is how it runs — who answers, what is watched overnight, and how recovery is proven when it matters.
One number to call
Monday–Friday, 8 a.m.–6 p.m. ET, answered by a US-based technician who already has your environment in front of them.
Eyes on it overnight
Security alerts are triaged around the clock in qualifying tiers, with human-led investigation and escalation to your contact.
Coverage across the full United States
Every engineer, every ticket and every project stays onshore. No offshore hand-off in the middle of an incident.
Identity locked at the door
Multifactor authentication is enforced on email, remote access and admin consoles before a password ever gets reused.
Restores that are tested
Backups are proven with restore drills, so recovery is a documented procedure rather than a hope at the worst moment.
Documented response windows
Each priority level carries its own response commitment, so escalation is a defined step instead of a judgement call.
A named contact, not a queue
An engineer accountable to your account, who knows your sites, your software and the quirks of your environment.
Service lines