◉ From decision to operated system Four controlled investment decisions ZDS · Selected engagements § 01

Decide what matters. Prove it works. Build it properly. Keep improving.

Move from a promising opportunity to a working, operated system.

Zalo Design Studio (ZDS) keeps commercial intent, senior technical judgement and hands-on delivery connected. Start with the smallest responsible commitment, create evidence before increasing investment and design production systems to be operated and improved.

Lees in het Nederlands
  1. 01 Decide Decision Sprint
  2. 02 Prove Working Pilot
  3. 03 Build Build & Modernise
  4. 04 Continue Systems Partner

§ 02 / Optional orientation

Start broad only when the opportunity is still broad.

In about four minutes, you receive an immediate initial assessment of your situation, including key signals and a practical next step. If you want a deeper analysis, you can request a personalised report and then decide whether a conversation would be useful.

The assessment is not a paid stage and does not commit you to an engagement. Customers with sufficient evidence may start directly with a Working Pilot or Build & Modernise.

Assess one current opportunity

Investment path

Enter where the evidence supports you.

The assessment can help orient an unclear opportunity. Each paid stage creates standalone value, and existing evidence can support a direct Pilot or Build entry.

Optional orientation Four-minute assessment Assess, talk, or stop

Existing evidence may support direct entry

  • Prove
  • Build
  1. 01 Decide

    Decision Sprint

    A defensible investment decision

    Proceed, reshape, defer, or stop

  2. 02 Prove

    Working Pilot

    Evidence from one working loop

    Build, iterate, or stop

  3. 03 Build

    Build & Modernise

    An operable production capability

    Launch, phase, transfer, or hold

  4. 04 Continue

    Systems Partner

    Sustained operation and improvement

    Continue, change, expand, or exit

Orientation is optional. Decide, Prove, Build, and Continue each end in an explicit investment decision.

§ 03 / The commercial path

Four commitments. One evidence-led path.

Each engagement answers a different investment question, creates standalone value and ends with an explicit choice. Commitment grows only when the available evidence supports it.

