What is a digital product, and which form does your organisation need

Many organisations talk about "building a website" or "building an app" as if those are different categories of work, governed by different rules and scoped at different rates. They are not. They are different forms of the same thing.

A digital product is any software-enabled system that delivers value to a user. A website is a digital product. A web application is a digital product. A mobile app is a digital product. A multi-tenant SaaS platform is a digital product. The choice an organisation makes when commissioning software is not whether to build a digital product. It is which form the digital product should take.

This article walks through the most common forms a digital product can take, what each one is good for, and how to figure out which form fits a given problem.

What a digital product is

A digital product is a software-enabled system designed to deliver value to a user over time, with success measured by the outcomes it produces and the way it evolves rather than by the moment it ships. The category sits inside the broader field of product design and is distinguished from physical products by being intangible, distributable instantly, and inherently updateable.

It is worth naming what is not a digital product in the sense used here. A downloadable ebook for sale online, a printable planner, a stock music track. The creator economy sometimes calls these digital products, and that usage is fair in its own context. The studio's work is on digital products as *systems*, not as digital SKUs sold from a shop. The distinction matters because someone arriving at this article from the e-commerce side of the internet will otherwise start with the wrong mental model.

The forms a digital product can take

The same digital product framing covers a wide range of forms. The studio has delivered most of them. Each form is good for a different kind of problem.

Website. A digital product whose primary function is to communicate. The user arrives, takes something away, and leaves. State is not maintained across visits. There is no account, no transaction that lives across sessions. The studio's Project Polaris impact story engagement is a website. Project Polaris is the Caribbean's first smart, climate-resilient teaching hospital, a US$60 million project being built in Grenada. The digital product communicates the vision to investors, partners, and the Grenadian public. The information architecture was designed around four distinct audiences and the specific questions each would arrive with. No user signs in. The product's job is credibility.

Web application. A digital product where users sign in, do work, and have state maintained across sessions. The interactivity is the deliverable. The studio's work on Giftme Hub impact story is a web application. Giftme Hub serves 400+ companies that use it to reward and motivate their employees with digital gift cards. Users sign in, manage accounts, run campaigns, and see results. The product has to do work reliably and produce value every time a user opens it.

Multi-tenant SaaS platform. A web application that serves many organisations at once, with each tenant operating in its own isolated environment. The "multi-tenant" part is what makes it a platform rather than a single-instance web application. The studio's T-Stats Solutions impact story is a multi-tenant SaaS platform. So is Metarelic People. T-Stats Solutions serves tourism boards across the UK and parts of Africa, with each board working in its own tenant. Metarelic People serves businesses across Grenada, with each business running payroll and HR in its own tenant. The form has specific architectural demands, tenant isolation, shared infrastructure, statutory rule encoding where it applies, that are not present in a single-tenant web application.

Mobile app. A digital product designed for use on mobile devices, typically when context-of-use, on the go, in the field, away from a desk, is part of the product's value. The studio's work on Pure Flowers impact story includes a mobile app. Pure Flowers is a digital marketplace connecting Grenadian flower growers with buyers, and the mobile app is the form that fits how growers actually work, away from desks, on farms, on the move.

Marketplace. A digital product that connects two or more user types and facilitates exchange between them. Pure Flowers is the example again, this time considered as a marketplace rather than as a mobile app. Marketplaces have specific delivery problems: matching, trust, transaction flow, dispute handling. They are usually a web application or a mobile app, but the marketplace pattern is distinct enough from a single-audience product that it earns its own name.

There are other forms a digital product can take, an API, a backend system, an embedded device, a kiosk, a chatbot. The list above covers what the studio has actually delivered. Most organisations commissioning software work end up needing one or two of these forms, sometimes combined.

Why the form matters less than the lifecycle

Whichever form is chosen, the work that makes the digital product succeed is the same. Product Clarity before the build, defining what to make and why. Product Build with engineering discipline. Product Growth that measures what is working. Product Stewardship that keeps the product useful over time.

The form determines the shape of the work. The lifecycle determines whether the work succeeds.

The mistake organisations make is not usually choosing the wrong form. It is treating the form as if it determines the work. A website built without Clarity will fail in the same way a SaaS platform built without Clarity will fail, just on a smaller scale and a tighter timeline. A mobile app stewarded for six months and then abandoned will degrade in the same way a marketplace stewarded for six months and then abandoned will degrade.

This is why the studio's services are organised around the lifecycle rather than around the form. The same Clarity work happens whether the answer is a website or a marketplace. The same Stewardship commitment applies whether the product is a single-purpose tool or a multi-tenant platform. The form is the shape of the ship. The lifecycle is what determines whether the ship stays afloat.

How to figure out which form your organisation needs

Three questions usually settle it.

First, what does the user actually do with the product? If they read and take something away, a website is probably the right form. If they sign in and do work that persists across sessions, a web application or a SaaS platform. If they need to do that work away from a desk, a mobile app or a mobile-first web application.

Second, who is the user? If it is one organisation using the system internally, a web application. If it is many organisations each operating in their own isolated environment, a multi-tenant SaaS platform. If it is two distinct groups exchanging value with each other, a marketplace.

Third, where is the user when they use it? Context-of-use determines whether mobile is a primary form or a secondary surface. A field worker on a flower farm needs mobile. A finance team running payroll does not.

The answer to those three questions usually settles the form. The harder question, which most organisations underestimate, is who will do the lifecycle work that makes the form succeed.

What this looks like in practice

A digital product is not a category of thing to be chosen from a menu. It is a way of approaching software work. The form is a delivery decision, made based on what the user does, who the user is, and where the user is. The substance is whether the work is treated as a digital product or as a one-off deliverable.

The expensive mistake is rarely picking the wrong form. The expensive mistake is scoping a digital product as a project with an end date, building it, handing it off, and being surprised when the system that nobody is stewarding starts to fall over twelve months in.

A digital product is not what you ship. It is what you keep.

‍