Skip to content
P Propulsive
Book a demo
Deployment & Onboarding

How a deployment gets set up and kept running

What setup actually looks like today, how environments are meant to be promoted, and where we're candid that our operational maturity is still catching up - rather than a polished claim we can't back up.

Getting started

Bootstrap & seed data

Every module ships with a setup wizard so go-live isn't dependent on undocumented manual configuration.

  • Per-module setup wizards

    Each module (CRM, HR, Accounting, Inventory, Manufacturing and more) has a setup wizard that live-computes what foundational records still need creating - a checklist, not a black box.

    Available

  • Manual mark-complete overrides

    A setup step can be explicitly marked complete by an admin if it was configured outside the wizard's own count.

    Available

  • Versioned, portable "SeedPack" bootstrap contract

    A formal, versioned contract for packaging and promoting reference/starter data between environments (with ownership, checksums and rollback) is defined as a standard internally, but is not yet fully implemented in the product.

    Planned
Environments

Environment promotion & migration

The intended path is a straight line from development through to production - not a database copy.

  • Environment promotion path

    Code and schema migrations are intended to move Development → Integration → Test → UAT/Staging → Production, without copying full databases forward.

    Beta

  • Schema migrations

    Database schema changes ship as migration scripts rather than manual, undocumented edits.

    Available

  • Configuration kept separate from seed data

    Per-environment configuration (secrets, endpoints) is intended to stay out of seed files.

    Beta
Operations

Backups & support

What we do today, and what we're not yet claiming as proven.

  • Database backups

    Regular database backups are part of our operating process.

    Available

  • Independently rehearsed restore drills

    A documented, independently verified restore rehearsal (proving a backup actually restores cleanly on a schedule) is not something we can confirm as a mature, repeatable practice yet.

    Planned

  • Support boundaries

    We support the platform itself - deployment, upgrades and defects. Data entered into the system, and decisions made from it, remain your responsibility as the customer.

    Available

Customer responsibilities

  • Assign and review who holds administrator, role-management and payroll/finance-admin permissions.
  • Own the accuracy of data you enter or import - contacts, items, financial records and configuration.
  • Tell us before you rely on a beta or planned capability (see each product page's status) for a business-critical process.
Questions

Frequently asked

Will you promise a specific backup/restore SLA?

Not until we can independently confirm a repeatable, tested restore process - we'd rather be honest that this is still maturing than promise an SLA we haven't proven.

How is my environment set up initially?

Each module has a setup wizard that walks you through creating its foundational records (roles, categories, chart of accounts, and so on) and tracks what's still outstanding.

Can we test a deployment before going live?

Yes - talk to us about a staging/UAT setup before your production go-live. The full environment-promotion pipeline described in our internal standards is a target we're building toward, not something we're claiming is fully automated today.

Who is responsible for data accuracy?

You are, for what you enter or import. We're responsible for the platform behaving correctly and safely with whatever data it's given.

Ask us about your specific go-live

We'll walk through setup, environments and support boundaries against your actual timeline.

Book a demo Sign in