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.
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.
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.
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 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.
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.
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.
Part of From our delivery work. Get new articles by email or follow the RSS feed.
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.
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.
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.