The Mometic standard

Principles that survive the product cycle.

We designed and built Mometic with a unique vision and set of principles. Customers, employees and partners should understand how those principles shape what we build and how we operate.

About Mometic Explore MOMO Pro
Customer responsibilityNo data harvestingTestable technologyPurposeful design
01 COMMUNITYLong-term relationships.

People are customers, not inventory.

02 BUSINESSResponsible to the customer.

Value before growth theater.

03 TECHNOLOGYTested, maintainable systems.

Modern where it matters; boring where it helps.

04 DESIGNDo less, but better.

Purposeful tools with depth beneath simplicity.

Community

People before scale.

A relationship standard—not a growth tactic.

Community

Foster a close-knit, family-like group.

Mometic is built around traders and partners who understand the approach, trust the intent and expect to be treated as people—not inventory.

Long-term trustDirect feedbackDignity + respect

We aspire to maintain long-term bonds with customers and partners that last for years. Mometic supports those relationships over the life of the company and expects everyone involved to act professionally and treat others as they would want to be treated.

No outside party can view, change or manage MOMO on a user’s behalf. Customers are given practical ways to share ideas and influence product direction, while retaining control of their own account and decisions.

We celebrate the people using Mometic products and do not treat them as an anonymous mass—or a resource to be harvested.
Business

Value before growth theater.

BUSINESS

We are responsible to the customer.

MOMO is a paid product and the people using it are paying customers. The MOMO team is fully accountable to these customers and aim to build the product and business in a way that encourages our customers to stay with us. We will engage with our community to decide on the future direction and enhancements, coupled with our own vision. We believe we have done an amazing job over the past few years and believe the testimonials and feedback reflect a similar sentiment.

BUSINESS

No advertising or data harvesting.

MOMO treats everyone’s data as a responsibility and a liability, not an asset. We do not have access to your data (with exception of limited account and settings data). We will not sell or resell our users or their data. We do not make any specific statements about exact future business plans but we pledge to never use advertising as the primary means to fund our business.

BUSINESS

No growth hacking.

Mometic will not engage in aggressive growth hacking tactics that go against our values. Our focus is not on acquiring the largest customer base in the shortest amount of time, but rather on building high-quality, long-lasting relationships with our customers.

BUSINESS

Minimal footprint.

We designed and built MOMO without external funding, using contemporary and lean principles to minimize ongoing operating costs. Our main cost is the time invested in designing and maintaining the product. We have minimal operating costs for other aspects of our work. Most of the heavy lifting is done on Amazon AWS, and we have options to reduce costs there as well.

Technology

Maintainable systems over cleverness.

TECHNOLOGY

Limit third-party code.

As a general policy, we use only open APIs and frameworks. We may make exceptions, but we recognise that any third-party code in our product is a maintenance liability, so we mostly intend to avoid it.

TECHNOLOGY

Write boring code.

We want our code to be boring; that is, understandable and maintainable to ourselves and anybody else we may bring along the journey. We steer clear of brittle hacks and obscure languages. We don’t need to impress anybody with our smartness.

TECHNOLOGY

Tested and testable.

We aim for our code to be well-testable and covered by automated test and build scripts. We architect our code and systems in a way that affords maximum testability and always aim to maximize test coverage on all layers.

TECHNOLOGY

Skate where the puck is going.

We aim to continuously embrace technology and design innovation from across and within the financial market. This may mean implementing novel design patterns or dropping support of dated technology. In doing so we need to be pragmatic in balancing short-term needs with longer-term vision.

Design

Do less, but do it deliberately.

DESIGN

True to platform; unapologetically our own.

MOMO is built to be clean and intuitive where less is usually “more”, so we (and you) can focus on the task at hand.

DESIGN

Celebrate cross-device capability.

We are professionals who spend a large part of their working and leisure hours across all devices. Frustration with the sorry state of stock scanning tools was a large part of what motivated us to build MOMO Pro. Desktop and mobile needs will always be key design considerations for MOMO Pro and we will push the state of the art to always be a step ahead of the other guys.

DESIGN

Embrace craftsmanship.

We are craftspeople and work hard to provide a high degree of polish to our work. Building Mometic brings us considerable satisfaction and pride. Our aim is to use proven tools and methods, be proud of what we make, and treat MOMO as a reflection as to how software is meant to be built - by smart and passionate people. Part showcase, part expression, and part business.

DESIGN

Do less, but better.

We won’t have a massive laundry list of features and functions. We aim to do basic things relative to momentum, do them well, and iterate to continuously improve over the long run.

DESIGN

Build nuanced functionality.

We aim to develop purposeful, straightforward functionality while offering “Aha" moments to those striving to fully realize its capabilities. Meaning you, as a user, did a bit of thinking to switch lightbulbs on and uncover the richer purposefulness that lies beneath the surface.

Shared across products

Different clocks. The same operating principles.

MOMO Pro, Matterhorn, Aura and True Origin are built for different decisions, but each should expose its purpose, inputs and limits clearly.

See the Mometic approach