Delivery and engineering

Building a product we co-own

Most of our work is building software that a client owns. UMOYA Zone is different. It is a joint venture, and co-owning a product has taught us things that client work does not.

In short
  • A joint venture works when each side brings what the other cannot build quickly.
  • Owning a product means owning the work that continues after release, which client projects usually hand to someone else.
  • Consumer software loses people in the first minute. Enterprise software keeps them because they are paid to stay.

Almost everything nVisionIT builds belongs to someone else. A client describes an outcome, we design and deliver the system, and they own it. That is our business and it will remain our business.

UMOYA Zone is the exception. It is a personal development and performance app built as a joint venture with its founders, who spent years developing a coaching method for helping people set goals and stay with the habits that support them. We brought the engineering, and we share in what the product becomes.

What each side brought

The founders had a method and years of running it with people directly. What they did not have was a way to put it in someone's pocket and keep it working on two mobile platforms. We could build and run the software, and we were never going to invent a coaching method.

Co-ownership puts both sides behind the same result. When the founders ask for a feature we are not quoting for it. We decide together whether it earns its place in the product, and some requests stop there.

The decision that shaped everything

The first real product decision was about data. People use the app to record how they see themselves, including on bad weeks. We decided early that those entries would stay on the user's phone and never reach our servers. It closed off some features that depend on collecting everyone's data centrally, and it made the product one that people can be honest in. A later piece describes what that meant for the engineering.

Work that never ends

A client project ends in acceptance and handover. A product does not end. Every new release of iOS and Android needs testing against it, the app stores ask their own questions, and somebody has to decide what the next version is for.

In client work that continuing effort usually sits in someone else's budget. Here it sits in ours, and it has changed how we advise clients at design time. When a client asks for a second platform, an extra dependency or a feature few people will use, we now price in the years of maintenance it brings along with the build.

The first minute

People use enterprise software because their job requires it, and they put up with a clumsy screen. People open a wellbeing app on their own time, and if the first minute is confusing many never come back. That has pushed the product towards a short start, a single clear first action, and features that stay only if they are used.

UMOYA Zone is aimed at individuals, and at organisations that want to offer their people a structured programme: companies, sports academies, schools and health settings. What it does is described on the UMOYA Zone page.

Sources
  • nVisionIT and the UMOYA Zone founders, product development 2023 to 2026.
Keep reading

More from Insights

Delivery and engineering

Structure before speed in a development engagement

Standards applied the same way on every engagement are what let a small development team keep its pace after the first month. What that looks like in practice.

26 August 2026 · 3 min read
Delivery and engineering

Moving documents to SharePoint Online without moving the users

Unstructured data is the harder half of retiring an old platform. When documents are wired into daily work, the aim is a migration the users never notice, and the risk sits in places that are not code.

5 August 2026 · 3 min read
Delivery and engineering

Getting a platform ready for someone else's money

When an investor looks under a growing platform, the questions are about credentials, data and whether the fixes are real. What we learned taking a technical due diligence from first review to verified remediation.

2 July 2026 · 3 min read