The Internal Engineering Standard at Lumitech — Made Public on Purpose.
Many software vendors don’t operate from a written engineering standard. The ones that do treat it as a trade secret. We publish ours because the existence of a real standard — and the willingness to be measured against it — is itself a buying signal.
What this is
What “Good” Means at Lumitech
“Quality code, on time” is no longer a value proposition. It’s the baseline. The Lumitech Standard is what we hold ourselves to above that baseline — across architecture, code, AI evaluation, security, observability and operations.
Our goal was never to create a marketing artifact. Our standard is the document our engineers are reviewed against, and the bar new hires have to clear. Publishing it does three things at once: it tells our clients what to expect, it explains to the team what’s non-negotiable, and it filters out engagements where the expectations, incentives, or operating model are not a fit.
Standards that aren’t written down aren’t standards, but preferences with good lighting.
What follows is the public version of the standard — six pillars, each with what we believe, how we actually measure it, and what “below the bar” looks like so the line is unambiguous.
Six pillars
What We Measure Ourselves Against
Six dimensions. Every serious engagement is evaluated against them, every engineer is reviewed with them in mind, every retro uses them to find what held and what didn’t.
Architecture & Design
Systems that survive contact with reality, not slide-deck diagrams.
Code Quality
Readable today, maintainable in two years, debuggable at 3 am.
AI Evaluation
AI output varies by design, so it needs a measurement discipline of its own. We treat it as one.
Security by Default
Threat modeling at design time. Not “we’ll add auth later.”
Observability
If you can’t see it, it isn’t running. If you can’t measure it, it isn’t done.
Operational Excellence
Production is the only environment that counts.
01 · Architecture & design
Systems are Designed for the Reality They’ll Live in
We design for the operational environment — load shapes, failure modes, regulatory boundaries, change cadence — before we design for elegance. The system has to survive the year, not just the demo.
What We Do
Explicit architecture decision records. Failure-mode analysis before implementation. Boundaries chosen so future change is cheap. Documented trade-offs, not hidden ones.
How We Measure
Every non-trivial system has an ADR log. Senior review on architectural calls. Post-incident reviews trace failures back to the design decision that allowed them.
Below the Bar
Architecture by accident, “We’ll figure it out later,” diagrams that don’t match the running system, hand-waving load and failure assumptions.
02 · Code quality
Code is Read More Often than It’s Written. We Optimize for the Reader
Code clarity, naming, structure, and test coverage exist to serve the engineer who’ll debug this at 3 am, not the engineer who feels clever today. AI accelerates output; only humans can decide whether that output is honest.
What We Do
Reviewable PRs with clear intent. Tests where they earn their keep. Linting and formatting automated. AI-drafted code reviewed by humans, never shipped blind.
How We Measure
Production code receives human review, with AI used as an additional critic — never as the final authority. Defect rates tracked per surface area. No PR ships without an explicit “what could go wrong” note.
Below the Bar
Mystery code, tests that test the mock, vibe-coded AI output committed without review, clever instead of clear.
03 · AI evaluation
AI Systems Are Evaluated Like Systems, Not Demos
When AI is in the loop, “looks right” is not a measurement. We run real evals, version prompts and models, track regressions, and treat AI output the way we treat any other production behavior — observable, reproducible, accountable.
What We Do
Eval harnesses from day one, golden sets curated from real usage, prompt and model versions are first-class artifacts, regressions block ship.
How We Measure
Pass rates, regression deltas, and qualitative review on every model or prompt change. Production AI behavior monitored, not assumed.
Below the Bar
Shipping a prompt because “it worked in the chat.” No regression tracking when models update. Stochastic outputs treated as deterministic ones.
04 · Security by default
Security is a Design Input, not a Closing Checklist
Threat modeling happens before lines of code, not before launch. Sensitive data, identity, authorization, and audit are part of the architecture conversation. We assume hostile inputs because they always show up in production.
What We Do
Threat models at design time. Secrets management as a default, not a remediation. Least-privilege access. Auth/authz reviewed by senior engineers are non-negotiable.
How We Measure
Dependency scanning on every commit. SAST and secrets scanning in CI. Quarterly review of access posture on long-running engagements.
Below the Bar
“We’ll add auth later,” secrets in env files in repo, permissions copied from the previous project without review, threats discovered in production.
05 · Observability
If You Can’t See the System, You Don’t Own the System.
Logs, metrics, traces, and dashboards are not post-launch concerns. They are the way we know whether the code is doing what we intended — at the moment we ship, and three months later, and during the incident none of us wanted.
What We Do
Instrumentation in the same PR as the feature. Dashboards tied to user outcomes, not vanity metrics. Alerts that wake people up only when humans are needed.
How We Measure
SLOs defined and tracked. Mean time to detect, not just mean time to resolve. Alert noise audited monthly — if a page can’t be acted on, it shouldn’t exist.
Below the Bar
Dashboards nobody reads, alerting on metrics nobody owns, “We’ll add logging after launch,” production incidents diagnosed by re-reading the code.
06 · Operational excellence
Production is the Only Environment that Counts
Code that hasn’t survived production hasn’t been built. Deployment pipelines, rollbacks, runbooks, on-call practice and incident response are first-class engineering work — not handoffs to “ops.”
What We Do
Deployments automated and reversible, runbooks written by the team that built the feature, blameless post-mortems, on-call rotations with real coverage.
How We Measure
Deploy frequency, lead time, change failure rate, and MTTR tracked per engagement. Incidents reviewed within five business days, with documented changes.
Below the Bar
“It works on staging,” manual deploys, runbooks written after the first incident, post-mortems that blame an individual instead of a system.
Above the pillars
Four Meta-Principles that Override Anything Else
When the six pillars produce conflicting answers, these four resolve the tie. They are the rules we don’t bend.
M1
Honesty Before Optics
If something is broken, late, or fragile, we say so — to the client, in writing, on the day we know. Surprise is the most expensive thing we can deliver.
M3
The Reader is the Team in 6 Months
Every artifact (code, doc, ADR, runbook) is written for the engineer who’ll touch this when none of the original authors are around. Optimize for them.
M2
Senior Judgment Wins Ties
Tools and processes have a vote; senior judgment has a veto. If the standard and the situation conflict, the senior engineer’s call is documented.
M4
Production Trust is the Score
Demos don’t count. Slides don’t count. The system holding in production under real load is the only signal we use to decide whether the work is done.
M1
Honesty Before Optics
If something is broken, late, or fragile, we say so — to the client, in writing, on the day we know. Surprise is the most expensive thing we can deliver.
M2
Senior Judgment Wins Ties
Tools and processes have a vote; senior judgment has a veto. If the standard and the situation conflict, the senior engineer’s call is documented.
M3
The Reader is the Team in 6 Months
Every artifact (code, doc, ADR, runbook) is written for the engineer who’ll touch this when none of the original authors are around. Optimize for them.
M4
Production Trust is the Score
Demos don’t count. Slides don’t count. The system holding in production under real load is the only signal we use to decide whether the work is done.
Good To Know
Is the Lumitech Standard the same for every project?
How does this standard affect the way Lumitech works with clients?
Does following the standard slow delivery?
Ready to bring your idea into reality?
- 1. We'll sign an NDA if required, carefully analyze your request and prepare a preliminary estimate.
- 2. We'll meet virtually or in Dubai to discuss your needs, answer questions, and align on next steps.
- Careers → careers@lumitech.coPartnerships → partners@lumitech.co
Prefer a direct line to our CEO?
Prefer a direct line to our CEO?