End-to-end responsibility: how layers affect each other in BGB

01The product's context

BGB is a digital product aimed at reducing gambling-related harm. I am aware that the subject is sensitive, so in this note I make no claims about the product's impact. What I want to describe is what it is like to take on the software side of such a product end to end. This is a company project. I carried out product analysis, design and development, taking responsibility across all software layers: the mobile application, backend algorithms, management panel and website.

When working in a sensitive area, I think the right stance is to approach the person who will use the product with respect and keep the interface language plain. The software's job here is not to impress; it is to behave in a reliable, understandable and consistent way. This affects small decisions too, from word choice to the tone of error messages.

02Four surfaces, one product

The mobile experience was built with React Native and Expo, and the web and administration interfaces with Next.js. The services run on NestJS and PostgreSQL, with Prisma for data access. It is possible to think of these four surfaces as separate projects, but in BGB they are complementary parts of the same product. Mobile workflows, data and administration tools need to work together.

React Native + Expo (mobile)      Next.js (web)      Next.js (admin)
            \                          |                    /
             +----------- NestJS services ----------------+
                                  |
                         Prisma -> PostgreSQL

This layout has an important consequence: no surface can be considered “finished” on its own. The behavior of a mobile screen depends on what the service layer returns; the usefulness of a tool in the management panel depends on how the data is modeled. So work done on one surface should not be considered complete until it has been checked on the others.

03A decision in one layer

The thing I saw most clearly with end-to-end responsibility is that a decision made in one layer always has a counterpart in the others. How you define a field in the data model determines how the service presents it. The way the service presents it determines how the mobile app shows that data and which states it has to handle. How the management panel can edit the same data also depends on that same model.

When the layers belong to different people, this chain is managed through meetings and documents. When they all belong to the same person, a different risk appears: because you hold the chain in your head, you neglect to write it down. That is why I think the agreements between layers need to be defined explicitly even when working end to end.

A small decision in one layer comes back as the behavior of a screen at the other end.

04Service contracts

I tried to consider the mobile experience, service contracts and administration needs together. By service contract I mean the agreement about what an endpoint accepts, what it returns and how it behaves in which situations. With mobile apps, the versions in users' hands generally do not update as quickly as the web. That holds for mobile products in general, and it means contracts need to be changed carefully.

Having TypeScript as a common language across all layers helps here; it makes it easier to think of the same concept the same way in mobile, web and services. But a common language alone is not enough; the contract itself also needs to be designed deliberately.

05Administration needs are part of the product

In many projects the management panel is the last surface anyone thinks about. Yet a product's sustainability also depends on how comfortably the people managing it can do their work. Considering interface and backend workflows around the product's shared needs makes administration a surface designed from the start rather than an add-on. When the administration tool is weak, daily operation becomes harder no matter how good the rest of the product is.

Because I also carried out the analysis and design, from the moment I first heard about a need I could think together about what it would become on mobile, in the service layer and on the administration side. In my view, that is the most valuable part of end-to-end responsibility: being able to see all the consequences of a decision at once.

06The cost and the gain

Taking responsibility across every layer also brings the load of context switching. Moving from the detail of a mobile screen to the structure of a query within the same day takes attention. In return, the gain is significant: seeing faster which layer a problem comes from and putting the fix in the right layer. Fixing an error at its source rather than hiding it in the interface is only possible when you can see the whole chain. Being able to estimate a feature's cost across all layers at once while designing it also makes scope discussions more realistic.