Engineering. builder layers.
/// ENGINEERING_MEMORY Tunet Engineering is the umbrella for everything we ship for builders: open-source foundations, reference implementations, commercial tools, and operated services that turn repeated technical work into reusable capability.
Open Source covers frameworks, contracts, and reference implementations. Commercial Tools packages operational services such as UI kits, managed databases, and supported modules. One page, one engineering system.
One engineering unit, two clear outputs.
A framework starts when the same technical problem appears across products often enough to deserve a named boundary, a stable contract, and a public explanation.
If the result should be freely inspectable and portable, it belongs in Open Source. If the result needs an operated service, support surface, or commercial packaging, it becomes a Commercial Tool.
Find the recurring edge
We look for glue code, data shapes, provider seams, safety checks, and migration paths that keep reappearing.
Make behavior explicit
The useful parts should be inspectable: inputs, outputs, failure modes, defaults, migrations, and escape hatches.
Ship tests and examples
A framework needs examples, boundaries, tests, release notes, and a reason another developer should care.
Publish what can stand alone
The pieces that solve a general developer problem become packages, docs, reference implementations, and public examples.
Engineering catalogue
Open Source and Commercial Tools together.
Browse the full Tunet Engineering surface by subcategory, technical concern, or maturity. Open layers and commercial offerings sit together so the path from reusable idea to supported tool is visible.
Product foundations
Portable contracts and canonical data that help products travel further.
Trust foundations
Explicit security and access layers for products that need to earn confidence.
SwapLayer
Provider abstraction for payments, email, storage, and other replaceable services, with migration paths and consistent contracts.
Core contract
Provider adapters
Product effect
Migration freedom
GeoCanon
A canonical country, locale, timezone, language, holiday, and jurisdiction layer for products that operate across markets.
Core contract
Canonical market data
Product effect
Global consistency
SessionArmor
Django session hardening with fingerprinting, audit trails, request gates, timeouts, and compliance-oriented defaults.
Core contract
Session security gates
Product effect
Traceable access
AccessGate
A data access layer for permissions, policy enforcement, row-level filtering, encryption posture, and auditable access decisions.
Core contract
Policy decisions
Product effect
Least privilege
Commercial Tools / Interface systems
Supported UI foundations for faster, more consistent product delivery.
Commercial Tools / Managed infrastructure
Operated technical services that remove recurring backend work.
AZ Super UI Kit
A practical component system for teams that need consistent UX, accessibility defaults, and faster launch velocity without rebuilding every interface pattern.
Technical surface
Product interfaces
Team effect
Faster consistent UI
Database as a Service
A managed relational database layer for teams that want secure provisioning, isolation, realtime subscriptions, policy controls, and a clearer backend starting point.
Technical surface
Managed backend
Team effect
Operational confidence
No Engineering entries match that filter yet.
Engineering standard
What makes a Tunet Engineering piece worth shipping.
Whether it is open-source or commercial, the layer has to be legible, portable, tested, and useful without needing the whole Tunet stack around it.
Portable by default
Data, configuration, and contracts should move cleanly between products, teams, and vendors.
Proven in real apps
The pattern should come from lived product pressure, not abstract architecture theatre.
Documented boundaries
Developers should understand what the layer owns, what it refuses to own, and how to escape it.
Release discipline
Versioning, deprecations, examples, tests, and support windows matter as much as the first implementation.
Engineering planning guide
Choose the right first layer.
Most teams struggle when critical behavior is hidden in one-off glue code. Tunet Engineering exposes that behavior as open contracts or packages it as supported commercial tooling so teams can reason, review, migrate, and reuse safely.
Start with SwapLayer if
- You rely on one payment, email, storage, or auth provider.
- You need a controlled migration path between vendors.
- You want consistent errors across integrations.
Start with GeoCanon if
- Your product operates across countries or jurisdictions.
- Locale, phone, timezone, or holiday data is duplicated.
- Compliance and localization logic keeps drifting.
Start with SessionArmor if
- You need stronger Django session security.
- Audit logging is part of your compliance story.
- You need hookable gates for onboarding or policy checks.
Use Commercial Tools if
- You need a supported UI system or managed backend.
- The problem needs service ownership, not just source code.
- Adoption speed matters more than assembling every layer yourself.
What a candidate should prove in the first 30 days
Weeks 1 to 2
Extract the layer in a low-risk path, validate its contracts, and decide whether it should be open, supported, or both.
Weeks 3 to 4
Move one real workflow end to end, add CI contract tests, and package the adoption path with examples, docs, or service onboarding.
Building something that should become reusable?
Bring us the repeated engineering pain: the integration, schema, safety layer, UI system, managed backend, evaluation loop, or workflow contract that keeps turning up across products.