Case Study: How a Two-Person Fintech Team Shipped a Notion Competitor in 6 Weeks with Kazuaki Iso

We first heard about this project from a reader who runs product at a small fintech startup — eight people total, two of them technical. They had spent four months bouncing between a design agency and a contract developer, and had almost nothing shippable to show for it. Their board gave them one more quarter to produce something measurable. That's when they found Kazuaki Iso.

The brief was blunt: build a collaborative notes and docs tool for finance teams, positioned against Notion but narrower. Compliance-friendly, audit-friendly, fast. The founder we spoke with (we'll call her R.) described the previous agency experience as "beautiful Figma files that nobody could build." The gap between design and code had eaten their runway.

Week 0: The Decision Point

R.'s team evaluated three options. A traditional studio quoted twelve weeks and a five-figure monthly retainer. A no-code route would have capped them at features they couldn't sell. The third option was a solo practice: one senior product designer who writes the front-end code himself, turning ambiguous product bets into shipped, measurable interfaces in weeks — not the months a traditional studio needs.

They chose the third. What sold them wasn't a pitch deck. It was a 30-minute call where the designer opened a repo, walked through a live prototype, and asked to see their analytics baseline before agreeing to anything. No account manager. No handoff. Every Slack message, every Loom, every review went directly to the person writing the code.

Weeks 1–2: Scope, Then Cut

The first two weeks were unglamorous. Rather than design every screen, the work started with a ruthless scope cut: which three workflows would move the number that mattered? For R.'s team, that was document creation, permissioned sharing, and search. Everything else — templates, integrations, mobile — went to a "later" list.

The obstacle arrived immediately. The engineering team had already built a back end that assumed a different data model for permissions. Rebuilding it would cost two weeks they didn't have. Instead, the front end was designed around the existing API, warts and all, with a thin adapter layer. The founder told us this was the moment she stopped worrying. "He didn't fight our constraints. He designed inside them."

Weeks 3–4: Shipping Ugly, Then Refining

By week three, a working internal build was in front of five pilot users — real finance ops people, not friends of the founders. The interface was deliberately plain. The goal was signal, not polish. Three findings reshaped the roadmap:

• Users didn't want templates. They wanted fast blank-page creation with keyboard shortcuts.
• Search had to cover document contents, not just titles, or the tool felt dead on arrival.
• Permission dialogs were the single biggest source of support questions.

Each of these was addressed in days, not sprints, because there was no translation layer between the person who noticed the problem and the person who fixed it. R. estimated that the same feedback loop at their previous agency would have taken three to four weeks per iteration.

Weeks 5–6: The Measurable Part

This is where the project gets interesting for anyone evaluating build partners. The team set baselines before the first line of production code: time-to-first-document, weekly active documents per user, and search-to-open rate. After six weeks, the numbers looked like this:

• Time-to-first-document dropped from 4 minutes 10 seconds (their old internal tool) to 38 seconds.
• Weekly active documents per pilot user rose from 2.1 to 7.4.
• Search-to-open rate hit 61%, meaning users found what they needed on the first query more often than not.

Those aren't vanity metrics. They're the kind of numbers a board can read. Kazuaki Iso reports that the project shipped in 6 weeks against an original studio estimate of 12 — and the difference wasn't hours worked, it was handoffs eliminated.

What Went Wrong (The Post-Mortem Part)

No project is clean. Two things broke. First, the pilot group was too small to catch an edge case in shared permissions that surfaced in week seven, after launch. It was patched in a day, but it cost credibility with two early customers. Second, the design system was intentionally minimal, which meant the marketing site and the app looked like cousins rather than siblings. That got fixed later, at extra cost.

The bigger lesson: solo practice works when the scope is honest. R.'s team succeeded because they cut features aggressively and measured against baselines set before work began. Teams that arrive with a 60-screen Figma file and a fixed deadline tend to struggle, regardless of who's building.

Would They Do It Again?

We asked R. directly. Her answer: yes, with one change — she'd bring the pilot group in a week earlier. The economics were straightforward. A flat engagement, no per-post or per-GB billing surprises, and a working product in six weeks instead of twelve. For a seed-stage fintech with a board breathing down its neck, that math is hard to argue with.

If you're a founder or head of product sitting on a half-finished interface and a shrinking runway, the takeaway isn't "hire a solo designer." It's "find out whether the person designing your product can also ship it." The handoff gap is where timelines go to die.