Junior to mid-level auditors at Indonesian banks and financial institutions — the people who actually do the loan review work. Not the audit partner who signs off, but the associate sitting with 50 loan files, a spreadsheet, and a checklist they repeat from scratch every engagement.

They are not technical. They are detail-oriented, time-pressured, and accountable for accuracy. Any tool that slows them down or adds steps gets ignored.

I spent four years doing this work at EY. The loan review process was mostly manual: open a file, check if documents were complete, extract numbers into a spreadsheet, calculate impairment, track status in a separate sheet. Then repeat — for every loan, every engagement.

The inefficiencies were not hidden. They were just accepted. Completeness checks done twice by different people. Spreadsheets emailed back and forth. No single view of where each loan was in the review cycle. When something went wrong, it was hard to trace back.

I did not run user interviews. The validation was four years of doing the work myself. I knew the pain points because I had lived them — the repeated completeness checks, the fragmented KKA files, the PSAK 71 calculations rebuilt from scratch each time.

That's a form of validation, but also a limitation. My experience was from one firm. Other banks may run the process differently, and a proper product would need interviews with auditors across multiple institutions before assuming the pain is universal.

Preserve auditor judgment, reduce manual work. The goal was never to automate the audit decision. That would be both wrong and unacceptable in a regulated environment. The goal was to remove the repetitive operational steps so auditors could spend more time on actual judgment — assessing credit risk, not chasing missing documents.

Built compliance in from the start. Role-based access, audit trail logging, and data segregation were not afterthoughts. In a regulated environment, these are table stakes. A tool without them would never get past procurement, regardless of how useful it was.

Excel output, not a new interface. Auditors are already comfortable with Excel. Generating structured KKA output in Excel was a deliberate choice to reduce adoption friction — give people something familiar rather than asking them to learn a new system.

A full document management system. The temptation was to build something that ingested all loan files, parsed them automatically, and centralised everything. That would have been technically interesting but practically impossible to deploy — banks have strict data residency requirements and lengthy IT approval processes.

I kept the scope to workflow structuring, completeness checks, and impairment calculations. The parts an auditor could use without needing IT sign-off.

If this were a real product in use, the metrics I would track are: time to complete a standard loan review cycle (baseline vs with tool), error rate on completeness checks, number of re-review cycles per engagement, and whether auditors actually use it after the first week.

That last one matters most. Tools that get used once and abandoned tell you more than tools that look good in a demo.

Adults in their 20s and 30s who have heard about crypto from friends, coworkers, or the news and want to understand it — but every time they try, they end up more confused. They are not looking to trade. They want to understand how it actually works.

They've probably tried YouTube videos, Reddit threads, or exchange learning centres. The content exists. But none of it gives them a clear sense of progression — what to learn first, what builds on what, and when they're done with the basics.

The crypto content ecosystem is designed for people who already understand it. Most tutorials assume you know what a wallet is before explaining why it exists. Most explainers jump straight into DeFi without grounding you in what problem it solves.

The result is that beginners consume a lot of content, recognise some words, but can't explain how the pieces fit together. That's not a content problem — it's a structure problem.

I spent time in crypto beginner communities on Reddit and Twitter — reading threads where people asked basic questions and noting which ones came up repeatedly. "I understand Bitcoin but nothing after that." "People keep using terms without explaining them." "I don't know where to start."

I also drew on my own experience entering the space. The frustration was real and personal, not just observed. What I did not do was structured user interviews or usability testing with real learners. The research was observational and informal, which means the assumptions about what structure should look like were mine, not validated by the people I was designing for.

Problem before concept. Every chapter starts with a real-world problem — inflation, banking failures, settlement delays — before introducing the technical idea that addresses it. The goal was to give learners a reason to care before asking them to understand.

Interactive over passive. Reading about how a blockchain works does not stick the way running a simulation does. Each chapter was built as an interactive flow, not a wall of text. This increased build time significantly but felt essential to the core value proposition.

