Skip to content

PRODUCT-STRATEGY.md

Latest commit

 

History

History
213 lines (138 loc) · 5.84 KB

PRODUCT-STRATEGY.md

File metadata and controls

213 lines (138 loc) · 5.84 KB

DeployMate Product Strategy

Updated: 2026-04-11

Strategic Thesis

DeployMate should not try to become a general cloud platform or a Kubernetes control plane.

DeployMate should become the clearest way to deploy and operate Docker applications on your own servers:

  • self-hosted
  • provider-agnostic
  • Docker-first
  • understandable in one pass
  • safe enough for real production use

The product category is:

deployment control plane for teams running applications on their own VPS, dedicated servers, or private cloud

The Job To Be Done

The main job is still:

  1. connect a server
  2. choose what to run
  3. deploy it
  4. see whether it is healthy
  5. know the next safe action

The real promise is not only "make deploy possible".

The real promise is:

make deploy and runtime state understandable without SSH archaeology or platform-team overhead

Who The Product Is For First

Primary ICP:

  • small product teams shipping Docker services on VPS
  • web studios and outsourcing teams managing multiple client services
  • SMB teams with internal tools and one or two technical operators
  • integrators who need a simple self-hosted control layer on client infrastructure

These buyers already have servers. They do not want to become a Kubernetes team. They do not want deployment safety to depend on tribal knowledge.

Russia Market Read

The strongest local angle is not "another cloud".

The strongest local angle is:

  • Russian-language product and docs
  • works on infrastructure the customer already owns
  • not tied to one provider
  • easier than Kubernetes
  • safer and clearer than raw Docker plus SSH

This is relevant because the Russian cloud market is still growing, while provider concentration, security expectations, and infrastructure sovereignty pressures remain high.

Useful market references:

Inference:

There is room for a provider-agnostic control layer above VPS and private infrastructure, especially for teams that want deploy simplicity without handing platform control to a single cloud vendor.

Competitive Position

DeployMate should not try to beat every competitor on feature count.

That would lose against broader platforms.

DeployMate should win on:

  • clarity of the first deploy path
  • safe runtime review after deploy
  • reusable templates without platform complexity
  • operator handoff quality
  • self-hosted control on existing infrastructure

The product should feel closer to:

Render-like clarity on your own servers

not to:

yet another infrastructure dashboard

Signature Differentiator

The product-level differentiator should be:

Deployment Passport

Every deployment should have a human-readable runtime passport that answers, in one place:

  • what is running
  • where it is running
  • which image or template produced it
  • which URL, port, and health path matter
  • who owns it
  • what changed in the latest release
  • what the current risk is
  • what the next safe action is
  • how to redeploy or roll back safely

When the runtime is degraded, the same surface should switch into incident mode:

  • likely cause
  • first checks
  • safe actions now
  • escalation path

This is the best candidate for a real product "hook".

Logs, health, and status exist everywhere. A structured deployment passport is a stronger operational artifact and a better handoff surface.

Product Plan

Phase 1: First Deploy In 10 Minutes

Goal:

  • a new user can reach the first healthy service without author help

Required outcomes:

  • beginner path is obvious from /app
  • server setup, deployment workflow, and runtime detail feel like one story
  • provider presets exist for common VPS shapes
  • the product explains plain-language meanings for server, what to run, and healthy

Phase 2: Production-Useful Runtime

Goal:

  • the first deployed service is actually maintainable

Required outcomes:

  • environment variable and secret handling
  • domains and SSL as first-class flows
  • redeploy, rollback, and release review
  • better unhealthy-state guidance
  • Git or webhook-driven deploy entry points

Phase 3: Team And Agency Fit

Goal:

  • one operator can hand the service to another without losing context

Required outcomes:

  • stronger ownership model
  • workspace or client separation
  • clearer audit and activity trail
  • reusable templates as team assets
  • deployment passport and handoff quality become central, not decorative

Phase 4: Commercial Packaging

Goal:

  • the product is easy to buy and easy to justify

Required outcomes:

  • clear self-hosted commercial offer
  • agency or multi-client packaging
  • onboarding and support motion
  • Russian-language operator and install materials

Deliberate Non-Goals

Not now:

  • Kubernetes-first orchestration
  • broad platform engineering sprawl
  • trying to replace a cloud provider
  • building many advanced admin surfaces before the deploy path is excellent
  • turning Web Terminal into the center of the product story

Success Metrics

The strategy is working if:

  • a new user can explain the first two steps in under 30 seconds
  • first server to first healthy deployment becomes a short, repeatable path
  • runtime review answers the next action without reading raw logs first
  • agencies and small teams can manage several services without SSH-based tribal knowledge
  • demos convert because the product story is obvious, not because the author explains it live

Strategic Rule

If a proposed feature does not strengthen one of these:

  • first deploy clarity
  • runtime confidence
  • operator handoff
  • self-hosted deploy value

then it should not displace current priorities.