Where a studio and its clients always agree on where the work stands.

Apollo gives a creative studio and its clients one workspace for managing briefs: deliverables and action items, versioned proofs, threaded approvals, time tracking and capacity — with a complete audit trail at every step.

A hosted service — standard or tailored to you Two-sided studio & client workspace Role-based access, full audit trail
MRDN · SG
Search briefs Status ▾ Assignee ▾ Section ▾
Client inputVendor input
SpringOverallStore entrance poster
SpringOverallSunglasses redemption poster
SpringOverallEvent teaser poster
SpringOverallEvent in-store POP
LoyaltyOverallHoarding visual
LookbookOverallKids lookbook photo
LookbookOverallLookbook photo
LookbookOverallLookbook photo (2)
ArtcardsOverallMember artcard 1
ArtcardsOverallMember artcard 2
CampusOverallHanger POP
CampusOverallDisplay cubes
Spring › Overall › Store entrance poster 🔥 Urgent
On Hold Cancelled
CLIENT Awaiting Brief Brief Ready Review Amendment Approved Done
VENDOR In Progress Proof Ready Output Ready
BriefReferenceProofsCommentsActivity
0 threads☐ Show resolved
No comments yet.
Write a comment… use @ to mention 🔒 Internal ➤ Send
The case for a system

A studio and its client can run a few briefs out of email. Then volume catches up with them.

On a handful of jobs, the informal version works. The client sends a brief by email. A designer picks it up, exports a mockup, and emails it back. The client replies with changes in the body of the message. A few rounds later, someone delivers the final file.

Scale that to a standing contract — dozens of live briefs across several campaigns, two teams, deadlines every week — and the cracks show. Nobody can say which version a comment referred to. "Approved" lives in someone's inbox. Feedback arrives as "make the logo bigger" with no indication of which logo, on which frame. The studio can't prove how many rounds a job took, and the client can't see what's coming due. At month-end, working out how much time actually went into the contract means reconstructing it from memory.

“Half the work isn't the design. It's tracking the state of the design.”

That's the visible symptom. The deeper one: most of the friction between a studio and its client isn't disagreement about the work — it's disagreement about where the work is. Who has the ball. Which round this is. Whether a change was asked for, or just mentioned. Both sides spend their day chasing state instead of moving the work forward.

Apollo replaces the informal process with a structured one. Every brief has one place to live, one status each side can see, and a versioned set of proofs. Feedback is pinned to the exact point on the exact version. Approvals are explicit and recorded. Time is logged against the brief as the work happens. Nothing depends on remembering — it's all on the record.

That's the whole product. The rest of this page is how each piece works.

What actually changes

Stage by stage, here is what's different.

The shape of the work doesn't change — it's still briefs, proofs, feedback, delivery. What changes is where each piece lives and how much time both sides spend tracking it.

Stage Without Apollo With Apollo
Briefing Briefs arrive by email or chat, in whatever shape the sender chose. Detail is missing; the designer chases it before starting. A structured brief with deliverables, due dates and references. It isn't picked up until the client marks it ready.
Production Work is one big blob. Nobody outside the designer's head knows how far along it is or what's left. Broken into action items, each with an owner, estimate and status. Progress reads as "N of M done" at a glance.
Proofs Mockups emailed as attachments. Versions pile up — final, final-2, final-final. No one is sure which is current. Each round uploaded as a numbered proof. The current version is unambiguous; old rounds stay on the record.
Feedback "Move the logo, fix the colour" in an email body. Which logo? Which version? The designer guesses. Comments pinned to the exact point on the exact proof, threaded and resolvable. No ambiguity, no guessing.
Approval "Looks good" buried in a reply. No clean record of who approved what, or when, if it's ever questioned. An explicit approve / request-changes decision, timestamped against the version it applies to.
Time & capacity Hours reconstructed from memory at month-end, if at all. No view of whether the team is over-committed. Time logged against the brief as work happens. Utilisation against planned capacity, live.
Accountability Disputes come down to whose inbox is more complete. Round counts and timelines are unprovable. Every status change, comment and decision is logged with user and timestamp. The history is the record.
How it works

