Home/Projects/BlinkDo: Canvas to App Stores in 5 Weeks
Book a callSay Hello

Related Projects

TamDone
TamDone
A powerful productivity and collaboration platform designed for teams to manage tasks, projects, and goals with ease.
Kotteb Mobile App
Kotteb Mobile App
Kotteb is a Full-featured Quran companion app with prayer times, tafsir collections, and memorization tracking.
Healu
Healu
Accessible online therapy and wellbeing support.
See All projects
blinkdo

BlinkDo: Canvas to App Stores in 5 Weeks

BlinkDo is the bridge between reading a book and actually changing your life.

Team:
BSBrijesh SMobile Engineer
AJAvish JainProduct Owner & Founder
Result: Improved task completion consistency with a simpler workflow.
Duration: May – June 2025
Type: Mobile App
Role: UX/UI Designer

Tools

Overview

Avish Jain spent 8 years as a product manager at eBay, BMW, and Remitly. He knew every productivity app on the market. He still couldn't get a book to change his behavior. That frustration became MentorFlow AI, and MentorFlow's first product was BlinkDo — a mobile app that takes a non-fiction book and turns it into a structured, day-by-day action plan you actually follow. I came in as the sole designer in May 2025, with a fixed-price contract, a 30-day deadline, and a blank Figma file. Five weeks later, a production-ready design was in the hands of the dev team. Four months after that, the app was live on both the App Store and Google Play.

The Problem

The self-help industry has a dirty secret: reading doesn't change behavior. People finish Atomic Habits, feel genuinely inspired, underline half the book — and then open the same apps with the same routines the next morning. The knowledge sits on the shelf. The gap between "I get it" and "I did it" is exactly where every existing tool stops.

Summary apps like Blinkist help you read faster — but faster reading doesn't mean deeper change. Habit apps like Streaks help you track behavior — but they don't tell you which behaviors to build or why. Users trying to bridge the gap themselves resorted to manually copying book recommendations into Notion or Todoist, stripped of context. A task that says "do a weekly review" is useless without the framework that made it meaningful in the first place.

Goals & Success Metrics

The brief was tight and the goals were clear:

  1. Design a complete MVP — zero to production-ready — shipped before June 14, 2025
  2. Make the read → do core loop frictionless: pick a book, start a DoGuide, complete today's task in as few taps as possible

