Design
Architecture, design and price are the same decision
The architecture decision sets which screens are cheap to build. The design decision sets how much of the work repeats. The pricing model is the promise that it will. Three meetings, one decision.
Architecture, design and price are the same decision because each of the three sets the limit on what the other two can be. The architecture decides which screens are cheap to build. The design decides how much of a delivery repeats at the next customer. The pricing model is a promise about that repetition. Choose one of them without the other two in the room, and you have chosen all three anyway.
The decision is usually taken across three meetings, with three agendas and partly different people. That is where the connection disappears.
What does it mean that the three decisions are one decision?
That the three decisions are one decision means a change in any of them carries a cost in the other two, and that the cost falls due long after the decision was taken. The architecture meeting is about operations and scale. The design meeting is about what the user sees. The pricing meeting is about margin. All three answer the same question: how much of this should be the same next time?
A company that answers “a lot” in the architecture meeting and “very little” in the design meeting has sold a fixed price it cannot cover. The mistake does not surface in any of the three meetings. It surfaces in the fourth delivery project, when the margin is gone and nobody can point to the decision that took it.
How does an architecture decision turn into a price?
An architecture decision turns into a price through how many times the work can be reused. Shared infrastructure and a common component library make the next delivery cheaper than the last, and that is the technical condition a subscription rests on.
| The architecture decision | What the designer can draw | What the salesperson can promise |
|---|---|---|
| Shared platform, several customers on one core | Screens are assembled from existing components | A fixed monthly price |
| A separate codebase per customer | Every screen can be drawn freely | Hourly rates, or a fixed price with a risk premium |
| A shared design system wired into the front-end code | Changes land in every project at once | Maintenance can be sold as a subscription |
| Integration built per customer | The interface can follow the customer's own system | Each integration is priced on its own |
| API-first from the start | Two interfaces must be drawn, one for people and one for machines | Usage can be priced, not only seats |
The last row is the one changing fastest right now. A product used by an agent as much as by a person has two interfaces and therefore two design jobs. The pricing model that fits is rarely the one that fit when only people logged in.
Over 80% of the functionality in the apps you use daily is the same. It just looks a little different.
What the AppCloud decision settled about the price
AppCloud is Apps AS's own low-code platform for designing, building and operating web and mobile applications on shared infrastructure. AppCloud was sold at a fixed monthly price covering all three of those parts. That price was possible because four decisions had already been taken, and all four were technical or design decisions with a direct consequence for what could be sold.
Apps AS standardised the design in a shared design system in Figma, with components and templates that had been used before. The definitions were pulled out through Figma's API and into the front-end code, which was standardised on Flutter and React. The infrastructure was shared across projects. Configuration and follow-up sat in a separate management interface, which Apps AS used internally and the customer used directly.
None of the four points looks like a pricing decision. Together they are the entire pricing decision. A fixed monthly price assumes the next project costs less than the last, and those four points are how the assumption was met.
What happens when the customer asks for one more screen?
A request for one screen outside the component library is a pricing change, and it is worth treating as a pricing change in the meeting where the request comes up. Drawing the screen itself is cheap. The expensive part is that the screen has to be maintained outside the system every time the system changes.
The rule is that a departure from the component library requires someone to say yes to the maintenance cost, not only to the drawing. If the departure is worth it, the component becomes part of the library and is available to every project. If it is not worth it, the screen is drawn with the components that already exist.
The same mechanism is described from the designer's side in Design is where a technology choice gets cheap. The choice between native, React Native and Flutter is the technical decision with the clearest effect on both of the other two, and it is covered on its own in Should I choose native, React Native or Flutter?.
What do the three decisions mean when the interface is an agent?
When the interface is an agent, the permission model is the design, and the design is the pricing model. What the agent is allowed to do is an architecture decision. What a person must see before approving follows directly from that architecture decision. Whether you can sell outcomes instead of access follows from both.
The approval surface has to show the action the agent intends to take, the arguments it intends to take it with, and which of them cannot be undone. An interface that shows only a summary of what the agent thinks it is about to do gives no real approval. The person says yes to a summary and becomes responsible for an action.
If the action can be undone, you can sell the outcome, because you can guarantee to put it right. If the action cannot be undone, you are still selling access and an approval surface, whatever the proposal says. How the risk moves once software acts on its own is covered in What changes when software acts on its own. The operations side of the same decisions is in Personalization is an operations task, not a campaign.
Three questions that belong in the same meeting
Ask the three questions in one meeting, and write the answers on one sheet.
The three questions
What is the same next time? The answer is the limit on how much of the delivery can carry a fixed price.
What has to be drawn from scratch? The answer is the part of the price that has to stay variable, whatever the customer asks for.
What cannot be undone? The answer decides what a person has to approve, and therefore what you can guarantee.
Why the connection is most expensive to miss when the company owns the product itself is in What building our own products teaches us.
Bring the price into the architecture meeting
Have an architecture decision on the table right now? Write down the three answers above for that specific decision and send them to hello@apps.no. We will reply with the pricing model those three answers point to, and which of the three we would change first.
Sources
About this article. Written by Espen Hareide, co-founder and partner at Apps. Anchor article for the pillar Design, technology and business as one decision. The details about AppCloud, including the halved delivery time and the quotation about eighty percent, come from Apps AS's own AppCloud case page, read 23 September 2026. How many projects sit behind the halved delivery time is not stated on the case page and is not estimated here. AppCloud is no longer in operation, and the reason is not documented. The article uses no customer figures.
FAQ
- Who actually needs to be in that meeting?
- The person who owns the architecture, the person who owns the design system and the person who owns the margin. That is usually three people, and the point is that they answer the question of what should be the same next time at the same time and out loud. If gathering them is not practical, the minimum version is that one written decision passes all three of them before any of them answers the customer.
- What do we do if the price has already gone out and the architecture will not carry it?
- Work out what the departure costs per delivery before you negotiate, so the conversation is about a figure rather than about blame. After that there are two real options: bring the delivery back to what can be reused, or keep the bespoke work and change the pricing model at renewal. Keeping both is the most expensive version, and it is also the most common one.
- Does this apply when we buy a finished platform instead of building our own?
- Yes, and the connection is tighter, because the vendor has already taken the architecture decision for you. What you are buying is a limit on what your designers can draw, and that limit decides what you can promise your own customers. It is worth reading the platform's price list as a design specification, because in practice that is what it is.
- How many departures from the component library can one project carry?
- Set a limit as a number and hold it, rather than judging each departure on its merits. Three to five departures in a project is manageable if someone has said yes to maintaining them. The advantage of a number is that it forces a ranking, while a case-by-case judgement almost always ends in yes.
- Can we price per outcome when we use a model from a vendor we do not control?
- You can price per outcome on the part of the workflow you are able to put right again, whatever vendor supplies the model. What decides it is not who owns the model but whether the action can be undone. If the answer is no, you are selling an approval surface and a liability, and the price should say so.
