Zapex TechnologyGet started
Back to home

Technical Standard

The Zapex Engineering Standard

How we architect, build, and maintain every system we touch. This is not a marketing document, it is the actual process behind every build.

1. Architecture Principles

  • Proven over experimental. We build on established, industry-standard technology, cloud infrastructure (AWS, Azure, Google Cloud), microservices where they genuinely reduce complexity, and modern, well-supported frameworks. We do not use a client's system as a testing ground for unproven tools.
  • Right-sized, not over-engineered. Architecture is scaled to the business, not to what looks impressive. A five-person firm does not need the same infrastructure as an enterprise, and we do not bill for complexity that does not serve the client.
  • Designed to be handed off. Every system is documented and structured so that another competent engineer, not just the one who built it, could pick it up and understand it.

2. Security Standards

  • Role-based access control is enforced at every layer that handles sensitive data, never relying on the frontend alone to restrict access.
  • Credentials, API keys, and secrets are never committed to source control, and are rotated immediately if exposure is suspected.
  • Client data is stored using encryption at rest and in transit as a baseline, not an upsell.

3. Code Review Process

  • No code reaches production without being reviewed, either by a second qualified engineer on larger builds, or through a structured self-review checklist on solo-led work.
  • Reviews check for correctness, security, and maintainability, not just whether the feature works.

4. Deployment Pipeline

  • All builds go through an automated build-and-test step before deployment. Nothing is pushed to production manually without verification.
  • Every deployment is reversible. We do not ship changes we cannot quickly roll back.

5. Change Order Policy

Scope changes are common and expected. What is not acceptable is silent scope creep that erodes timelines and budgets without the client's knowledge. Our process:

  1. Identify the deviation. When a request falls outside the original agreed scope, we flag it plainly, not absorb it silently.
  2. Provide a fixed-price change order. The client sees the exact cost and timeline impact before any work begins.
  3. Pause and confirm. Work on the change does not start until the client approves it in writing.

This protects the client from surprise invoices, and protects the engagement from scope creep that quietly kills margins and delivery quality.

6. Warranty Policy

Every fixed-scope build includes a 30-day bug warranty from launch. If something we built breaks due to our error, we fix it at no additional cost.

Have a project in mind?

Book a free discovery call