There's a version of Vizory I could have built faster and cheaper. I chose not to. Here's why that was the right call.
The naive assumption I deliberately rejected.
There's a view in the product / tech community that I've heard repeated for years: build a minimum viable slither, get it in front of users, iterate from there. Treat everything else as a "nice-to-have" you can add later — once you've proven the core value works.
That advice is sound for plenty of categories. Consumer apps, productivity tools, anything where the early adopters are tolerant of rough edges and the worst-case downside is a refund request. It's not sound for board materials.
I knew this from the start. When you're handling documents directors have legal obligations to protect — M&A targets, financial projections, executive performance discussions, strategic plans not yet public — a lightweight security posture isn't a feature gap you can close in v2. It's a disqualification. The moment a potential user asks "where does my data go?" and you can't give a complete, confident answer, you've lost them. And in a market this small and this networked, you've probably lost their professional circle too.
So we built differently. Security as the architecture, not a feature on top of it. That meant slower initial progress, more upfront engineering, and a longer path to first users than the conventional MVP playbook would have suggested. It also meant that when the first directors asked the inevitable question, the answer was complete the first time — and the network effect started working in our favour rather than against us.
Security wasn't a bolt-on. It was the architecture. Every decision about where data sits, how it moves, and who can access it had to be made through a security lens first.
What the secure environment actually required.
My co-founder Toby Vidler came from a background that made this non-negotiable. He'd led ISO 27001 certification at Prospection, handling 350 million de-identified patient records across GDPR, HIPAA, and multiple other regulatory frameworks. His position was unambiguous: if you're going to do this for directors, security has to be foundational.
What that meant in practice:
- All data hosted on AWS infrastructure within Australia — no foreign cloud storage, no offshore processing
- AES-256 encryption at rest, TLS 1.2+ in transit
- PDF processing pipeline that sliced documents into individual pages before analysis — for both source referencing and cross-user data isolation
- Strict access controls: only Toby and I could access system data, and only with explicit written permission
- No external AI model training — ever — from any user's data
- Automated data retention and deletion controls
Each of these decisions added scope, and none more so than the PDF processing pipeline. Rather than extracting the full text of a board pack as a single block — the simpler and faster approach — we sliced each document into individual pages and stored them separately, with metadata that preserved the position of every piece of content within the original. Every analysis the AI ran was anchored to the specific page it came from.
This had two consequences we cared about deeply. The first was source referencing throughout the product — every signal, every insight, every flagged risk could link back to the exact page in the original PDF with one click. Directors could verify anything instantly rather than taking the AI's word for it. The second was data integrity: processing at page level gave us finer-grained control over isolation, access, and deletion per user. The architecture that built trust with directors and the architecture that was technically sound turned out to be the same decision, made at the same time. That's not always the case in product development. When it happens, you've found something worth protecting.
The time-to-value problem.
One consequence I underestimated: time to value was longer than I expected.
I originally assumed one board cycle would be enough — upload a pack, see the signals, feel the benefit, keep the subscription. It was actually closer to three cycles before behaviour changed. Cycle one: directors still read the pack manually and ran Vizory alongside it — parallel processing, not replacement. They were testing whether the AI caught what they caught. Cycle two: still doing the manual read, still comparing, but with growing confidence in the outputs. Cycle three: only then did most directors start relaxing into Vizory as the primary tool and stepping back from the full manual read.
This had a flow-on effect: because board cycles aren't uniform (some boards meet monthly, others every six weeks, many quarterly), a director on two quarterly boards might be a full year into the subscription before they've hit cycle three on either board. Where I thought time-to-value would be four to six weeks, the realistic path to behaviour change was four to nine months depending on meeting frequency. That has serious implications for trial design, churn risk, and any financial model built on standard SaaS assumptions about activation timelines.
Branding matters — the colour test.
This is a small thing that turned out to matter more than I expected.
Vizory's original brand was a bright, optimistic purple — the kind of colour that works for a modern SaaS startup trying to feel approachable and energetic. We liked it.
Then we started showing it to directors. The feedback was subtle but consistently told us the tone was slightly off. Directors are dealing with governance, liability, accountability. The visual language needs to signal trustworthiness and seriousness — not just approachability.
We shifted to a deeper, more considered shade of purple. The change sounds trivial, but brand signals trust to a specific audience, and in a market where trust is the primary purchase driver, getting that register right matters. It's the kind of detail that doesn't show up in any product brief but absolutely shows up in how a director responds when they first open the app.
The build-versus-validate tension.
One specific challenge in building a product like this: you need real board packs to test the AI analysis properly, but asking directors to share real board packs requires trust you haven't yet earned.
We resolved this by being explicit about the conditions. Early adopters shared packs under NDA, with full transparency about what we'd see, how it would be used, and when it would be deleted. We were clear that during the early phase, we would be able to see the packs — and committed to moving to a model where we couldn't once we moved beyond that phase.
That transparency, rather than minimising the ask, was what built trust. Directors who participated did so because the conditions were honest.
Stated preference vs revealed preference: what we built, what directors used.
Two features consumed significant development effort based on strong enthusiasm in early research. Both turned out to matter far less in practice. The gap between what directors said they wanted and what they actually used is worth understanding, because it's a trap that's easy to fall into — and expensive to discover late.
I talked about the financials feature in section two. In conceptual testing, even financially sophisticated directors were enthusiastic about a layer that tracked governance-critical signals — the things directors are personally liable for: whether GST obligations are being paid on time, whether annual leave liabilities are building dangerously, whether cashflow stress is hiding in the numbers while management stays quiet. That framing seemingly appealed to our early users. So we invested heavily in building it: structured parsing logic, ratio calculations, anomaly flagging across packs.
The technical problem in doing this was harder than expected. Financial statements in board packs are inconsistently formatted — millions on one page, thousands on another, scaling unstated on a third. The LLM kept tripping on this, producing confident but wrong calculations. We considered surfacing the inconsistencies to users and asking them to verify the scaling. We rejected that quickly: if users have to correct the system before it can do basic financial analysis, they're unlikely to place complete trust in it. So we pulled back to an alert-only approach.
And then, watching early adopters actually use the product, we got to the truth of it: users barely glanced at the financials section. Most board packs already contain a KPI scorecard the company has curated, and directors go straight to that. They didn't need Vizory to recalculate what they could already see. Weeks of engineering, significant technical complexity, and the finding was: this wasn't the urgent job.
Cross-pack search was the same story, albeit in a different shape. In testing it generated some of the strongest reactions of any feature — "you've solved my problem" was a phrase I heard more than once. In practice, once directors were using the product regularly, search was barely touched. Directors are time poor; they really just need the tool to surface what's important for them, not give them another way to search for it themselves. They gravitated almost entirely to Key Signals — the feature that did the triage — and largely skipped the features that required formulating a query.
You can see that both of these features were affected by revealed preference diverging sharply from stated preference. What directors endorsed in research and what they actually reached for when pressed for time were different things. People say yes to features that solve problems they can imagine having. They use features that solve the problem they're experiencing in the moment, with minimal friction.
In a market where board prep happens in gaps between other commitments, "this would be useful" and "I will use this under time pressure" are very different claims. This is tricky as you never have full usage analytics and evals from the outset.
What product–market fit looks like in a niche.
Standard SaaS PMF metrics don't map cleanly onto a quarterly-cadence governance product. I developed a framework specific to this market:
Early validation — 30 to 50 customers.
Directors using Vizory every board cycle. Telling you they'd be very disappointed if it disappeared. Starting to bring it to a second board. Showing signs of being indispensable, not just interesting.
Credible PMF — 100+ customers.
Approximately $180k ARR. Retention above 80% after 12 months. A meaningful portion of growth from referrals and seat expansion. This is the point where you've demonstrated not just usage but genuine willingness to pay a premium price.
Clear traction — 300 to 500 customers.
$540k to $900k ARR. Consistently low churn. Vizory known in the director community as the private AI thought partner. At this stage, PMF is clear.
There were some green flags I was watching for: active use every board cycle, expansion to second boards within three to six months, unprompted referrals, willingness to pay full price without discounting pressure. And red flags … low usage after signup, feedback centred on 'nice idea but not urgent,' sign-ups requiring steep discounts or heavy persuasion.
The honest assessment after the early adopter program: some green flags were present. Not enough of them, for reasons the next parts explain.