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.
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.
Or email hello@todaytomorrowplan.com
Product screenshot
Not yet published.
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.
-
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.
-
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.
-
03
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.
-
04
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.
-
05
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.
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.
Both mechanisms have done their job
The isolation guard is not decorative.
It caught a real tenant-scoping defect in our own platform code at runtime, and named the model, both tenants, the route and the remedy in the error. We know it fires because it has.
The audit chain is verified, not assumed.
A scheduled job walks the chain and recomputes it. It has flagged an entry whose hash did not recompute — which is the whole point of chaining them, and the reason we can say tampering is detectable rather than hoping it would be.
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
Subscription plans
Recurring commercial terms for the platform itself.
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
Not published.
Pricing isn’t on the site. Book a call and we’ll take you through it.
Get started
Book a call.
Tell us how your engagements run today.
Book a call
Or email hello@todaytomorrowplan.com