Cloud Vendor SoftwareArchitecture & engineering

00 · OriginSoftware architecture consultancy · Amsterdam

Software architecture is still a discipline.

Anyone can build a proof of concept now. An AI assistant will write one in an afternoon. We design and build what comes after: software that lasts, scales, stays secure and can still be changed years from now.

Discuss your system Follow the route

Scroll: from an idea to a system that lasts

01 · Proof of conceptEngineering in the age of AI

A proof of concept is not a product.

AI makes code cheap. It does not make decisions about boundaries, data ownership, security or failure.

Generated code arrives fast and looks finished. The hard questions are the same as they always were: what happens under load, when a dependency is down, when the requirements shift, when someone tries to break in, when a new developer has to change it next year.

We use AI tools where they genuinely help, and we hold their output to the same standard as any other code: a clear architecture to fit into, review, tests and a path to production. If you have a prototype that works on a laptop and now needs to run a business, that gap is exactly the work we do.

Fig. 01 Fast to build. The questions arrive later.

ApproachHow we work

Design is a decision, not an accident.

Every system has an architecture. The only question is whether someone chose it. We choose it deliberately, write it down, and hold the code to it.

  1. UnderstandWe start with the business, the constraints and what is likely to change, not with a technology choice.
  2. DesignA written architecture and a delivery plan: components, interactions, risks and the order to build in.
  3. BuildWe build it, or guide your team through building it, and keep the code and the design in step.
  4. Hand overDocumentation, standards and coaching, so your team owns the system and does not depend on us.

02 · UnderstandRequirements and volatility

Start with what will change.

Requirements will change; that is the one thing you can count on. So the first question is not which framework to use, but which parts of the business move, how often, and why.

We start with the business, the constraints and what is likely to change. The answers shape everything that follows.

Fig. 02 Map the volatility before choosing the technology.

03 · DecomposeBoundaries and services

Draw the boundaries around the change.

A system split along technical layers spreads every change across all of them. A system split along what changes keeps each change in one place.

Principle · 01
Design for changeRequirements will change; that is the one thing you can count on. We decompose systems around the things most likely to change, so that change stays contained in one place instead of rippling through everything.
Fig. 03 One block becomes components with clear responsibilities.

04 · DesignContracts, data, failure

Settle it on paper before it is settled in code.

A written architecture and a delivery plan: components, interactions, risks and the order to build in.

Principle · 02
Design before codeA few days of design saves months of rework. We settle the boundaries, the data, the failure modes and the plan before the team starts typing, and we keep the design current as the system grows.
Fig. 04 Contracts between parts, data with one owner, failure designed in.

05 · BuildCode and design in step

Build to the design, not around it.

We build it, or guide your team through building it, and keep the code and the design in step: review, tests and an automated path to production.

Principle · 03
Simple beats cleverFewer moving parts are cheaper to run, easier to reason about and harder to break. We remove complexity at least as often as we add it.
Fig. 05 The code follows the drawing; the pipeline checks every step.

06 · OperateSecure and observable

If you cannot see it, it is not finished.

Production is where the design meets reality: real load, real failures, real attackers. A system has to be ready for that on its first day, not after its first incident.

Principle · 04
Secure and operable from day oneSecurity, observability and deployment are part of the architecture, not a phase at the end. If you cannot see what a system is doing, or ship it safely, it is not finished.
Fig. 06 Security, telemetry and deployment drawn into the architecture.

07 · EvolveChange without rewrites

Change it in year three without starting over.

The route does not end at the first release. Documentation, standards and coaching mean your team owns the system and does not depend on us, and good boundaries mean a part can be replaced without touching the rest.

Principle · 05
Maintainability is a featureThe cost of software is mostly what happens after the first release. Clear structure, consistent standards and tests are what let a team keep moving in year three.
Fig. 07 Replace one part; the rest keeps running.

InterchangeServices

What we do: four ways onto the route.

