Engagement delivery platform

Run client engagements end to end
— under your own name.

Scope, contracts, change orders, time and invoicing, a client portal, and the software you deliver — one platform, one spine. Built for consultancies of 5 to 100 people doing custom software and technical delivery.

The six stages of an engagement, in order: scope, contract, build, change order, invoice, and handoff and maintenance. In their portal your client approves the contract, reviews what has been built, approves the change order, and pays the invoice.
  1. Scope
  2. Contract Approves
  3. Build Reviews
  4. Change order Approves
  5. Invoice Pays
  6. Handoff / Maintain

Marked stages are what your client does in their portal.

The engagement spine

Every stage is built from the one before it.

Most delivery tooling treats scope, contracts, billing and reporting as separate systems that happen to describe the same work. Here they are one chain: what you agreed shapes what you bill, and what you bill reconciles to what you agreed.

  1. 01

    Scope

    Record what you are delivering as scope items on the engagement. Everything downstream is built from them, so they are the one thing worth getting right early.

  2. 02

    Contract

    The agreement is built from those scope items, so the contract and the delivery plan cannot drift apart. Generated, signable, versioned. Your client reviews and approves it in their portal.

  3. 03

    Build

    You build against the scope you agreed, not a separate backlog. Data shape first, then screens, then permissions and behaviour — pages bind to entities and permissions are granted per entity, so that order is what stops you redoing the screens. Your client reviews what has been built in their portal.

  4. 04

    Change order

    When scope grows, your client raises a change request in the portal. It becomes a priced change order. They approve it, and the approved scope becomes a billable scope item on the engagement.

  5. 05

    Time & invoice

    Log time against the engagement at its rate. Raise an invoice from it. Drafts stay out of your aging figures, so your receivables are what you can actually claim.

  6. 06

    Report & hand off

    Progress reports are generated from the engagement’s real state — scope items and their status, time logged, what shipped — not typed from memory. The handoff package is what your client keeps.

Disputes, quotes and progress reports hang off the same spine, on the same engagement.

The app you deliver

Configuration, not code.

The software you deliver to a client is configuration — its data shape, screens, rules, permissions and look are stored, versioned and shipped as a unit. Changing a delivered app is a config change, not a code deploy.

The four below are what a consultant assembles without us. Analysis that spans two entities — cost per customer, spend per unit — and figures a reader can move for themselves are set up by your consultant or by us, not clicked together in the builder yet. If that is the shape of the work you are buying for, say so on a call.

What a consultant actually builds

Pages

Widgets on a grid, each bound to an entity and a query.

  • Data tables, forms, charts, KPI cards and stat grids, pivot tables, waterfall charts, kanban boards, work queues, timelines, activity feeds, maps and markdown.
  • The property inspector is built from each widget’s own config schema, so an enum renders as a select and a field reference as a picker over that entity’s real fields — you are not typing field names by hand.
  • A measure can carry its own condition, so a win rate is two counts and a division rather than a 1/0 column your client maintains by hand forever. Calculations run over those measures — the previous period, a running total, a share of the total, a rank — so growth and a margin bridge are the same mechanism rather than two features. Dates group by day, week, month, quarter or year, in a timezone you pick rather than one we assume.
  • Navigation is authored alongside the pages, and an entry pointing at a page that does not exist is caught before deploy.

Behaviour

Five mechanisms, kept separate so detection and response can be tuned independently.

  • Rules fire on a record change: condition, then actions — notify, assign, set a field, create a record, start an escalation, run a workflow.
  • Workflows are click-authored on a canvas with typed nodes, and can pause on a human approval and resume when it is completed.
  • Anomaly watchers track a metric over a window — threshold, rolling baseline, seasonal, contextual, or percentage change — and the tuning step replays the last 90 windows so you can see where a watcher would have fired.
  • Surfacing rules rank records that need a human into an attention queue; escalation chains climb to the next person when an alert goes unacknowledged.

Permissions

Roles for the delivered app, and a matrix that says what each one may do.

  • Per role, per entity: no access, read, write, or full — projected onto create, read, update and delete.
  • Roles inherit from other roles, and the resolution is safe against both diamonds and cycles.
  • Deny on unset. A permission that has not been granted is denied; there is no implicit allow, so a new role can do nothing until you say otherwise.
  • Row-level access is available by user attribute, so a user sees only the rows matching their own region or team.

Data model

Entities, fields and the relationships between them.

  • Field types include string, number, boolean, date, enum and reference, with validation for required, unique and range.
  • Referential integrity is enforced on delete: removing a record that others point at is refused, and the error names the records referring to it rather than silently orphaning them.
  • Where a relationship is optional you can configure the delete to clear the reference instead of blocking.

