Solutions based on Defined Building Blocks

Why Solutions?

VSHN aims to offer self-service platform products to enable DevOps. However, many customer use cases go beyond what VSHN products or 3rd-party services offer — architecting or more complex integration is needed to address the technical business need. To handle this, we deliver Solutions: purpose-built combinations of products, reusable IT components, and professional services.

To scale this approach and avoid unclear expectations, we follow a modular concept: Solution Building Blocks – clearly defined, reusable where useful and possible, and transparently priced.

What is a Solution?

A Solution is what we deliver to close the gap between our and 3rd-party products and what is needed to address the customer’s specific technical need.

It combines:

  • VSHN or external products

  • Reusable Solution Building Blocks

  • Customer-specific Building Blocks

  • Requirements engineering, design, and setup effort

It always comes with clearly defined scope, responsibilities, and pricing.

What is a Building Block?

A Building Block (BB) is a modular element in a solution – a reusable way to describe a specific service or support we provide.

Each block defines:

  • what we do and what we don’t

  • who owns what (ops vs. support)

  • which parts are included in a monthly fee

  • which tasks are billed as effort

  • what needs to be defined specifically in the solution, and what is standard

This makes our solutions more scalable, transparent, and fair.

Once the agreed-upon scope is delivered, VSHN takes care of the defined operational responsibilities and can review the solution with the customer periodically. Improvements are then proposed and, if ordered by the customer, implemented to evolve the solution.

Distinction from Products

VSHN Products are proactively developed, standardized offerings with clear features, pricing, and platforms.

Building Blocks are more flexible, more custom, and therefore more reactive: They exist because we make them for a specific customer need. We might be able to reuse them across customers, lowering effort and cost per customer over time.

A building block may evolve into a product if there’s enough demand – but that’s not the goal.

Types of Building Blocks

We define four types. They help categorize the kind of service and our responsibility.

Type Used when Service Operator Billing

🟦 Managed Standard Software
VSHN manages standard 3rd-party software (e.g. MariaDB, Redis)

No VSHN product fits; needs reliable operations

VSHN
(partially or fully)

  • Fixed monthly fee

  • Extra effort billed

🟨 Custom Software Support
VSHN supports a customer-developed application

Customer devs own app; need hands-on support

Customer
(VSHN engineers, supports)

  • Monthly base fee

  • All effort billed

🟩 3rd-party Services Support
VSHN supports use of cloud services like Kubernetes offerings, databases, etc. (e.g. AWS, GCP, Azure)

Customer uses cloud provider services; wants help with design, engineering, and ops support

Cloud Provider
(VSHN designs, engineers, supports)

  • Monthly base fee

  • Most effort billed

🟥 VSHN Product
Productized, fully managed VSHN service

Standard VSHN product fits the use-case

VSHN

Product pricing applies; integration billable as part of the solution

Hierarchy of Building Blocks

Solutions are modular – composed of different kinds of building blocks. Some provide a base layer needed to add services; others extend services to offer additional support, more functionality, or increased operational responsibility for VSHN.

Level Description

🧱 Base

Provides foundational support or infrastructure. Not always visible to the customer but required for delivery. Can deliver value directly (e.g. Cloud Infra Support).

🛠 Service

Provides direct customer value – either by managing a technical component or by offering application or platform support.

➕ Add-On

Optional extension to a Base or Service. Enhances functionality, e.g. alert handling or backup strategy.

Responsibilities

We distinguish between two main types of responsibility. This is critical for setting expectations – especially in DevOps setups where application ownership stays with the developers (usually our customer or their software agency).

Role Description

🛠 Operations

"Managed by VSHN" – we run the service, monitor, update, and react to incidents. Applies to products and selected Managed Software Building Blocks. Usually used to build a (custom) platform that enables DevOps.

🧑‍💻 Support

"Supported by VSHN" – we design, advise, help troubleshoot, or engineer improvements. The customer remains responsible for running it. We enable DevOps.