This is not a mandatory funnel. Enter at the stage your sponsor, evidence, scope, constraints and production outcome support.

  1. 01 / Decide

    Engagement

    Decision Sprint

    Duration
    Five working days
    Investment
    €3,500 fixed, excluding VAT

    The question you answer

    Is this opportunity worth pursuing, what should we build or change, and what is the smallest responsible next investment?

    The promise

    Turn one important but uncertain software, cloud, automation or AI opportunity into an evidence-backed investment decision in five working days.

    When to use it

    • One consequential workflow, system, product or investment decision needs clarity.
    • The cost, delay, risk or opportunity is material.
    • A sponsor can provide access to relevant people and non-sensitive evidence.

    What happens

    • Frame the decision, outcome, owner, boundary and decision criteria.
    • Map the workflow, systems, data, integrations, exceptions and controls.
    • Test desirability, feasibility, viability, security, privacy, operability, cost and build, buy or integrate options.
    • Shape the recommended architecture, scope, success measures, dependencies, milestones and investment range.

    Evidence you receive

    • A concise decision report with credible options, trade-offs and a recorded decision.
    • Current-state workflow and system map.
    • Evidence, assumptions, options and trade-off register.
    • Recommended boundary, architecture and bounded Pilot or Build plan.
    • Acceptance conditions, dependencies, milestones and investment range.

    Decision at the end

    Proceed, reshape, defer or stop.

    Discuss a Decision Sprint

    Decision Sprint

    Five days. Evidence accumulates. One decision lands.

    The sequence turns an uncertain opportunity into a bounded decision case. The work can still conclude that the responsible choice is to reshape, defer, or stop.

    Before start Confirm owner, scope, inputs, exclusions, and access
    1. Day 1 Frame
      Work
      Define the decision
      Evidence created
      Decision statement and criteria
    2. Day 2 Map
      Work
      Understand operating reality
      Evidence created
      Workflow, systems, and evidence gaps
    3. Day 3 Test
      Work
      Reduce material uncertainty
      Evidence created
      Options, trade-offs, risks, and boundary
    4. Day 4 Shape
      Work
      Make the next stage buildable
      Evidence created
      Architecture, measures, plan, and range
    5. Day 5 Decide
      Work
      Challenge the recommendation
      Evidence created
      Proceed, reshape, defer, or stop
    Evidence accumulates toward the executive decision case
    Readiness is established before day one. Each day adds evidence to the final sponsor decision.
  2. 02 / Prove

    Engagement

    Working Pilot

    Duration
    Typically three to five weeks
    Investment
    From €18,000, excluding VAT

    The question you answer

    Does one valuable workflow work well enough, with the right users, systems, controls and economics, to justify production investment?

    The promise

    Prove one valuable operational loop with a working system and evidence agreed before the build begins.

    When to use it

    • One outcome, accountable owner and bounded end-to-end workflow are clear.
    • Material data and integration access is feasible.
    • A credible production path exists if the Pilot succeeds.

    What happens

    • Agree a baseline, hypothesis, success thresholds, observation period and stop conditions.
    • Build the minimum production-intent vertical slice from trigger to outcome.
    • Include material integrations, operator experience, human controls, exceptions and fallback behaviour.
    • Run agreed scenarios or a controlled canary and compare the result with the evidence contract.

    Evidence you receive

    • Working limited-release workflow or product capability.
    • Architecture, code, configuration and agreed integration artifacts.
    • User, operator, scenario, exception and failure evidence.
    • Technical performance, quality, cost and operating evidence.
    • Production-gap assessment and bounded recommendation.

    Decision at the end

    Build, iterate, choose a different approach or stop.

    Discuss a Working Pilot

    Working Pilot

    A Pilot is an evidence loop, not a polished demo.

    One bounded operational workflow is built and observed against criteria agreed before implementation begins.

    One bounded workflow One owner · Real controls · Production path
    1. 01
      Contract

      Baseline, threshold, scenarios, stop conditions

    2. 02
      Build

      Production-intent slice from trigger to outcome

    3. 03
      Operate

      Users, integrations, exceptions, and human control

    4. 04
      Measure

      Function, quality, reliability, latency, and cost

    5. 05
      Decide

      Compare the result with the evidence contract

    BuildIterateStop
    The evidence contract keeps the hypothesis, workflow, measurement, and final investment decision connected.
  3. 03 / Build

    Engagement

    Build & Modernise

    Duration
    Six weeks or more
    Investment
    From €35,000, excluding VAT

    The question you answer

    How do we turn the accepted decision or Pilot evidence into a dependable, secure, observable, maintainable and owned production capability?

    The promise

    Build, rescue or modernise the production system with operation, ownership and measurable release evidence designed in.

    When to use it

    • The sponsor owns budget, priority and decision rights.
    • The production outcome and acceptance boundary are explicit.
    • Material constraints are understood or assigned to bounded early milestones.
    • Operational ownership after release is agreed.

    What happens

    • Translate accepted evidence into outcome milestones and vertical production slices.
    • Engineer software, data, AI, integrations and fit-for-purpose infrastructure.
    • Design identity, security, privacy, delivery, observability, recovery, cost and ownership into the system.
    • Release through controlled environments and explicit production gates.

    Evidence you receive

    • Running production system or accepted modernisation milestones.
    • Source, infrastructure, configuration and deployment assets within the agreed ownership model.
    • Tested integrations, data boundaries and control evidence.
    • Observable service and business-outcome signals.
    • Release, recovery, operating, handover and residual-risk records.

    Decision at the end

    Launch, phase the release, hold for missing evidence, transfer operation or enter a defined Systems Partner roadmap.

    Discuss Build & Modernise

    Build & Modernise

    Production discipline travels with the system.

    The right environment follows the customer problem. AWS is proven ZDS experience, not a mandatory destination.

    • Public cloud
    • On-premises
    • VMware
    • Hybrid
    Portable production boundary
    1. Experience Customer and operator journeys
    2. Application Software, workflows, AI, and integrations
    3. Information Data, identity, consent, permissions, and secrets
    4. Delivery Infrastructure as code, tests, CI/CD, staged release, and rollback
    5. Operation Observability, recovery, security, privacy, cost, and service objectives
    Named ownership Runbooks · Enablement · Support boundary

    Proven ZDS operating experienceServerless AWS

    Cloud, on-premises, VMware, and hybrid environments require the same explicit engineering of operation, control, and ownership.
  4. 04 / Continue

    Engagement

    Systems Partner

    Duration
    Initial three-month commitment
    Investment
    From €8,000 per month, excluding VAT

    The question you answer

    How do we operate and improve the system against business outcomes while managing reliability, security, cost, quality and change?

    The promise

    Operate and improve what matters through one priority queue, explicit monthly outcomes and evidence that connects system health to business value.

    When to use it

    • There is a concrete recurring roadmap or operating responsibility.
    • Leadership access, decision rights and one ordered outcome queue are explicit.
    • Capacity, service boundary, cadence and an exit or handover path are agreed.

    What happens

    • Review outcome movement, service health, cost, risks and learning.
    • Choose explicit monthly outcomes from one priority queue.
    • Design, build, release and measure the selected work.
    • Reset the roadmap quarterly using business, workflow and system evidence.

    Evidence you receive

    • Operating and improvement releases tied to agreed monthly outcomes.
    • Business, workflow and service-health evidence.
    • Cost, reliability, security and AI-quality decisions.
    • Transparent roadmap, risks, capacity and progress.

    Decision at the end

    Continue, change, expand, hand over or exit.

    Discuss a Systems Partnership

    Systems Partner

    Three evidence loops inform one priority queue.

    Business movement, product learning, and system health are reviewed together before the next monthly outcome is selected.

    One ordered priority queueChoose · Build · Release · Measure
    1. Customer and commercial outcomes

      Usage · Conversion · Cycle time · Exceptions · Experience

    2. Product and workflow improvement

      Evidence · Experiments · AI quality · Releases · Adoption

    3. System health

      Reliability · Security · Privacy · Cost · Recovery

    Monthly outcomeChoose · Build · Release · Measure

    Quarterly roadmap decisionContinue · Change · Expand · Hand over · Exit

    The engagement buys explicit outcomes and controlled capacity, not an undifferentiated bundle of hours.

