A Map of Digital Product Development and the Expert Studio Business

Picture a simple situation: someone clicks "Book a consultation". What actually has to happen for that person to end up with a confirmed time slot, rather than just a nice-looking button? The answer runs from the screen, across the network and the server, to stored data, a message to the client, the team's work and the support that follows.

What you will understand

By the end of this unit you will be able to trace a user's action through the main parts of a digital product and tell a product apart from a project and from a technical service. You will recognise the responsibilities a team carries and see where tools built on artificial intelligence can help across the life cycle. This is a general map: code and repositories are covered in detail in Anatomy of a Code Project, diagnosing what a client actually needs in Product Discovery, Positioning and Client Diagnosis, and the economics of a studio in Economics of an AI Studio.

No prior knowledge is required. Abbreviations, technical terms and jargon are explained the first time they appear.

Product, project, application and service

People often use these words interchangeably, but each one answers a different question.

A product is an offering that helps particular people achieve an outcome and that keeps needing support and development afterwards. A product can be a mobile app, a web service, a sales website, a device with software inside, or a combination of these. A button, a page or a repository on its own is usually not a whole product: each is only a piece of what a person receives and uses.

A project is time-bound work to create or change something. "Launch online booking by October" is a project; the booking system, its users, its rules, its support and its later improvements can all go on existing after that project ends. Teams draw these boundaries differently, so what matters is not the label in Jira but a shared understanding of what it means.

An application is a program, or a connected group of programs, that a person uses to get a particular job done. A marketing website may do nothing more than show pages prepared in advance; a web application lets a person change data or do work in the browser; a mobile app is installed on a phone and, depending on how it is built, may partly work offline. Any of these interfaces may have a server-side program behind it, but it does not have to: a website can be entirely static. Products are not all built the same way.

In this course, service mostly means a long-running, continuously available part of a software system that does work for other parts of the system or for people. A server-side service that stores bookings is one example. In business conversation, "service" can also mean a service offering or a way of serving a customer. Context tells you which meaning is intended.

These distinctions explain why "the code is written" does not always mean "the product is ready". Code can exist and still be untested, unreleased, unconnected to real data, or not yet supported after launch.

The parts a digital product may have

Take a web-based booking system as the example. A person opens a form in a browser or a mobile app. When they click the button, the client program sends the server a network request containing the chosen time and the other required data. The server checks the booking rules and the person's access rights, reads or changes a record in the database, and returns a response to the client program, which shows the result to the person. The confirmation email can be sent separately: a delay or failure in sending it does not necessarily cancel a booking that has already been saved.

This is one possible path, not a requirement for every product. A small website may have no database and no separate server-side logic at all. A large platform may have several applications, several databases, external providers and many servers.

A client is a program that asks another program to do something. In the example, the browser is the client of the server. A server is a computer or a program that accepts requests and answers them. The same piece of software can be a client in its dealings with one service and a server in its dealings with another. MDN (originally the Mozilla Developer Network, now called MDN Web Docs) explains this distinction in a dedicated article, What is a web server?.

The frontend is the part a person interacts with directly: form fields, buttons, text, accessibility and the way results are displayed. The backend is the server-side logic: checking rules, handling requests and working with data. The boundary between them does not always line up with team names or programming languages. MDN describes client-side code as the browser code that governs a page's behaviour, and server-side code as the code that decides what goes into a response and works with data.

An API (application programming interface) is an agreed way for one program to ask another for data or for an action. The person clicks a button, the frontend builds a request to the API, and the backend validates it and returns a result. An API can be internal to the product or belong to an external provider. The mere existence of an API tells you nothing about which business rules it enforces. MDN explains web APIs as an interface through which pieces of software interact.

A database stores structured state, such as the list of available hours and the confirmed bookings. A relational database organises this data into tables; the PostgreSQL tutorial describes tables as the primary place where data is kept. File storage is best understood as a place for documents, images and other files; it is not the same thing as tables in a database, although a single product may use both kinds of storage. A product does not need separate file storage if it accepts no files or works only with structured fields; when files are needed, the right approach depends on their size, who needs access, how long they must be kept and how reliable storage has to be. Storage systems differ: for instance, a guide from AWS (Amazon Web Services) compares hierarchical file systems with object storage (AWS guide).