Where you join depends on where your system is today.

  • Line 1Joins at 02 Understand

    Architecture consulting

    System design for new products and for systems that have outgrown their first design.

    • Service decomposition and boundaries
    • Cloud architecture on AWS and Azure
    • Monolith-to-services and legacy-to-cloud migration plans
    • Project design: sequencing, risk and realistic plans

  • Line 2Joins anywhere

    Architecture reviews and audits

    An independent, written assessment of an existing system and the team's way of building it.

    • Structure, coupling and change cost
    • Security, reliability and observability gaps
    • Infrastructure and running-cost review
    • A prioritised list of what to fix first, and why

  • Line 3Joins at 05 Build

    Development

    Hands-on delivery, on our own or embedded in your team, built to the design rather than around it.

    • Backend services in .NET, Node.js and TypeScript
    • Event-driven and asynchronous processing
    • CI/CD, containers and infrastructure as code
    • Technical leadership and mentoring of your engineers

  • Line 4Joins at 01 Proof of concept

    From AI prototype to production

    Taking fast-built prototypes, including AI-generated ones, to software that can run a business.

    • Assessing a prototype: keep, refactor or rebuild
    • Putting an architecture and standards under it
    • Guardrails for teams that code with AI assistants
    • Security and production readiness

Distance travelledExperience

A quarter century of systems that had to work.

Cloud Vendor Software was founded in 2021 by Elia Slomka, a software architect with more than 25 years in software development and over 15 years in technical leadership, across fintech, retail, homeland security, insurance, automotive and healthcare commerce, in startups and in enterprises.

25+Years in software development
15+Years in technical leadership
2021Cloud Vendor Software founded

  1. Monoliths into services

    Designed and led the decomposition of monolithic systems into microservices, including moving a .NET Framework platform to .NET Core services on Docker.

  2. Moving to the cloud

    Led a company's move to AWS and document databases, and migrated a fintech platform from Azure Service Fabric to Docker and Kubernetes, cutting deployment times by 40%.

  3. From proof of concept to production

    Helped take a fintech product from proof of concept to a scalable production system on microservices and event sourcing, and set the engineering standards around it.

  4. Modernising legacy systems

    Designed a new REST API over a legacy system to keep strategic customers, and migrated insurance systems from VB6 and classic ASP to .NET.

  5. Commerce platforms

    Moved a custom-built commerce platform to commercetools, with centralised monitoring and cost reductions from a simpler architecture, and built core server components of a retail platform delivered to a major North American retailer.

  6. Systems where failure is not an option

    Led development of a C4I security system for airport security at three airports during the 2010 FIFA World Cup, and delivered operating software for surveillance systems deployed at Heathrow Airport.

Methods

Trained in IDesign's Architect's Master Class and Project Design Master Class. We work with volatility-based decomposition, domain-driven design, an API-first approach, SOLID and test-driven development.

Technology

  • C# / .NET
  • TypeScript
  • Node.js
  • Python
  • AWS
  • Azure
  • SQL Server
  • PostgreSQL
  • MongoDB
  • DynamoDB
  • Redis
  • Kafka
  • SNS / SQS
  • Azure Service Bus
  • RabbitMQ
  • Docker
  • Kubernetes
  • Terraform

Branch lineOur own products

We build products the way we build for clients.

Alongside consulting we design, build and run our own software. It keeps us honest: every principle on this page is one we live with in production.

See our apps
Shopify appIn production

Euro B2B Smart Hub

A Shopify app for merchants selling to businesses in the EU: prices with and without VAT, VAT-number-checked B2B sign-up, and automatic EU reverse charge.

Read more about the app

Next stopContact

Tell us about your system.

A new product, a system that has become hard to change, or a prototype that needs to grow up. Send a short description and we will reply with an honest view of whether and how we can help.

contact@cloud-vendor-software.nl

Support for our apps: support@cloud-vendor-software.nl

Company
Cloud Vendor Software B.V.
Address
Reijnier Vinkeleskade 64B
1071 SX Amsterdam
The Netherlands
KvK · VAT
82531072 · NL862508009B01
LinkedIn
Company page