On this case study

  • Build a Flutter-compatible design system so the handoff to Brijesh required zero translation
  • Default to optional authentication — let users experience value before asking them to commit
  • Success wasn't a metric dashboard — it was a live app. The design system would prove itself through how fast subsequent versions shipped after launch. Stretch goal: WCAG AA compliance baked in from the start, not bolted on later.

    Research & Discovery

    With a 5-week timeline and no budget for a formal research phase, the research had to be fast and high-signal. Avish was the primary source — and he was unusually qualified. Eight years of studying productivity apps from inside Big Tech gave him a researcher's understanding of user behavior and a frustrated user's understanding of what was missing.

    The competitive audit confirmed the gap was real. Blinkist had millions of users and zero action layer. Habitica had behavior tracking with no knowledge connection. Todoist had task management but required users to do the hard translation work themselves — and most didn't. No existing product lived in the space between "I read it" and "I changed because of it." BlinkDo's DoGuide format was genuinely unoccupied territory.

    Two findings shaped the entire design direction. First: users want to work through 2–3 books maximum at a time — stacking books creates the same overwhelm the app was designed to eliminate. Second: authentication friction kills early engagement — making sign-up optional wasn't a compromise, it was the right product philosophy for a tool that needed to earn trust before asking for commitment.

    Design Process & Iterations

    The first layout I explored organized all features as equal navigation items — Browse, Summaries, DoGuides, Habits — across a five-tab bottom bar. It looked complete. It was wrong. It buried the one thing BlinkDo needed to be: an action app. The second direction borrowed from Blinkist's library-first UI, leading with book discovery. Also wrong — it told users this was a reading app, which was exactly the category BlinkDo was trying to leave behind.

    The chosen direction flipped the hierarchy entirely. The home screen led with the user's active DoGuides and today's specific tasks. Discovery was a secondary tab. Every time someone opened the app, the first thing they saw was what they needed to do today — not what they could browse next. The navigation collapsed from five tabs to three: Focus, Discover, Profile.

    The pivotal iteration wasn't the layout — it was adding the Concept layer. Early wireframes showed DoGuides as plain task checklists. Functional, but thin. The Concept layer attached a brief "why this matters" note to every single task, connecting the action directly back to the book's core principle. This was the version where Avish's reaction changed. It wasn't a task app with book branding anymore. It was something new.

    Technical Decisions

    The entire design system was built Flutter-first. Every token name, component label, and spacing value was defined to match Flutter's conventions — padding: 16 in Figma mapped directly to EdgeInsets.all(16) in code. There was no translation layer, no naming dictionary, no guesswork for Brijesh at handoff.

    snippet.txt

    Copied!
    // Design token mapping — Figma variables to Flutter constants
    class AppTokens {
      // Color roles (semantic, not value-based)
      static const Color textPrimary    = Color(0xFF1A1A2E);
      static const Color textSecondary  = Color(0xFF556270);
      static const Color surfaceDefault = Color(0xFFFFFFFF);
      static const Color actionAccent   = Color(0xFFF5A623);
    
      // Spacing scale
      static const double spaceXS = 4;
      static const double spaceSM = 8;
      static const double spaceMD = 16;
      static const double spaceLG = 24;
      static const double spaceXL = 40;
    }

    Rather than designing every component from scratch, Flutter's Material Design library was extended and skinned. Custom components only where behavior required it — everywhere else, Material conventions applied. This kept the dev workload manageable and ensured consistent cross-platform behavior. OAuth (Google + Apple Sign-In) replaced email auth: two taps instead of a form, aligned with the optional-auth philosophy. Color tokens were named by role — action-accent, surface-default, text-secondary — so the system would stay legible as the product scaled beyond its v1 scope.

    Results & Impact

    The design delivered 3 days ahead of schedule. BlinkDo launched on the App Store and Google Play in October 2025. By February 2026 — just 4 months post-launch — the app was on version 1.0.9, having shipped audio summaries, a redesigned reading experience, onboarding flows, and time-estimate features across 9 consecutive updates. None of those updates required a design system overhaul. The foundation held.

    App Store rating: 5.0. One reviewer called it "a gateway to actionable wisdom from books that many of us have read and admired but couldn't turn the learnings into action." Another noted the summaries went "much deeper" than Blinkist — exactly the positioning the product was designed for. Avish's Upwork review: "delivered way beyond the initial scope." He's now working on BlinkDo full-time. The freelance contract became the foundation of a company.

    A good design system doesn't just make the first version look right — it makes the tenth version ship fast.

    Lessons Learned

    1. Never hand someone a blank field. The best lesson from Avish came from watching how he ran feedback sessions: he never asked open questions. He always gave options. "Which of these two directions?" not "what do you think?" Open questions produce vague answers. Options produce decisions. Every design review since has been structured this way.
    2. Consistency over brilliance. The early weeks of the engagement were the strongest. Energy dipped in the final stretch — a real risk on a fixed-price contract with a small budget. The 5-star outcome was still there, but the inconsistency showed, and it almost cost the relationship. A $199 contract can be worth far more than $199 if you treat it that way the whole time.
    3. Show thinking before showing work. Early habit was to build privately, then present finished screens. Avish worked better with constant visibility — seeing direction before execution, catching misalignments early. Switching to that mode mid-project saved time in the back half. Now it's the default from day one.

    What's Next

    My part is done. The product isn't. The version history from October 2025 to February 2026 shows a team that knows how to ship — 9 updates in 4 months, each one adding depth without breaking what was already there. The open challenge ahead is the AI content layer: generating genuinely deep, personalized DoGuides requires full-text book analysis at scale, which is expensive. The design is ready for whatever that solution looks like. The infrastructure is the hard part now, not the experience.