Authentication establishes who is contacting the system, or whether the credentials presented are valid. Authorisation checks which data and actions are permitted to that person. Someone can log in to their account successfully and still have no right to change another client's booking. A public page, on the other hand, may be open to everyone without logging in.

These are different checks: authentication confirms an identity or a set of credentials, while authorisation decides what that identity is allowed to do. Being logged in does not mean having access to every record and every function. OWASP (the Open Worldwide Application Security Project) explains both concepts in its guidance on authentication and authorisation.

A background job is work the system does separately from its immediate response to a person. A queue holds jobs waiting to be processed, and a worker (a processing program) picks them up and carries them out. This is useful when the work may take longer than a user's request should, must be retried after a temporary failure, or has to be rate-limited. Cloudflare's documentation, for example, describes a queue as a buffer plus a consumer process that handles messages; that is one specific cloud implementation, not a requirement for every product (Cloudflare Queues). For a small catalogue these components may be unnecessary.

A cache keeps a temporary copy of data, or of a result, that is often needed again. It can speed up responses or reduce repeated calls to a slow source. But a cache raises a freshness question: what should happen when the underlying data has changed and the copy is still old? A cache may be pointless if the data is rarely read, if the source already responds quickly enough, or if every read must show the very latest state; keeping a cache consistent costs extra complexity. MDN's guide to HTTP caching explains both the benefits of reusing responses and the risk of serving stale data or sharing data with the wrong people.

From an address to a response on the internet

When a browser opens a website address, the DNS (Domain Name System) helps find the network information needed to reach the server. A domain name such as example.com is a name convenient for humans; the network information tells programs where to send the request. DNS does not store the website itself and does not run its business logic. Once the address is resolved, the client sends its request to the server. MDN explains the general path from an address, through DNS, to a request to a web system.

