A short build-in-public note from the week.
For most of Matsuri's existence I told myself: be ready to build alone, at first. In early-stage work, that vow is the right default — pitch-and-crowd-rushes-in usually means the business isn't real.
This week, two unexpected partnership inquiries arrived at the same time:
- One of Japan's largest event organizers — about partnering for our June real-operations period.
- A well-known overseas Web3 security & smart contract audit firm — about an audit partnership, inbound (not solicited).
Names withheld until contracts close. The timing matters: Matsuri's web version had just landed and we're heading into June real operations. Months of design and architectural decisions had just become visible in shippable form. That's the moment these two inquiries showed up.
Genuinely happy. Also responsibility-heavy. Below is what technically changes when partnerships arrive at this kind of phase.
What changes when partnerships arrive at design-maturity
Two failure modes are tempting and wrong.
❌ Failure mode 1: over-engineering for the partner you imagine
The instinct is: 'a big event organizer is coming, so let's build enterprise-grade capacity now.' This guarantees you miss your June ship date and burn the trust that just arrived.
What we actually scoped:
- Minimum capacity needed for early June operations.
- Harden only the surfaces the audit firm will gate on.
- Everywhere else: design extension points so the next layer of hardening doesn't require a rewrite.
❌ Failure mode 2: hard-coding a single partner's requirements
A partner-specific code path inside core logic is technical debt the moment a second partner arrives.
// ❌ Don't
function processEvent(e: Event) {
if (e.organizer === 'PARTNER_X') { /* special path */ }
}
// ✅ Externalize as profile
type OrganizerProfile = {
scaleHints: ScaleHints;
customizations: Customization[];
};
function processEvent(e: Event, profile: OrganizerProfile) { ... }
Requirements live as profiles, not branches.
What 'audit-ready' actually demands
Receiving an audit partnership inbound — when the firm reaches out before you do — is also a quiet vote of confidence in the architecture itself. It's flattering until you sit down to scope what 'audit-ready' actually means in practice. For us it meant going back and:
- Writing the threat model in something humans can read, not just in code.
- Listing the invariants the contract is expected to preserve.
- Raising test coverage to a number we can defend in a meeting, not just in a CI badge.
- Documenting the boundary between on-chain and off-chain logic, including failure modes both sides need to handle.
type AuditReadiness = {
threatModel: 'documented';
invariants: Invariant[];
testCoverage: number; // %
formalSpec: 'present' | 'absent';
auditTrail: 'append-only logs';
};
None of this is glamorous. All of it is what a serious auditor expects to find before opening the editor.
What changed inside
The vow to build alone didn't disappear. The accumulating fact of not being alone now sits next to it. Each is a real input to daily decisions.
What shifted is mostly responsibility, not relief. Someone deciding we'll be early with this team creates a quiet enforcement that doesn't come from outside. You can't betray it.
In June, real operations begin. That phrase means something starts moving — and also I begin returning what was placed in my custody. It feels less like 'now we begin' and more like 'the prerequisites are finally in place.'
What I'd love to hear
- If you've received an early-stage partnership inquiry as your design or release was maturing: what changed in your technical roadmap the day after?
- If you've audited or been audited: what's the single thing you wish founders prepared before you opened the codebase?
Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. ko-takahashi.jp · matsuri.group · j-times.org
Top comments (0)