§ 04 / Capabilities

Capabilities you can apply to your own system.

ZDS combines the disciplines the outcome requires. These are not a fixed technology menu or a requirement to copy our topology.

01

Workflow and service redesign

Connect customer intent, staff work, decisions, exceptions and measurable outcomes.

02

Software and product engineering

Create operator tools, customer journeys and product capabilities that can be released and owned.

03

Agentic and generative AI systems

Coordinate specialist roles, models, evidence, media, tools and human judgement inside a governed workflow.

04

Portable integration and infrastructure

Design for cloud, on-premises, VMware or hybrid environments, with AWS as proven experience when it fits.

05

Operational controls

Build identity, consent, policy, observability, recovery, measurement and cost operation into the system.

06

Growth and content operations

Connect assessment, CRM, campaigns, generation, approval, publishing, receipts, measurement and learning.

§ 05 / Built and operated by ZDS

A connected capability architecture, not a collection of claims.

ZDS uses its own systems to prove that public journeys, private operations, agentic workflows and production controls can work as one governed architecture.

Connected ZDS capability architecture

From public opportunity to measured operating loop.

ZDS builds and operates the connected components behind its own growth system. The same disciplines can be recombined around a customer outcome.

Public journeyPrivate operations
  1. 01 Orient and qualify
    • Assessment
    • Personalised report
    • Booking
    • Consent
  2. 02 Connect safely
    • Authenticated handoff
    • Duplicate-safe delivery
    • Retry and replay
    • Observable receipts
  3. 03 Plan and create
    • CRM and campaigns
    • Research and planning
    • Text and images
    • Carousels and reels
  4. 04 Review and deliver
    • Human review
    • Approval policy
    • Scheduling
    • Publishing and receipts
  5. 05Channels and owned experiences
    • Website
    • LinkedIn
    • Meta
    • Other approved channels
Measurement and learning return to the next decision

Configurable autonomy with human judgement at material decisions

Production foundationReplaceable provider and infrastructure boundaries
  • Event-driven integration
  • Identity and data boundaries
  • Infrastructure as code
  • Observability and recovery
  • Cost operation
This is ZDS operating evidence, not a fixed customer topology. Providers and infrastructure remain replaceable components.
01

AI & Software Opportunity Assessment

What exists
A bilingual assessment, deterministic scoring, personalised report, booking and consent journey built and operated for ZDS.
What this demonstrates
Product journey design, privacy-aware data boundaries, asynchronous reporting and a usable path from question to conversation.
Why this matters
A customer journey can combine software and AI without making every decision probabilistic or collecting unnecessary data.
02

Connected Growth System

What exists
An authenticated, idempotent, retryable and observable handoff between the public serverless journey and private operational systems.
What this demonstrates
Cross-system integration, consent-aware CRM state, campaign coordination, recovery and replayable evidence.
Why this matters
Public and private systems can remain separately controlled while still supporting one end-to-end operating journey.
03

Agentic Marketing System

What exists
A substantial working system for research, planning, text, image and reel generation, review, scheduling, publishing and measurement that ZDS continues to improve.
What this demonstrates
Configurable autonomy, multiple AI and channel providers, durable workflow state, policy controls and operational receipts.
Why this matters
Agentic software can coordinate a real operating loop instead of adding another disconnected assistant.
04

Production and integration foundation

