Lab note 001 · Singapore

We build small software products — and then we keep them running.

VEXEL TECHNOLOGY PTE. LTD. is an independent software product lab. We work on mobile applications, utility software and digital products, taking each one from a written concept through to a maintained release. The scope stays deliberately narrow: a small number of products, built properly.

Entity: VEXEL TECHNOLOGY PTE. LTD. Domain: myvexeltech.com Channel: [email protected]
Bench record Active
Legal entity
VEXEL TECHNOLOGY PTE. LTD.
Entity form
Private company limited by shares
Jurisdiction
Singapore
Official domain
myvexeltech.com
Correspondence
[email protected]
Field of work
Mobile applications, utility software, digital products
01 / METHOD

Write it down first

Every product starts as a written note: the problem, the user, the screens and the data involved. Nothing is built until that note can be read and disagreed with.

02 / SCOPE

Fewer things, finished

We keep the number of active projects low. A small product that works and can be maintained is worth more than a long list of half-built ideas.

03 / UPKEEP

Shipping is the midpoint

Operating system updates, dependency changes and defect reports continue after release. Maintenance is treated as part of the product, not as an afterthought.

01 — About the lab

About VEXEL TECHNOLOGY PTE. LTD.

A small product lab, what we work on, and how this domain relates to the company behind it.

VEXEL TECHNOLOGY PTE. LTD. is a private limited company that operates as an independent software product lab. In practice that means the company does one thing: it conceives, builds and maintains software products. Most of what we make is small by design — a mobile application that removes one repeated friction, a utility that does one job well, or a lightweight service that supports a product we already run. We are not a general agency and we do not spread across unrelated lines of business.

Our working method is simple and written down. A project begins as a short internal note describing the problem, the person who has it, the screens involved and the data required. If that note cannot be written clearly, the idea stays on the shelf. If it can, we scope the smallest version that would genuinely help, build it in reviewable steps, and test it on real devices before it goes anywhere near a release.

Why products rather than projects

A project ends; a product continues. We prefer the second because it forces better decisions from the start. Knowing that we will have to maintain something changes how it is built: data models get documented, dependencies get tracked, and releases get a changelog. It also keeps us honest about scope, because every feature added is a feature someone has to look after for years. This is why our product list is short and why some concepts stay in research for a long time.

How the company and this domain connect

This site is published on myvexeltech.com, which is the official domain of VEXEL TECHNOLOGY PTE. LTD. The domain carries the company's public information, its product notes, its privacy policy and its terms of use, and it provides the company's business email addresses. Email received at an address on this domain is handled by the company; anything sent from another domain is not an official communication from us.

  • The same legal name appears on the home page, in this section, and in the footer.
  • One business email on the company domain serves as the published contact channel.
  • Product and legal information is maintained here rather than on third-party profiles.

02 — What the lab does

Services

Six types of work. Each one is a stage or a support function in the life of a small software product.

W‑01Concept

Utility App Prototyping

We turn a narrowly defined idea into a working prototype that can be held and judged. The output is a small application running on a real device, with the core interaction complete and the edges deliberately unfinished, so that feedback is about the idea rather than about the polish. Prototypes are built to be thrown away or promoted, and both outcomes are planned for from the outset. Feedback gathered at this stage decides whether a concept proceeds to a full build.

Deliverable: installable prototype · written findings
W‑02Build

Offline-First Mobile Builds

Applications that are useful without a connection are more reliable in daily use. We design local storage, conflict handling and synchronisation so that a product keeps working in tunnels, on poor networks and in buildings with no signal. Sync behaviour is written as an explicit, tested rule rather than left to chance, and conflicts surface to the user instead of silently discarding work. Battery use, storage growth and background refresh behaviour are measured during testing.

Deliverable: native or cross-platform client · sync rules
W‑03Build

Lightweight Backend Services

Not every product needs a large platform. We build small servers that do a specific job: accounts, synchronisation, scheduled jobs, or an integration between two systems. Services are versioned, logged and covered by tests, and they are documented well enough that another engineer could take them over without needing a handover call or a long explanation. Backups, a documented restore procedure and basic rate limiting are put in place alongside the service itself.

Deliverable: versioned API · deployment notes
W‑04Setup

Subscription Product Setup

Where a product is offered as an ongoing service, the account and billing side has to be straightforward and honest. We implement account creation, access tiers, renewal, and a cancellation path a user can find without searching. Entitlement checks run server side, and billing state is recorded so that a dispute can be settled from records rather than from memory. Trial periods, refunds and price changes run through the same recorded path.

Deliverable: account and entitlement logic · billing records
W‑05Measure

Release, Analytics and Iteration

