Praxis / working protocol

How we build systems that survive contact with reality.

Praxis is the operating method: the principles, constraints, and decisions that govern how private software systems are designed, built, hardened, and handed over.

Not a sales pitch / a declaration of practice

/praxis/method
Operating assumptions
Architecture before interface.
Failure modes before happy paths.
Handover before dependency.
Quiet systems Clear boundaries
Operating principles

The work is shaped by systems thinking, operational restraint, and long-term ownership.

Systems over features

We do not start with feature lists. We start with the system that must produce, protect, and evolve those features. The interface is a projection of internal truth.

Failure is designed

Every system fails. The difference is whether failure is anticipated, contained, observable, and recoverable—or discovered in production at 03:00.

Control by default

Dependencies are treated as liabilities until proven otherwise. External services are abstracted behind boundaries so they can be replaced without surgery.

Silence is signal

A healthy system is quiet. Alerts should indicate intervention, not background noise. We instrument for anomaly, not vanity metrics.

Capability domains

Tools are selected by pressure, not fashion.

The work spans backend systems, infrastructure, security, and operational continuity. The domain changes; the discipline stays the same.

Software engineering

Systems / APIs / platforms
  • Backend systems in Go, Rust, Python, or PHP selected by problem shape.
  • API design with versioning strategies that survive years of evolution.
  • Event-driven architectures using Kafka, NATS, or smaller purpose-built brokers.
  • Database design across relational, document, and time-series workloads.
  • Cryptographic implementation and secure protocol boundaries.

Infrastructure

Servers / networks / continuity
  • Linux/BSD administration with hardening beyond default configurations.
  • Container orchestration with Kubernetes or Nomad when complexity is justified.
  • Network architecture, overlay networks, and anonymity-aware service layers.
  • Backup strategies with tested recovery procedures, not hopeful scripts.
  • Monitoring that reveals state without drowning operators in noise.

Security & privacy

Protection / discretion / minimization
  • Threat modeling that considers real adversaries and operational incentives.
  • Key management and sensitive data boundaries for systems that cannot leak.
  • Privacy-preserving architecture: minimization, encryption, and scoped retention.
  • Tor/I2P integration for services requiring network-level anonymity.
  • Incident response planning before the incident exists.

Continuity

Endurance / handover / recovery
  • Documentation for the engineer who inherits the system under pressure.
  • Runbooks that assume the reader is stressed and short on context.
  • Capacity planning based on observed growth, not optimistic projections.
  • Graceful degradation when components fail or overload.
  • Knowledge transfer that leaves the client independent, not trapped.
Engagement protocol

The process is written-first, constraint-led, and intentionally calm.

Discovery

Week 0

We listen. You describe the problem space, constraints, and desired outcomes. We ask questions that reveal assumptions. No proposal yet; only understanding.

Architecture

Weeks 1–2

We design the system before touching code. Data flows, failure boundaries, security perimeters, and scaling vectors are defined. You receive a document, not theatre.

Construction

Weeks 3–n

Implementation proceeds in vertical slices. Each increment is deployable, observable, and testable. You see working systems early, not polished illusions.

Hardening

Pre-launch

Before production: load testing, failure review, security checks, and documentation. The system proves it can survive before it is trusted.

Transition

Post-launch

You receive documentation, runbooks, architecture decisions, and operational context. Support can continue, but the goal is independence—not dependency.

Boundaries

Clear scope protects the work.

Clarity requires stating what lies outside the scope. These are not offered:

Marketing websites or brochureware
Native mobile applications
WordPress, Shopify, or hosted CMS work
SEO, growth hacking, or analytics optimization
Projects without clear ownership or decision authority
Engagements built around daily ceremony instead of written progress

This is not judgment. It is recognition that certain work belongs elsewhere. The best systems work starts by refusing the wrong work.

Next step

Bring the system that needs to become calm.

If this approach matches how you think about correctness, continuity, and discretion, a written intake is the right starting point.

Establish contact View selected works