Six steps, one trail, two sides in sync.

Every brief moves through the same path. Each step is logged with the user and timestamp. The client and the studio see the same brief from their own side, never a forwarded copy.

01

Brief created

Client raises a brief with deliverables, references and a due date, then marks it ready.

02

Assigned

Studio picks it up, assigns a designer, and breaks the work into action items.

03

Production

Designer works through action items, logging time with a start/stop timer.

04

Proof submitted

A numbered proof goes up for review. The client comments pinned to the artwork.

05

Approval

Client approves or requests changes with a required note. Revisions loop back to step 3.

06

Delivered

Output marked done and delivered — only once every action item is closed.

Onboarding a contract, not a quarter-long rollout.

Apollo is configuration-driven and multi-tenant. A new contract is a setup task, not a project. A typical onboarding runs to this rhythm.

1
Contract setup

Create the contract, its campaigns, and the planned capacity. Configure roles and statuses.

2
People

Invite the studio team and the client's users. Each side gets its own role-scoped view.

3
First briefs

Real briefs run end to end — brief, proof, feedback, approval — with both sides live.

4
Steady state

The board becomes the source of truth. Dashboard and utilisation come online for planning.

Who works in the system

Two sides. Four roles. One brief.

Studio

Studio admin

Provisions users, sets up contracts and capacity, manages settings, and owns the audit log.

Studio

Designer

Works the briefs: action items, proofs, responses to feedback, and time logged as they go.

Client

Client admin

Manages their own team's access, raises briefs, and oversees everything under the contract.

Client

Client user

Reviews proofs, leaves pinned feedback, and approves or requests changes on the work.

What it does

Four things, done properly. Plus the small things that matter.

Apollo is built around four jobs a studio–client relationship has to get right — and a set of secondary capabilities that exist because, on a real contract, someone needed them.

01 / Pillar

A brief that tracks its own state.

Every brief carries two statuses — one the client owns, one the studio owns — so neither side has to ask where it stands. Work is broken into action items, each with an owner, an estimate and a status, and a brief can't be marked delivered while any action item is still open.

Two-sided statusAction items Owner & estimateDelivery guardrail
Brief · Social carousel 3 of 5 done
Frame 1 — hero
DJ · 1.5h
Frame 2 — product
DJ · 1.0h
Frame 3 — offer
DJ · 0.8h
Frame 4 — lifestyle
due Fri
Frame 5 — CTA end card
due Fri
02 / Pillar

Feedback pinned to the pixel.

Each round of work goes up as a numbered proof. The client comments by dropping a pin on the exact point of the exact version — no more "the logo on the third one." Comments thread, get replies, and are marked resolved, so it's always clear what's been actioned.

Versioned proofsPinned comments Threaded repliesResolve & reopen
Window vinyl · Proof v2 ● 2 open
1
2
1 · Client — Logo reads small at this scale, can we go +15%?
2 · Client — Offer colour is off-brand; use the deep green.
03 / Pillar

Approvals that leave a record.

When a proof is ready, the client makes an explicit call — approve, or request changes with a required note. The decision is timestamped against the version it applies to, and a request for changes loops the brief straight back into production. No more hunting an inbox for the message that said "go."

Explicit decisionRequired change note Version-stampedAuto re-open on changes
Window vinyl · history v2
Proof v1 submitted
12 Jun 09:40
Changes requested · 2 notes
12 Jun 15:02
Proof v2 submitted
13 Jun 11:20
Awaiting client decision
—
04 / Pillar

Time and capacity you can actually see.

Designers log time against the brief with a start/stop timer as they work, so effort is captured while it's fresh, not reconstructed at month-end. Roll it up per contract and the studio sees planned versus actual hours and each designer's utilisation against their capacity — with a warning before anyone is over-committed past 1.0 FTE.

Start/stop timerPlanned vs. actual Per-designer utilisationOver-capacity alerts
Utilisation · this week FTE
Designer · J. Lim0.62
Designer · A. Rahman0.88
Designer · M. Chen1.12
Designer · P. Nair0.45
AND THEN, THE THINGS YOU FIND OUT YOU NEED