After a first release we measure what actually happens: crashes, failed requests, the screens people abandon and the features nobody opens. Findings are written down and turned into a short list of changes for the next version. Measurement stays limited to what informs a decision, and what is measured is described in the product's own documentation. Nothing is measured for its own sake, and figures are not used to support claims we cannot stand behind.

Deliverable: release notes · iteration backlog
W‑06Upkeep

Long-Term App Stewardship

Products are kept current: operating system releases, library updates, security patches and defect resolution, handled on a schedule rather than in bursts. Each maintenance cycle produces a changelog and a short report, and deprecated components are replaced before they become a problem. The aim is that a product stays installable and usable for years. If something can no longer be maintained, users are told plainly and given time to export their data.

Deliverable: maintenance schedule · change log

03 — Experiment wall

Planned Product Areas

What is currently on the bench. Each card is an area of work together with its present state — none of these are claimed as released, listed, or approved by any store or platform operator.

EXP‑01

Mobile productivity tools

Applications that remove one repeated friction from a working day: capturing a note, finding it again, moving it somewhere useful. Designed around a single gesture and a short setup.

UtilityIn research
EXP‑02

Offline utility applications

Single-purpose apps for calculation, conversion and scheduling that work with no network connection and store as little as possible on the device.

UtilityPrototype
EXP‑03

Small team workflow tools

Lightweight coordination for small groups: requests, approvals and simple record keeping, without the configuration burden of a full enterprise system.

WorkflowConcept
EXP‑04

Subscription digital services

Products delivered as an ongoing service with account access, synchronisation between devices, and a billing and cancellation path that is easy to find.

ServiceScoping
EXP‑05

Device companion apps

Companions that pair a phone with hardware or a desktop application over a local network, handling discovery, pairing and reconnect behaviour.

CompanionIn testing
EXP‑06

Internal roadmap items

Concepts held at note stage with their risks written down. These are advanced only when they can be built and maintained properly, and some never leave this list.

ResearchBacklog
Reading the wall Concept In research Prototype In testing Scoping Backlog

A card moving to a released state is announced on myvexeltech.com together with its availability and the platform it runs on. Until an announcement appears here, treat every item above as work in progress.

04 — Compliance and trust

How the lab operates

The practices we follow when handling data, shipping code and answering the people who use what we build.

We treat compliance as something that happens while a product is being designed, not as a document written afterwards. In practice, this means deciding what a product needs to collect before it collects anything, reviewing every release before it goes out, and keeping one published route for anyone who needs to reach the company.

Product and mobile application work is planned and operated with awareness of platform policies, user privacy expectations, and responsible data handling practices. Where a distribution platform sets rules about permissions, purchases, data collection or content, we work inside those rules and keep a written record of the reasoning, so that a decision can be revisited rather than guessed at later. We do not describe ourselves as approved, certified or partnered with any platform operator, because no such relationship is claimed.

  • Data privacy — a documented purpose for every field, and nothing collected without one.
  • Secure development — code review, tracked dependencies, and staging kept apart from production.
  • User consent — permissions requested in context, with a plain explanation of the reason.
  • Responsible operation — monitoring, incident notes, and a defined route for fixing defects.
  • Platform policy awareness — distribution rules checked before a release goes out.
  • Business contact channel — one published email route for company and privacy matters.
  • Same-domain email — official correspondence is sent only from myvexeltech.com.

Scope of this statement

This section describes internal practice. It is not a certification, and it is not a claim that the company has been assessed, approved or endorsed by any platform operator, standards body or authority.

Answering requests

Questions about data handling, a product described on this site, or company verification can be sent to [email protected]. Written requests are handled in the order they arrive.

Recording changes

When a product changes what it collects or how it behaves, the change is written into that product's own documentation and reflected in the information published alongside it.

05 — Reach the lab

Contact

One official channel. Product questions, commercial enquiries and privacy requests all arrive in the same place.

VEXEL TECHNOLOGY PTE. LTD. works in writing. Requests, answers and follow-ups stay on record, which is useful when a question needs a considered reply or when several people on our side need to look at it. Messages are read by the company and answered in the order in which they arrive.

What helps us answer quickly

  • Who you are writing from, and your role in that organisation.
  • The product, page or document your question refers to.
  • Any reference or submission number already issued to you.
  • Whether the matter is commercial, technical, or about data and privacy.

Verification questions

If a partner, platform or authority needs to confirm the company's legal identity, we can supply the statutory particulars held on the official registry record and confirm that this domain and the email address published here belong to VEXEL TECHNOLOGY PTE. LTD.

Correspondence is handled by email so that both sides keep a complete record of what was asked and what was answered.