Mobile
Native platform toolchains
Native code gives us direct access to platform privacy controls, background execution rules and accessibility APIs. Those are exactly the areas where a cross-platform abstraction tends to leak.
Engineering
How we build, in specifics
Claims about engineering quality are easy to make and hard to verify. This page states our practice concretely enough that you could hold us to it.
Practice
The standards every NEOMANERA project meets
-
Version control and review
All production code lives in version control. Changes reach a release branch through review, and the history of what shipped — and why — is auditable.
-
Automated verification
Continuous integration builds every change, runs the test suite and blocks a merge that fails. A green pipeline is a precondition for release, not a formality.
-
Reproducible releases
Builds are produced by automation from a tagged commit, so any released artefact can be traced back to the exact source that produced it.
-
Dependency and supply-chain hygiene
Third-party dependencies are pinned, scanned for known vulnerabilities and reviewed before adoption. We keep the dependency surface deliberately small.
-
Threat modelling at design time
Before a feature that touches personal data is built, we write down what could go wrong, who would be harmed and what the mitigation is.
-
Observability and incident response
Services are instrumented so that failures are detected by monitoring rather than reported by users, and incidents follow a written response procedure.
-
Data minimisation reviews
Every new data field is justified before it is stored. Fields that cannot be justified are removed from the design.
-
Accessibility verification
Interfaces are checked against WCAG 2.2 AA criteria with automated tooling and manual keyboard and screen-reader passes.
Technology
Positions we hold, and why
Technology choices are trade-offs. We would rather publish ours, with the reasoning attached, than present them as self-evident.
Services
Small, typed, boring services
We prefer a handful of well-understood services with strong type boundaries over a large distributed system. Complexity is a cost paid every day, not once.
Data
Minimised and partitioned
Personal data is collected only where a feature genuinely requires it, stored separately from operational data, and given an explicit retention period at design time.
Infrastructure
Declared as code
Environments are described in version control so they can be rebuilt from scratch, reviewed like any other change, and audited after the fact.
Delivery
Continuous integration, tagged releases
Every change is built and tested automatically. Releases are produced by the pipeline from a tagged commit, never from an engineer’s laptop.
Front end
Standards first, framework second
We reach for HTML and CSS before JavaScript. This website is a worked example: it ships as static files, and its interactive parts degrade to something usable without scripting.
Security
Security as an engineering discipline
Security work has a budget, an owner and review gates. It is not a checklist applied after a feature is otherwise finished.
- Transport security on every public endpoint, with modern TLS configuration.
- Secrets held in managed secret storage, never in source control.
- Least-privilege access to production systems, reviewed periodically.
- Automated dependency vulnerability scanning on every build.
- A published responsible-disclosure route with a stated response commitment.
- Written incident response procedure, including notification obligations.
Accessibility
Interfaces are not finished until they are usable by everyone
We target WCAG 2.2 level AA across our products and this website. In practice that means colour contrast is measured rather than eyeballed, every interactive control is reachable and operable from a keyboard, motion respects the operating system’s reduced-motion setting, and interfaces are tested with a screen reader before release.
Accessibility defects are treated as defects. If you encounter a barrier on this site or in one of our products, email [email protected] and we will treat it as a bug report, not as feedback.
Want the detail behind any of this?
We are happy to talk through our release process, data handling or security practice with a prospective partner, client or platform reviewer.