What we build

A portfolio we own, from the schema up.

Marlune Technologies develops and operates its own software. This page sets out the areas we build in, how a product moves from an idea to a release, and the bar it has to clear before it reaches anyone.

Current status

Our first products are in active development

We list a product on this site when it ships and we can support it — not while it is still an intention. Until then, the sections below describe the areas we are building in and the process behind them. If you would like to be told when the first release lands, write to info@marlunetechnologies.com.

Product areas

Where our engineering effort goes.

We work in a narrow set of areas on purpose. Depth in a few domains beats a thin presence in many, particularly for a team that also has to operate what it builds.

AREA 01

Consumer mobile applications In development

Focused, single-purpose applications for iOS and Android. We aim for software that works offline, opens instantly, holds no account when it does not need one, and asks for a permission only at the moment it is used — with a plain explanation of why.

Our mobile work is built against Apple's Human Interface Guidelines and App Review Guidelines and Google's equivalents, including accurate privacy nutrition labels, age ratings that match the actual content, and a working support route from inside the app.

AREA 02

SaaS platforms In development

Subscription web software for small organisations and professional teams. Multi-tenant from the first migration, with tenant isolation enforced at the data layer rather than trusted to application code.

Roles and permissions, audit logging, data export, invoicing and a genuine account-closure path are treated as version-one requirements. They are much harder to retrofit than to design in, and their absence is what makes software feel unfinished.

AREA 03

Reference & utility software In development

Large, structured bodies of information turned into something fast and searchable — calendars, catalogues, reference libraries and the tooling that keeps their source data verifiable.

This work is static-first: pages are generated ahead of time and served from disk, so a reader gets an answer without waiting on a database, and the archive stays readable even when JavaScript does not run.

AREA 04

Internal platform & tooling Continuous

The layer beneath the portfolio: build and release pipelines, deployment, backup and restore procedures, monitoring and alerting, and the shared libraries our products draw on.

None of this is sold. It exists so that a two-person release is as controlled as a twenty-person one, and so that recovering a service is a rehearsed procedure rather than an improvisation.

Process

How a product gets from idea to release.

Five stages. A product does not move forward because a date arrived; it moves forward when the previous stage is genuinely finished.

Definition

We write down the specific problem, who has it, and what the software will deliberately not do. The scope boundary is the most valuable output of this stage — it is what stops a focused product from drifting into a general-purpose one that serves nobody particularly well.

Architecture and data model

The data model comes before the interface. We decide what is stored, where it lives, who can reach it, how it is backed up and how it is deleted — and we write the privacy consequences down at this point, while they are still cheap to change. Retrofitting data minimisation onto a finished product is close to impossible.

Build

Short iterations against a working build. Automated tests cover the logic that would be expensive to get wrong — money, permissions, dates and time zones, and anything touching personal data. Every dependency added is a decision with a maintenance cost, and it is argued for rather than assumed.

Release readiness

Before submission: an accessibility pass on real devices with a screen reader, performance measured on hardware several generations old, a dependency and permission audit, a privacy disclosure that matches what the code actually does, and a support channel that a person is watching. A product that cannot be supported is not ready, however finished it looks.

Operation

Release is the beginning of the expensive part. We monitor availability, respond to reports, publish a changelog, and keep dependencies patched for as long as the product is offered. When a product does reach its end of life, we say so in advance and provide a full export — we do not let software go quiet and take its users' data with it.

Release standard

What ships with every Marlune product.

Not aspirations — the checklist a release has to satisfy.

A published privacy policy

Written in plain language, specific to that product, listing exactly what is collected and why — and kept accurate as the product changes.

A monitored support address

Reachable from inside the product and from this website, answered by someone who can actually change the software.

Data export and deletion

Open, documented formats for export. Deletion that reaches backups on a stated schedule, without a retention clause in the fine print.

Accessibility conformance

WCAG 2.2 AA on the web, platform accessibility APIs honoured on mobile, verified with assistive technology before release.

A public changelog

What changed in each version, in language a user rather than a compiler can read. No release notes that say only “bug fixes”.

No third-party trackers

No advertising SDKs, no cross-site analytics, no behavioural profiling — in the shipped binary, not merely in the policy document.

Building something adjacent?

We are open to partnerships, distribution conversations and technical collaboration where the fit is real. Tell us what you are working on.