Skip to main content
Projectix
Talk to us

Technology

Engineering-led, architecture first.

Projectix is an engineering practice. The decisions that determine whether a system survives contact with production — data model, interface boundaries, authentication, failure behaviour — are made deliberately and written down.
Talk to our teamSee services

Reference architecture

px.layers

  1. PresentationServer-rendered UI, typed components, accessible interfaces
  2. APIVersioned REST or GraphQL, validation, authentication, rate limits
  3. DomainBusiness rules, thresholds, workflow state, scheduling
  4. IntegrationMarketplace and platform clients, retries, normalisation
  5. DataRelational storage, queues, object storage, retention rules
Cross-cutting
  • Security
  • Observability
  • CI/CD
  • Environments

01Architecture principles

Eight decisions we make on every system.

These are not preferences. They are the properties that determine whether a system can be integrated, operated and changed two years from now.
  • 01

    API-first

    Every capability is designed as a documented interface before it becomes a screen, so systems can be composed rather than rebuilt.

  • 02

    Cloud-native

    Managed platforms, stateless services and infrastructure that scales horizontally instead of being manually provisioned.

  • 03

    Modular architecture

    Clear boundaries between ingestion, processing, storage and presentation so one area can change without the rest following.

  • 04

    Secure by design

    Authentication, authorisation, validation and secret handling are decided at design time, not retrofitted.

  • 05

    Automation-driven

    Builds, tests, migrations and recurring operational work run as code rather than as manual checklists.

  • 06

    Observable

    Structured logs, health checks and meaningful metrics so behaviour in production can be explained.

  • 07

    Scalable

    Workloads are designed for growth in catalogue size, request volume and data retention.

  • 08

    Maintainable

    Typed code, predictable structure and documentation so the system stays workable years after launch.

02Delivery

From specification to operation.

Every engagement moves through the same five stages. The detail changes; the sequence does not.

  1. Stage 01

    Specify

    Data model, interfaces, permissions and failure behaviour agreed in writing before implementation starts.

  2. Stage 02

    Build

    Typed end to end, reviewed, validated at every boundary, with tests where they protect something that matters.

  3. Stage 03

    Integrate

    Authenticated clients, retry and rate-limit handling, and reconciliation against the source system.

  4. Stage 04

    Release

    Automated pipelines, reversible deployments, environment separation and managed configuration.

  5. Stage 05

    Operate

    Structured logging, health checks, alerting and documentation the receiving team can actually use.

03Technology ecosystem

Technologies we work with.

These are the tools Projectix is comfortable designing, building and operating with. The right combination depends on the problem — not every project uses every item, and we will tell you when something in this list is the wrong choice for you.

This list describes our practice, not the composition of any specific product. It should not be read as a statement of the stack used by MAP Protector or any client system.

Languages

  • TypeScript
  • JavaScript
  • Python
  • SQL

Application

  • React
  • Next.js
  • Node.js

Data

  • PostgreSQL
  • Redis
  • Object storage

Interfaces

  • REST APIs
  • GraphQL
  • Webhooks
  • Message queues

Platform

  • AWS
  • Vercel
  • Docker

Operations

  • CI/CD pipelines
  • Infrastructure as code
  • Structured logging

04Engineering standards

What we hold ourselves to.

A short list, applied consistently. Most production failures we are asked to fix trace back to one of these being skipped.
Security practices

  • Typed end to end

    TypeScript in strict mode across application and API code, with schema validation at every external boundary.

  • Reviewed changes

    Changes are reviewed before merge. Automated checks run on every commit, not only before release.

  • Explicit configuration

    Environment-specific values and secrets live in managed configuration, never in source control or client bundles.

  • Reversible deployments

    Releases are automated and can be rolled back. Database changes are migrations, applied in order.

  • Structured logging

    Integration and application events are logged in a consistent shape so failures can be traced, not guessed at.

  • Documented interfaces

    APIs are documented as a deliverable. If another team has to integrate, the contract is written down.

Technical conversation

Talk to the people who will build it.

Scoping calls are technical. Bring your constraints, your existing systems and the parts you are unsure about.

Talk to usExplore MAP Protector