Engineering

Decisions we have already made, so we do not relitigate them per project.

Most of what makes software trustworthy is settled long before a feature is designed. These are the standing choices behind everything Marlune Technologies builds.

Technology

Boring on purpose.

We choose technology by how well we will understand it in year four, not by how pleasant it is in week one. In practice that means relational databases with real constraints, server-rendered or pre-generated HTML wherever a single-page application is not genuinely required, and platform-native frameworks on mobile rather than a translation layer between us and the operating system.

Dependencies are the main long-term liability in modern software, so we keep the surface small. Every third-party package is a piece of code we are responsible for auditing, patching and eventually replacing. A hundred lines we wrote and understand usually beat a library that solves a slightly different problem.

Where content can be generated ahead of time, it is. Static output has no runtime to exploit, survives traffic spikes without capacity planning, and stays readable in a browser with scripting disabled — which is also the accessibility floor.

Standing choices

Web delivery
Static-first HTML, progressive enhancement, no framework required to read a page
Mobile
Platform-native UI, built to Apple HIG and Material guidance
Data
Relational storage, constraints and migrations under version control
Transport
TLS everywhere, HSTS, modern cipher suites only
Hosting
Infrastructure we administer ourselves
Analytics
None from third parties. Aggregate server logs only

Practice

The four standards a build is measured against.

01 — PRIVACY

Data minimisation as an architectural rule

We decide what is stored while designing the schema, not while writing the privacy policy. If a feature can run on the device, it runs on the device. Personal data that does have to reach a server is encrypted in transit, restricted to the code paths that need it, and given an explicit retention period rather than being kept by default.

We carry no advertising SDKs, no cross-site analytics and no behavioural profiling. We do not sell, rent or share personal data with data brokers, and our revenue never depends on the volume of data we hold.

02 — SECURITY

Least privilege, patched continuously

Services run with the narrowest permissions that let them work. Secrets live outside the codebase. Dependencies are monitored for published vulnerabilities and patched on a schedule, with a shorter clock for anything reachable from the network.

Backups are encrypted, kept off the machine that produced them, and — the part that is usually skipped — restored on a test schedule, because an unverified backup is only a hope. Security reports from outside researchers are welcomed and acknowledged; the address is on our contact page.

03 — ACCESSIBILITY

WCAG 2.2 AA as the floor, not the goal

Semantic markup before ARIA, full keyboard operability, visible focus, contrast that holds in both light and dark appearance, and respect for the operating system's reduced-motion and larger-text settings.

We test with the assistive technology people actually use — VoiceOver, TalkBack, keyboard-only navigation — on real devices before release. An interface that fails a screen reader is not finished, regardless of how it looks in a screenshot.

04 — REACH

Internationalisation from the first commit

Text is externalised from day one, and the layout is built for right-to-left scripts and for languages that need two or three times the space English does. Dates, numbers and calendars come from the platform's locale data rather than from assumptions baked into our code.

Where we cannot translate something responsibly, we leave it visibly untranslated rather than shipping a plausible guess. A confidently wrong translation is harder to spot, and therefore worse, than an obvious gap.

Operations

Running it is part of building it.

We operate our own infrastructure. That is a deliberate cost, and it buys control over where data lives and what happens to it.

01

Reproducible deployments

Server configuration is written down and version-controlled, so a machine can be rebuilt from a known state instead of from memory. A deployment that cannot be repeated exactly is an outage waiting for a bad week.

02

Monitoring that a person reads

Availability, error rates and certificate expiry are monitored, and alerts go to someone who can act on them. We would rather have a handful of alerts that always mean something than a dashboard nobody trusts.

03

Tested restores, not just backups

Backups are encrypted, stored separately from the source system, and periodically restored into a scratch environment to prove they work. The restore procedure is documented to the point where it can be followed under pressure.

04

Incidents handled in the open

When something breaks in a way that affects users, we say so, we say what we know, and we correct the record as we learn more. If personal data were ever exposed, affected users and the relevant authorities are notified within the deadlines the law sets — not when the messaging is comfortable.

Questions about how we work?

Technical due diligence, a security question, or a researcher with something to report — we answer all three.