How it ships

Draft, published, deployed

Three distinct states. Editing a published version forks a new draft and leaves the published one frozen, so “what is actually live?” always has a specific, nameable answer.

Publishing refuses broken configuration

Validation runs over the whole configuration and blocks a release with a nav entry pointing at a missing page, a widget bound to a deleted field, or a rule targeting a removed entity. A misconfiguration is loud at deploy time instead of silently inert in production.

Rollback and promotion

Rollback runs a safety check and tells you what it found before you commit. Promotion to production goes through an approval gate that cannot resolve to “nobody can approve this”.

Deploying config does not touch data

Redeploying an app’s configuration preserves its records. The one destructive operation is guarded: refused on a deployed app, and a verified backup is taken before any migration.

Where it runs. Cloud-hosted or on-premises — you deploy to either, and data residency follows from that choice.

What it connects to. Stripe for payment collection, email delivery, and cloud hosting. Nothing else is integrated today.

Client portal

Where your client does their half.

Approvals happen in the portal rather than in email, which is what keeps the spine intact — a contract approved, a change order priced and accepted, an invoice paid.

What your client sees

The engagement at a glance, contracts, invoices, progress reports, change requests, quotes, change orders, deliverables, demos, documents, the schedule, onboarding, and notifications.

How they get in

A magic link — they enter their email, and land authenticated. There is no client password to manage or leak. Access is engagement-scoped: a client user sees that engagement and nothing else. From the portal, a single-use short-lived token hands them into the delivered app without a second set of credentials.

Branding, stated exactly

Your firm’s logo and identity render throughout the portal once a client has signed in. The sign-in page itself is TTP-branded — your colours are not applied before the platform knows which firm the visitor belongs to. A fully white-labelled sign-in does not exist today.

Security & data

What the platform actually does.

We hold no security certification — no SOC 2, no ISO 27001 — and none is in progress. Rather than imply otherwise, here is what the platform does today.

01

Per-tenant isolation

Each tenant’s data is isolated from every other tenant’s, enforced by a runtime guard rather than by convention.

02

Hash-chained audit logging

Each audit entry carries the previous entry’s hash, so a removed or altered entry does not recompute.

03

Exportable audit trails

Audit trails export to CSV with a server-side date range, rather than only being viewable in the product.

04

MFA for your operators

Time-based one-time passwords for your firm’s own accounts, with recovery codes. Your clients sign in to the portal by magic link, so there is no client password to manage.

05

Backups with automated restore verification

Backups are taken and restores are verified automatically, so a backup is known to be restorable rather than assumed to be.

What each mechanism guarantees

Every query is tenant-scoped.

A scoping mistake is refused at runtime rather than returning the wrong rows, and the error names the model, both tenants, the route and the remedy — so it is caught where it happens, by the platform, not discovered later in someone's data.

The audit chain is verified, not assumed.

Every entry is hash-chained to the one before it, and a scheduled job walks the chain and recomputes it. An entry whose hash does not recompute is flagged, which is what makes tampering detectable rather than merely unlikely.

In development

What we’re building next.

Everything above this section exists today. Everything in it does not — these are in development, and we are not going to guess at dates for you. The commercial layer of the platform is what we are building now.

In development

Self-serve firm onboarding

Signing your firm up without us provisioning it by hand.

In development

Self-serve subscription billing

Paying for your plan without us setting it up and invoicing you.

In development

Per-tenant limits

Configurable ceilings on what a single tenant can consume.

In development

SSO for firm accounts

Single sign-on for your firm’s own operators.

If one of these is the reason you would or wouldn’t buy, say so on a call — it is useful to know, and we would rather hear it than guess.

Pricing

Three tiers.

Per month, in USD. Annual billing is two months free.

Starter

$199/mo

A small practice running its first engagements on the platform.

  • 3 consultants
  • 3 live client applications
  • 250k AI tokens a month
Apply

Firm

$999/mo

A practice delivering at scale.

  • 25 consultants
  • Unlimited live client applications
  • 3M AI tokens a month
Apply

Founding rate. The first five practices lock their tier for 24 months.

AI tokens are a real ceiling. The platform meters them per month and stops AI calls when a month’s budget is spent, rather than billing you past it.

Starting. Apply for a practice and a person will read it. We set each one up deliberately rather than automatically, so there is no instant signup — and nothing is charged while we talk.

Get started

Book a call.

Tell us how your engagements run today.