Micca Music Publishing Platform

Build Progress Report

Prepared for Alberto & Consuelo  ·  20 August 2026

This report shows two different completion numbers on purpose. Which one is right depends on what you are asking.

Data current as of 3 July 2026 (feature ledger) and 21 July 2026 (engineering audit). Page written 20 August 2026, after reconciling the project documentation against the actual codebase.
The feature ledger is 48 days old. Work merged since then is not reflected in the percentages below — meaning the real numbers are somewhat better than shown, not worse.

01  /  Where the project stands

Two questions, two answers

How much of the product can you see and click?

71.1%
of documented feature breadth
(114 working + 0.5 × 42 partial) ÷ 190 active features

How close is this to something you can safely sell?

24–27%
of commercial-SaaS readiness
weighted rubric across 7 dimensions → 25.46%

Micca is demo-ready today, and roughly 6–12 months from commercially sellable at current staffing.

“The closest answer to how much visible functionality has been represented? remains 71.1%. The closest answer to how close is this to a safe commercial product? is 24–27%. Quoting either number without its lens would be misleading.” — Deep-Dive Re-Audit, 21 July 2026, §1.1

02  /  What is built

Readiness by area of the product

Every module is far more demo-ready than production-ready. That pattern is the single most important thing on this page, and section 03 explains why.

Area Can you demo it? Can a customer rely on it? Current reality
Contacts 92–96% 15–25% Strong UI and happy paths; transient state, weak permissions
Catalog / works 90–95% 15–25% Broad domain surface; no authoritative service behind it
Agreements 91–95% 15–25% Accounting boundary, routing and persistence remain
Accounting 80–88% 10–20% Visually mature; no journal or transaction boundary
Royalties / statements 80–90% 10–20% Not safe to pay anyone from. Allocation and period semantics unsafe
Creative / sync 85–92% 25–35% Strong prototype; integrations are simulated
Deliverables 65–80% 10–20% Metadata workflows exist; actual delivery lifecycle does not
Analytics / reporting 60–70% 5–15% Derived from sample data only
Onboarding 80–88% 10–20% Broad flow; no identity or durable workflow
Tenant / platform admin 55–70% 5–15% Settings often disconnected or globally scoped
Artist / client portals 85–90% 10–20% Polished views over shared sample data
Accessibility / mobile 60–70% 40–50% Good baseline; mobile and keyboard issues remain
Languages (i18n) 90% 13.3% Switching and right-to-left work; most values are still English

Source: Deep-Dive Re-Audit, 21 July 2026, §1.3. Ranges are audit estimates, not measured values.

03  /  The gap that explains everything

What you see vs. what is underneath

The part you can see 91%

Screens, forms, tables, workflows — everything you click. 83 of 99 essential features fully working, 15 partial, 1 barely started.

The part underneath 42%

The server that stores data permanently, checks who is logged in, and does the money math. 26 of 89 essential features fully working, 23 partial, 15 barely started, 24 not begun.

This gap is expected, and it was deliberate. The design was proven first — cheaply, in a browser, using sample data — so that the expensive, hard-to-change backend gets built once, against a settled design, instead of against a guess.

The cost is that nothing is permanent yet. In practical terms: you can show Micca to anyone. You cannot yet put a real client’s real data into it.

The backend is not unstarted — it is designed but not built. A complete 1,550-line database design covering roughly 26 record types already exists on paper (prisma/schema.prisma), together with a chosen stack and a 4–6 week build estimate. That is a head start, not a hole.

Counted from the 3 July 2026 feature ledger, essential (MVP) features only, where a partially working feature counts as half. Frontend 99 + backend 89 + 3 features classed as legal, design or infrastructure = 191 essential features in total.

How well is the built part tested?

Unlike the percentages above, these are measured today, not carried over from July. They say nothing about whether the right things were built — only that what exists is checked automatically every time it changes.

CheckToday21 JulyMeaning
Automated tests12,215 passing11,580Across 531 test files, all green
Browser tests1,1441,125Real-browser checks of complete user journeys
Type safety0 errors0 errorsStrictest setting, no exemptions
Translation keys2,9762,545Across 10 languages — though only 13% are actually translated

Measured on the current codebase, 20 August 2026. The July figures come from the audit, and the project documentation has been corrected to match today’s numbers.

04  /  What is missing

What Micca is and is not ready for