Explicitly not about investing. The crypto space blurs education with promotion. I made a deliberate choice to exclude price speculation, return expectations, and anything that reads as financial advice. It narrowed the audience but made the product more trustworthy.

A community or social layer. The instinct was to add forums, progress sharing, or cohort learning. I cut it. It would have doubled the scope and the core problem — lack of structure — did not require social features to solve. If the content worked, social could come later.

A placement test. I wanted to let users skip to the right level based on prior knowledge. It did not make the first version because the progression logic was not ready. It is the first thing I would add in a second iteration.

Chapter completion rate per level — does anyone get past chapter three, or do they drop off? Return visit rate — do people come back, or is it a one-time curiosity? Quiz scores over time — is the learning actually sticking?

The metric I'd care about most is whether someone who finishes the beginner level can explain Bitcoin to another person in plain language. That's the outcome I was designing for, and it's the hardest one to measure.

A small business owner — a tennis academy, a roofing company, an antiques dealer — who manages their own website and has heard that SEO matters but doesn't know where to start. They don't have a marketing team. They don't have time to read a 40-page crawl report. They need to know what to fix this week.

I knew this user because I had been working with them directly — managing SEO for Tenez Academy in Singapore and for freelance clients in the Netherlands and Indonesia. The frustration was the same across all of them: tools told them what was wrong, but not what to do about it.

Every time I delegated SEO work, I had to translate the tool output into actual tasks. Screaming Frog gives you a spreadsheet of issues. Google Search Console shows you impressions and clicks. None of them tell a business owner with no technical background: here are the three things you should do this week, in this order, with these exact changes.

At the same time, AI search — ChatGPT, Perplexity, Google AI Overviews — was becoming a real discovery channel. Businesses suddenly needed to think about two different kinds of visibility. Enterprise tools that covered both started at $295 a month. Nothing affordable addressed both together.

The validation was direct experience. I had managed SEO for real businesses and hit the same wall every time: the gap between here are your issues and here is what you do about them. I did not run a formal discovery process — I built the simplest version that proved whether the output format was useful.

The first version had no crawler at all. Claude estimated SEO issues based on the URL alone. That was deliberately minimal — I wanted to test whether the roadmap format resonated before investing in the harder technical work. It did, so I built the crawler.

Fix tool as the core differentiator. Every competitor shows you what's wrong. None of them write the fix inside the product. I made the fix generation — copy-paste-ready title tags, meta descriptions, schema markup — the centrepiece of the product, not a secondary feature. That's the step where most people give up, and removing it changes the experience entirely.

Deterministic scoring, not AI estimation. Early on, I asked Claude to score the SEO quality. The score changed on every run. A fluctuating number destroys credibility — users notice, and they stop trusting the whole product. I moved to scoring from real crawl data entirely: title tag presence, H1 coverage, HTTPS, schema, canonical tags, image alt ratios. Claude writes the analysis. The numbers come from the crawl.

Parallel crawling to fit serverless constraints. Vercel Hobby functions time out at 10 seconds. Crawling pages sequentially fails for any real site. I crawled up to 9 pages in parallel — not ideal architecturally, but it solved the problem within the constraint without needing a paid plan.

Ongoing monitoring and alerts. The instinct was to add weekly re-crawls and rank tracking. I cut it — it would have required a database, user accounts, and a subscription model before I knew whether the core audit was even useful. Build the audit first. If people come back wanting to track progress, that is the signal to build monitoring.

A full competitive intelligence layer. I added basic competitor comparison, but not a dashboard. The target user does not need to know everything about their competitors — they need to know what to fix on their own site. Competitor data is noise for someone who hasn't fixed their title tags yet.

Audit completion rate — do users actually run a full audit or drop off midway? Fix implementation rate — do users copy the generated fixes and use them, or ignore them? Return audit rate — does someone come back a week later to check if their changes improved the score? That last one is the clearest signal that the product delivered real value.

Revenue per user and conversion to paid would matter if this were a commercial product. Right now the honest metric is: did anyone implement a fix and see their ranking improve?