A personal home view that buckets every brief by what needs attention — overdue, due today, awaiting the client, ready to review, delivered. A notification centre with per-type toggles for assignments, status changes, comments, @-mentions, and due-soon and overdue warnings. @-mentions in any comment thread. A capacity dashboard with planned-versus-actual hours by campaign and date range, exportable to CSV on the studio side.

Underneath it all, an append-only activity log: every status change, assignment, due-date edit and action-item completion recorded with the user, the before-and-after value, and a timestamp. When a contract is questioned months later, the history answers it.

Built to be trusted

Two organisations in one workspace, each seeing only what it should.

Apollo puts a studio and its clients in the same system without blurring the line between them. Access control and the audit trail are part of the data model, not a setting bolted on.

Access & isolation

Every contract is its own tenant. A client only ever sees their own contract; a client user never sees the studio's internal production fields, and the studio's view is scoped to what each role needs. Permissions are enforced at the API and the field level, not just hidden in the interface.

Sign-in is handled in-platform with breach-checked passwords and configurable session limits. Sensitive integration credentials are encrypted at rest. Admins provision and suspend users on both sides without anyone emailing a password around.

  • Tenancy Per-contract isolation, multi-tenant
  • Roles Studio & client roles, API + field-level checks
  • Auth Built-in, breach-checked passwords, sessions
  • Secrets Integration credentials encrypted at rest
  • Provisioning Admin-managed invites and suspension

Accountability

Apollo's audit trail is append-only and comprehensive. Every status change, assignment, due-date edit, comment and action-item completion is recorded with the user who made it, the value before and after, and the moment it happened. The studio side can export the activity log to CSV for a contract review or a dispute.

Because reports and dashboards read from that same trail, there is no second place where the truth lives. What the dashboard shows and what the history records are the same data.

  • Audit Append-only, user + timestamp + before/after
  • Coverage Status, assignment, due dates, comments
  • Export Activity log to CSV (studio side)
  • Single source Reports read from the same trail
  • Time Sessions captured live, voided on overrun
How it's delivered

One service. Standard, or shaped around you.

Apollo is hosted and run by us — there's nothing to deploy and nothing to maintain. Start on the standard product, or have it tailored to your workflow. Either way it stays a single subscription.

Hosted · Standard

The product, ready to go.

Subscribe and you're live in days. Your studio gets its own isolated tenant, you invite your clients in, and the whole brief workflow is there from day one — with hosting, backups and updates handled for you.

  • Live in days, nothing to deploy
  • Your own isolated tenant
  • Hosting, backups and updates managed
  • Predictable monthly subscription
Hosted · Tailored

Shaped around your workflow.

When your process needs something the standard product doesn't, we configure and extend Apollo for your studio — custom fields, roles, stages and reports — and run the tailored version for you as part of the same service.

  • Custom fields, roles and stages
  • Workflow fitted to how you work
  • We build, host and maintain it
  • Still a single subscription
Why this exists

We built Apollo because the studio–client back-and-forth had no system of its own.

Creative teams have tools for the design itself, and clients have tools for everything except the bit in the middle — the briefs, the rounds, the approvals, the time. That gap gets filled with email and spreadsheets, and it quietly costs both sides a day a week.

Apollo is narrow on purpose. It doesn't replace your design software or your finance system. It owns one relationship — a studio and the clients it works for — and makes the state of every brief unambiguous, with the access control and audit trail that a shared workspace between two companies actually needs.

You run it as a service — subscribe to the standard product and be live in days, or have it tailored to your workflow. Either way we host, run and maintain it. It's built the way we build everything at Proteger: custom workflow software designed and shipped end to end, AI-assisted in the design and conventional, auditable software in production.

— Benjamin Tan

Get in touch

Benjamin Tan

Protéger Consulting Sdn Bhd · Kuala Lumpur
  • A live walkthrough of Apollo on your screen
  • Whether the standard service or a tailored setup fits you
  • A trial tenant to run a real brief through
  • Straight answers on hosting, access and pricing