Intended useVerdictWhy
Local demo with sample data Conditional go Works broadly; label simulated behaviour and keep unsafe financial actions switched off
Public hosted demo Now live No-go — no deployment existed Corrected 20 Aug 2026 — now live at micca-dashboard.pages.dev
Public marketing launch No-go Dead links, unsupported claims and accessibility failures on the marketing site
Paid pilot with a real client No-go Identity, permanent storage, tenant separation, privacy and audit are missing
Royalty calculation or payment No-go Financial rules and safeguards are not yet trustworthy
Automation on untrusted content No-go The internal automation tool has unresolved safety gaps

The five blockers that matter most

45 issues are formally catalogued — 13 that block any release, 32 that block a paid pilot. Translated out of engineering language, the critical ones are:

Audit IDWhat it means for you
DATA-001Nothing is saved permanently yet — close the tab and edits are gone
AUTH-001There are no real logins — everyone who opens it is an administrator
TEN-001One client could see another client’s data
ROY-001Royalty maths is not safe to pay anyone from
LAND-001Marketing site links and legal pages do not work

Source: Deep-Dive Re-Audit §1 and §15. IDs are kept so each line traces back to the full audit.

05  /  What is next

Three destinations, and what each costs

Honest hosted demo

Show Micca to anyone, anywhere, using sample data.

2–4engineer-weeks remaining

Design-partner pilot

One real partner, with real data — but no royalty payments running through it.

12–20engineer-weeks remaining

Commercial v1

Sell it. Administer real rights and real money for paying customers.

28–48+engineer-weeks remaining

These are engineer-weeks, not calendar weeks. They measure how much work is left, not when it lands. At current staffing — one engineer — the audit’s own estimate for the full commercial path is 6–12+ calendar months.

They are estimates from the 21 July 2026 audit, not commitments. They assume timely product, domain and legal input, and they exclude time spent waiting on decisions — which is why the next section matters more than this one.

06  /  What we need from you

14 decisions are open. Three of them unblock the rest.

Until the first three are answered, detailed planning cannot start. These are not engineering questions — they are business questions only you can answer. Each already carries a recommendation, so the fastest path is to agree or disagree with it.

D3

Is Micca software, a service, or both?

Recommended: software with a paid managed add-on — sold as a product, with hands-on administration available as a separate paid tier.

Unblocks: legal structure, what financial data we may store, privacy obligations, service guarantees.

D1

What goes into the first paid release?

Recommended: Contacts + Agreements, with royalties read-only — the two strongest modules, without taking on payment risk.

Unblocks: pilot scope, what must be production-grade first, the target partner conversation.

D2

Are royalty statements in version 1?

Recommended: read-only — clients can see statements, but Micca does not calculate or issue payments yet.

Unblocks: the largest single block of financial-correctness work.

Answer first
D3 · D1 · D2 · D12
Then these open up
D7 · D8 · D5 · D6 · D9
Then the rest
D10 · D11 · D13 · D14 · D4

The remaining eleven

IDQuestionRecommendation
D4Who is legally responsible for each kind of data?Per-dataset table, drafted with legal
D5Which countries and societies do we support first?Needs your call — drives integration order
D6Which territory-code standard is authoritative?Adopt one standard and stop translating between lists
D7Who is allowed to do what, at every level?Define roles before real logins are built
D8Can contacts be shared between workspaces?Default to no; revisit if a partner needs it
D9Which financial details do we store vs. hand to a payment provider?Store as little as possible
D10How long do we keep data, and where does it live?Follows from D3
D11Which integrations are real launch dependencies?Separate genuine blockers from roadmap ambition
D12Which technology decisions are locked?Confirm the recorded stack so building can start
D13What uptime and support do we promise?Follows from D3
D14How much evidence before AI touches rights or money?High bar; keep AI advisory, not authoritative

Three strategy questions with no engineering answer

Sources: audit decision workshop agenda (D1–D14, with recommended options and owners) and roadmap §4.

07  /  Recent activity

What has shipped lately

DateWork
20 Aug 2026Project documentation reconciled against the codebase — test counts, translation counts and hosting status were all out of date
20 Aug 2026This report published (PR #232)
20 Aug 2026Contacts fixes from Alberto’s walkthrough — section navigation, working filters, saved edits, search, phone validation (PRs #230, #231)
20 Aug 2026Dashboard published to a live link for the first time
13 Aug 2026Contacts aligned to Consuelo’s revised spec workbook — all 11 sheets audited (PRs #227, #228)
23 Jul 2026Codebase reorganisation, phases 1–6
21 Jul 2026Deep-dive engineering audit — the source of most numbers on this page