What exists
Serverless AWS components developed, deployed and operated with infrastructure as code, controlled releases, monitoring, recovery and cost operation.
What this demonstrates
Event-driven architecture, explicit data authority, safe retries, failure isolation, observability and operational ownership.
Why this matters
The same production disciplines apply across AWS, another cloud, on-premises, VMware or hybrid infrastructure. No platform is automatically the right choice.

§ 06 / Evolution

Build, operate, learn, retire, improve.

Armature was a ZDS-built delivery environment. We developed it, deployed it, used it and deliberately retired it when the operating model and stronger capabilities evolved. The useful principles remain without turning a retired system into a current product or framework.

A completed chapter

Learn. Operate. Retire. Evolve.

Armature was built and operated as an internal system. ZDS retired it when the environment and stronger capabilities moved on.

  1. 01 Learn

    Structure before speed

  2. 02 Operate

    Codify decisions and handoffs

  3. 03 Retire

    Remove what no longer earns its place

  4. 04 Evolve

    Carry the useful principles into stronger systems

What remains
  • Explicit decisions
  • Reproducible handoffs
  • Controlled execution
  • Clear ownership
The former system is historical provenance, not a current product, framework, offer, or customer dependency.

§ 07 / Engagement principles

How ZDS keeps investment risk and delivery connected.

  1. 01

    Evidence before investment

    Increase commitment only when the current stage has answered its material question.

  2. 02

    One accountable decision

    Every stage has an owner, boundary, evidence and exit choice.

  3. 03

    Working systems over demonstrations

    Test the end-to-end workflow, material integrations, human controls and operating reality.

  4. 04

    Production is designed for operation

    Security, reliability, observability, cost, recovery and ownership are part of the system.

  5. 05

    Improvement continues after launch

    Connect business outcomes, workflow evidence, system health, AI quality and cost to the roadmap.

§ 08 / Questions

Common questions

FAQ
What happens after the four-minute assessment?

You immediately receive an initial assessment of your situation, including key signals and a practical next step. If you want a deeper analysis, you can request a personalised report and then decide whether to book a conversation. The assessment is optional orientation, not a paid stage or a commitment to engage ZDS.

Do we have to start with a Decision Sprint?

No. Start with a Decision Sprint when the decision, evidence, scope or constraints are still unclear. You may start directly with a Working Pilot or Build & Modernise when the sponsor, evidence, boundary and intended production outcome are already strong enough to review.

What exactly does a Decision Sprint produce?

It produces a concise decision case, current workflow and system map, evidence and assumptions register, credible options and trade-offs, a recommended boundary and architecture, a bounded Pilot or Build plan, and an explicit proceed, reshape, defer or stop decision.

What makes a Working Pilot different from a prototype or demo?

A Working Pilot tests one end-to-end operational loop against evidence agreed before implementation. It includes the relevant users, integrations, human controls, exceptions, operating signals and economics needed to support a build, iterate or stop decision. A technical demonstration alone is not enough.

What evidence do we need before Build & Modernise?

The sponsor, production outcome, acceptance boundary, material data and integration constraints, security and privacy responsibilities, decision rights and operational ownership must be clear. Any remaining uncertainty must be assigned to a bounded early milestone rather than hidden inside a broad build promise.

Can ZDS work with our existing cloud, software and providers?

Yes. ZDS designs around the real operating boundary and can work across public cloud, private cloud, on-premises, VMware and hybrid environments. ZDS has strong production experience with serverless AWS, but AWS is an option when it fits, not a customer requirement.

Can ZDS operate and improve the system after launch?

Yes. Systems Partner connects one priority queue and explicit monthly outcomes to customer, workflow and system-health evidence. It is a defined operating partnership with agreed capacity, service boundaries and a quarterly continue, change, expand, hand over or exit decision.

What does the assessment do, and what information does it require?

The assessment asks structured questions about one opportunity, workflow and operating context. It scores the answers deterministically. Contact details are requested only when you ask for the personalised report, and consent choices remain explicit.

Are the displayed prices fixed quotes?

The Decision Sprint is fixed at €3,500 excluding VAT for its stated boundary. Working Pilot, Build & Modernise and Systems Partner show starting prices. Their final fee depends on confirmed scope, integrations, operating environment, capacity and service level.

Are ZDS's own systems customer case studies?

No. They are systems and products ZDS built and operates to demonstrate real engineering and operating capability. They are not invented client results and do not imply customer adoption, revenue, compliance certification or guaranteed outcomes.

Start with the smallest responsible commitment.

Use the assessment when the opportunity is broad. Discuss a Decision Sprint when one material decision needs to be made now.

Already have an evidence-backed Pilot hypothesis or accepted production scope? Start a direct conversation about Working Pilot or Build & Modernise. Discuss a direct entry