Testing an operating layer for repeatable service work.
ActaOS is an early local-first venture for legal operations and service delivery. The current pilot focuses on customer jobs, staged work, approvals, billing readiness, and evidence that cannot be casually rewritten.
Customer
Client and service context
Job
One active delivery cycle
Rules
Service type and roles
Snapshot
Start-state evidence
Approval
Review and billing gates
Record
Audit and repeat work
The problem
Service work gets messy when the record is not trusted.
Legal and service teams often carry important work across email, files, spreadsheets, portals, and memory.
Thin records
The status is visible, but the source, approval, version, and owner are harder to prove.
Manual handoffs
Intake, review, billing, and closure often depend on people remembering the right next action.
Changing rules
Templates and client settings change, but active jobs still need a clear record of the rules they started with.
The venture thesis
AI does not fix weak operations. The authority record comes first.
The thesis is simple. Service teams need a local-first operating record that joins workflow, documents, approvals, billing readiness, and repeat work.
ActaOS is being tested as a practical operating layer before any broader Services product claim.
What the pilot covers
Service areas under review.
These are validation areas, not claims of a finished horizontal platform.
How the model could work
From customer request to closed operating record.
Define the service
Set the service type, role rules, stage plan, documents, and completion criteria.
Configure the pilot
Set customer-specific checklists, delivery days, fees, approvals, and working rules.
Start the job
Create one active job with an immutable snapshot of the rules in force at the start.
Run the work
Track intake, delivery, QA, blockers, time, cost, evidence, and exceptions.
Approve the outcome
Separate delivery approval, billing readiness, margin exceptions, and closure authority.
Close the record
Preserve completion evidence and capture the decision for the next service cycle.
Why this wedge
Website care plans are a narrow, testable service workflow.
The current Services pilot starts with a small Hong Kong web agency or digital studio running monthly website maintenance jobs for SME customers.
It is deliberately narrow: intake, access/materials, maintenance delivery, QA, approval, billing readiness, and next-month repeat work.
Currently being validated
The immediate work is a bounded services pilot.
The goal is to test 5-10 live jobs over roughly 60 days before making broader product claims.
Who I want to speak with
Conversations that can sharpen the Services pilot.
Legal operators
People working around matter planning, client records, documents, billing, and operational reporting.
Service founders
Teams running recurring client work where intake, QA, evidence, billing, and repeat work need discipline.
Digital studios
Agencies with monthly website care plans, support credits, client delays, and delivery notes to manage.
Technical partners
Builders interested in local-first systems, SQLite-backed operations, audit, permissions, and file custody.
Founder note
Developed from Hong Kong, with controlled validation before scale.
ActaOS grows out of my work on workflow systems, CRM, reporting, and revenue operations. The current focus is proving one narrow operating journey before widening the product surface.
Start a conversation
Working on legal operations or repeatable service delivery?
I am speaking with operators, founders, and technical partners who care about trusted workflow records.
Start a conversation