HTTP (Hypertext Transfer Protocol) sets the shared rules for requests and responses in web systems. A request usually contains the address of a resource and an intent, such as fetching or changing data; the response contains the result plus information that helps explain what happened. This is a simplified description: the precise behaviour is defined by the specification HTTP Semantics, RFC 9110 (an RFC, or "Request for Comments", is one of the series of documents that define the internet's technical rules). HTML (HyperText Markup Language) describes the structure of a web page that a browser can display. Web systems also deliver styles, program code and other data.

Hosting is the service or infrastructure where a web program is stored and run. The cloud is a way of obtaining computing resources, networking, storage and software services over the network, with the ability to manage how much you use and how it is configured. NIST (the US National Institute of Standards and Technology) gives a stable baseline definition of this model in SP (Special Publication) 800-145. "In the cloud" does not mean "without servers": the servers physically exist, but the customer often does not have to buy and maintain them.

A CDN (content delivery network) is a network of servers that can cache some content closer to the people requesting it. This can speed up file delivery and help absorb load. A CDN usually does not replace the main place where the product handles requests and stores data; its exact capabilities depend on the provider and the configuration (Cloudflare overview).

From a file to a running program

Code is the text instructions a program follows to do its work. A runtime is the program or system that executes code and provides it with the capabilities it needs. An environment is a specific place and set of settings in which a program is developed, tested or used: a developer's computer, for example, a test environment, or the production environment, where the product is live for its real users. JavaScript code in a browser and the same code on a server can run in different surroundings and be allowed to do different things.

A library is ready-made code that another program uses for a specific function. A framework is a set of structures and rules that helps organise a program; it often dictates part of how the program plugs in its own code. A package is a unit that can be installed or distributed within a particular ecosystem. A dependency is an external package, library or service that the application relies on to work. These words partly overlap, and exactly what "package" means depends on the language and the tooling.

A build is the process of preparing code or resources to run or to be distributed. It can produce generated files that should not be edited by hand when their source lives somewhere else. A container is a way of packaging a program together with some of the dependencies it needs into a portable image. It helps run the same bundle in different environments, but on its own it does not prove that the program is secure or correctly configured (Docker's introduction to a containerised application).

The whole product life cycle

These steps give a general map of the work, although in practice they often alternate and repeat:

1. Need: people have a problem or an outcome they want.
2. Research: the team clarifies who has the problem, how it shows up and what has already been tried.
3. Requirements and design: the team agrees on the expected behaviour and the shape of the interaction.
4. Implementation: the team changes code, data, configuration or other parts of the system.
5. Verification: the team gathers evidence that the required scenarios work and that the risks are acceptable.
6. Release: the team makes the change available to users in the chosen environment.
7. Operation: the team watches how the system runs, responds to failures and keeps it supported.
8. Feedback: the team finds out whether the change produced the expected result and decides what to do next.

A team may, for example, be researching a new need, supporting an earlier feature and preparing a release all at the same time. What matters is that responsibility for the outcome continues after the code is written.

Who is responsible for the work

The process may involve a product decision owner, a designer, an engineer, a tester and an operations specialist. In a small studio one person may cover several of these roles, but the work itself does not disappear. Someone has to decide which problem the product solves; someone, whether the interaction makes sense; someone, how to implement the rules; someone, what evidence is needed; and someone, what to do once the system is running after release.

In a studio it is also important to distinguish the buyer from the user. The buyer approves the spending or the terms; the user does the work inside the product. Sometimes they are the same person, sometimes not. If a dashboard is wanted by a manager for reporting but used every day by an administrator, talking only to the buyer can miss the main operational need.

An in-house product team usually invests in its own product, chooses its own target users, and after release is responsible for supporting it and for the consequences of its decisions. On a client project, the studio works under a contract with the customer: the client funds an agreed scope, makes the business decisions, and determines who pays for and carries out ongoing support. The users may be the client's employees or the client's own customers. The contract does not remove the studio's professional responsibility for the quality of its work, but the allocation of risk, acceptance and support has to be agreed explicitly; a role title alone does not settle it.

AI (artificial intelligence) can help search through code, draft text, explanations and tests, and analyse options. An AI agent is a system that uses a model together with the tools it has been given to carry out a sequence of actions, such as reading files or preparing changes. The model does not automatically gain access to a repository, an external service or the production environment: that depends on the product, the tools and the permissions. The person or team responsible for the product sets the limits of the agent's work and decides whether to accept and release its changes.

Specific products and APIs provide different tools and permissions. For example, the Claude Code documentation describes reading a codebase, editing files, running commands and integrating with development tools. The Codex page describes a coding agent, while OpenAI's guide to code generation through the API describes a separate way of working through the API. These capabilities cannot be assumed to carry over to any model or chat; the course looks at each of these systems separately.

Example: the booking exists even though the email was not sent

Situation. A client picks a free consultation slot and clicks "Book". They expect to see a confirmation and receive an email.

Action. The browser collects the name, email address and chosen time and sends them in a request to the API. The server checks the format of the data, checks again that the slot is still available, and saves the booking in the database. The second check on the server matters: data in the browser can be tampered with, and two people may pick the same slot at almost the same moment.

Result. If the server has saved the booking successfully, it returns a response with a booking number or some other confirmation. The browser shows "Slot booked". After that, the server or a separate background job asks the email provider to send the message.

What went wrong. The booking has been recorded, but the email service did not respond for a while. If the interface says "booking not created", the client may click again and create a duplicate. If it says "email sent", that is untrue. The honest state is: the slot is booked, the confirmation is visible in the interface, and the email is waiting to be retried. The team can store the notification's status and retry delivery according to defined rules.

Why. The database and the external email provider are different systems. An operation is called atomic when it either completes entirely or leaves no partially applied result behind. Saving the booking and sending the email are separate actions here, so the booking's status and the notification's status have to be tracked separately.

Alternative and limits. For an internal prototype, the email can be sent without a separate queue, with a clear failure status shown. For a real product, repeated requests, duplicates, the email provider's limits and the urgency of the message may call for a different approach. The specific implementation depends on business rules, not just on the choice of technology.

Example: three studios hear "Build us a dashboard"

Situation. The owner of a small service company asks for "a dashboard where I can see the orders". The phrase describes a desired solution but does not yet explain the problem.

The page-selling approach. The studio immediately proposes a mock-up and a list of screens: an order list, an order card, a filter. This can be appropriate when the needs have already been clarified and the client has ready-made rules. The risk is building tidy pages without finding out which decisions they are supposed to support.

The time-selling approach. The studio agrees to work by the hour and shows completed changes once a week. This can suit uncertain or shifting work, provided both sides manage priorities and budget openly. The billing format alone does not guarantee that the team understands the right problem, and it does not mean expert judgement is unnecessary.

The diagnostic approach. The studio first finds out who looks at the orders, how often, what decisions they make, where the data comes from and what is currently slowing the work down. It may turn out that the manager does not need a new dashboard at all and a regular report would be enough. Or it may turn out that staff enter the same data twice, in which case integration and reducing manual work are what matter.

An expert studio's specialisation is not just a list of technologies: repeated work on a similar class of problems helps it spot typical risks faster and ask better questions. A team that often builds booking systems, for example, will know to check time zones, conflicts and repeated submissions, but it still has to confirm the specific client's rules. A report drawn from a single source may need only a small team; synchronising schedules, payments and access rights calls for the right integration experience and clear ownership of failures. The team's make-up and way of working should match the risk and the uncertainty, not a template project staffing plan.

Choice and consequence. If, after the conversation, the problem turns out to be stable with a concrete desired outcome, the studio proposes a bounded first phase with acceptance criteria. If there is not enough information, it proposes a paid diagnostic or another clearly bounded way of investigating. In this teaching scenario the client pays for the agreed phase and makes the business decisions; the client's administrators use the result every day. The client decides whether the expected outcome is worth the business risk, and the studio is responsible for the quality of the work within the contract. After release, support is provided by whichever party the agreement explicitly names; before signing, the parties agree who responds to defects and who pays for changes. This is an example of how responsibility can be divided, not a universal or legal contract model. The client gets a clear next step, and the team does not promise a feature before it understands the feature's purpose.

Useful frameworks, not universal rules. Blair Enns describes diagnosis before prescription, specialisation, and the limits of solving problems for free (Manifesto); David C. Baker connects expertise with pattern recognition and positioning (The Business of Expertise); David Maister links the nature of the work to the skills it requires and to how the firm interacts with clients (The Anatomy of a Consulting Firm). These are frameworks for a conversation, not a guarantee of income or a ready-made contract model.

Example: when a catalogue needs extra components

Situation A: a small catalogue. A company shows 120 products, and an employee changes a price a few times a week. An ordinary server-rendered page, a database and a simple admin form are enough. Adding a queue, separate server programs and several databases "because that is how big systems do it" would create new things to configure and new places to fail, with no matching benefit.

Situation B: a regular import. Now the catalogue receives thousands of changes every hour from an external supplier. Requests to the supplier may be delayed or temporarily rejected. If the whole import ran while a user was opening the page, that user's wait would depend on a slow external system.

The team can build a scheduler that creates jobs on a timetable, a queue where jobs wait, and a worker that reads the data and updates the catalogue. Every change needs retry rules and protection against duplicates: receiving the same record twice must not change a price twice or create two products. The import's status can be shown to an operator, so they can see when the data was last updated.

Result and trade-off. The catalogue page no longer has to wait for the full import, and the team has a dedicated place to handle failed attempts. In exchange, new questions appear: when is a job considered stale, who is alerted to an error, how do you find a stuck worker, and how do you resume the import without doing the damage twice?

When this design does not fit. If the import is needed once a month and takes a few seconds, a background system may cost more to maintain than simply running it directly. The goal of architecture is not to make the diagram more complicated but to deliver the needed result at an acceptable level of complexity and risk.

The repository of the open-source product Cal.diy illustrates another practical limit. In its README at a pinned commit (a commit is a recorded snapshot of a specific state of the files in Git), the team calls it a community-built scheduling platform and warns that self-hosting it requires knowledge of server administration, databases and the protection of sensitive data; for that edition it recommends personal, non-production use only. This proves nothing about the internal architecture of booking products in general, but it is a useful reminder: "the code is open" does not mean "no maintenance needed".

How to read claims that something is done

When someone says "the feature is done", ask what exactly has happened:

What is said	What it may mean	What else to find out
The code is written	Files have been changed	Does the change meet the requirements, and has the behaviour been checked?
The check passed	A specific check produced a specific result	Which scenario was checked, on which version, and what was left unchecked?
The change is released	The change is available in a particular environment	Can the intended group of users see it, and do the dependent systems work?
The outcome is achieved	The user did the job they needed to do	Is there any sign that their problem has actually got smaller?

These statements are not interchangeable. Other units in this course show how to gather evidence for each of them.

Summary

A digital product is made of behaviour, data, interfaces, rules and the people who support it. A client screen may call a server program through an API; the server program may store state in a database and ask an external service to send an email. DNS helps find the network address, hosting provides a place to run, and the cloud offers a managed way to obtain computing resources. Depending on the task, there may be fewer of these components or more.

A studio's work starts with understanding the need, not necessarily with a chosen technology. Roles can be combined, but someone still has to make the decisions about value, implementation, verification and support. An agent can help with actions, but its tools and authority depend on the product, its configuration and the permissions of the specific environment.

Sources and further reading

• MDN Contributors, How the web works, page updated 20 July 2026; accessed 23 September 2026. Used for client, server, DNS, HTTP and the general path of a request. The simplified networking analogy is not treated as a complete description of all modern protocols.
• MDN Contributors, What is a web server?, no publication date given; accessed 23 September 2026. Used for the distinction between a server as hardware and as HTTP server software, and between static and dynamic serving of content.
• MDN Contributors, Introduction to the server side, page updated 11 April 2025; accessed 23 September 2026. Used for the boundary between client-side code in the browser and server-side logic. PostgreSQL Tutorial: Concepts, current version of the documentation; and AWS, Choosing a storage service, a current vendor guide with no fixed revision date; accessed 23 September 2026. Used as examples of table-based storage and of file and object storage systems; the AWS guide is not presented as a universal model of all storage.
• MDN Contributors, Introduction to web APIs, and About MDN, pages with no fixed publication date; accessed 23 September 2026. The first explains the role of an API between programs; the second confirms the historical name Mozilla Developer Network and the current name MDN Web Docs.
• MDN Contributors, HTTP caching, continuously updated documentation with no stated publication date; accessed 23 September 2026. Used for response reuse, cache freshness and the risk of leaking personalised content.
• Cloudflare Learning Center, What is DNS? and What is a CDN?, no publication date given; accessed 23 September 2026. Used for the role of DNS and for caching content closer to clients. These are a service provider's materials, so they do not describe every possible CDN architecture.
• Cloudflare, How Queues Works, service documentation with no stated version date; accessed 23 September 2026. Used as an example of a buffer and a worker consumer in a managed queue; the details are attributed to Cloudflare specifically.
• IETF (Internet Engineering Task Force), R. Fielding et al., RFC 9110: HTTP Semantics, June 2022; accessed 23 September 2026. Used for the definition of HTTP as a request-response protocol and for the limits of what can be inferred from a single message.
• OWASP Foundation, About OWASP, no stated publication date, together with the Authentication Cheat Sheet and the Authorization Cheat Sheet, continuously updated guidance with no stated edition date; accessed 23 September 2026. Used for OWASP's full name and for the difference between verifying an identity or credentials and permitting a specific action.
• NIST, Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing, SP 800-145, September 2011; accessed 23 September 2026. Used as a stable baseline model of cloud resources, not as a description of any particular provider.
• Docker Docs, Build and share a containerized application, no publication date given; accessed 23 September 2026. Used for images, containers and an example of a system with several parts. This is a Docker example; containerisation details may differ between tools.
• Anthropic, Claude Code overview, documentation page with no publication date; accessed 23 September 2026. Used for a verified description of Claude Code's capabilities as a tool for working with a codebase; exact features may change.
• OpenAI, Codex and Code generation, product and documentation pages with no fixed edition date; accessed 23 September 2026. Used to distinguish a coding-agent product from working directly with the API and models. Product pages change; no features absent from these sources are attributed here.
• David Maister, The Anatomy of a Consulting Firm, 2004, a chapter from The Advice Business adapting material from his books on professional services; accessed 23 September 2026. Used to link the nature of consulting work to the skills it requires and to client interaction; no claim is made to have read the books in full.
• Blair Enns, The Win Without Pitching Manifesto, the author's page about the book and its twelve tenets; accessed 23 September 2026. Used to attribute diagnosis before prescription and positioning; this is not a guarantee of commercial results.
• David C. Baker, The Business of Expertise, the author's page about the book; accessed 23 September 2026. Used to link expertise with pattern recognition and positioning; the available page does not substitute for the full text of the book.
• Cal.com, Inc., Cal.diy README at commit 54343aa685ae8f33159d2f485ec4a57bad5c574a, accessed 23 September 2026. Used only as an openly documented example of warnings about self-administration and about the intended use of a specific edition; no conclusions are drawn about undocumented internal details of the product.