Orymu — Building a Reading Product That Sticks

Orymu is a reading companion built around a simple idea: reading should leave something behind. Not just finished pages, but focus, memory, and a reason to come back.

As founding engineer, I helped shape Orymu across product, mobile, and backend. I designed the mobile architecture, built the backend APIs behind the app, and worked with a small team to turn the product from an idea into something that could actually ship and keep evolving.

---

Overview

Orymu supports the full reading loop.

Users can discover books, build a personal library, start focused reading sessions, create and review flashcards, write reviews, and track progress over time. The goal was not to make another reading tracker. The goal was to build a product where reading, focus, memory, and reflection feel connected.

From the start, I wanted Orymu to feel like a real product, not a portfolio app dressed up as one. That meant making early decisions that helped a small team ship now without making later features painful to add.

---

My Role

Orymu was built by a four-person team: two mobile engineers, one web engineer, and one UI/UX designer. I worked as the founding engineer and carried the broadest technical scope.

My work covered four areas:

• Shaping the early product direction and defining what the first real version needed to do
• Designing the mobile architecture and setting patterns for how features should be built
• Owning the backend APIs behind auth, discovery, library, focus sessions, flashcards, reviews, and profile
• Acting as a technical multiplier through code review, implementation standards, and cross-team alignment

That role forced me to think end-to-end. I was not only building screens. I was designing the system those screens depended on.

---

The Real Problem

The technical problem was not simply "build a Flutter app."

The real problem was how to build a reading product with several connected flows on a small team in a way that still feels coherent months later.

Reading products get messy fast. Discovery, onboarding, auth, library state, timers, flashcards, reviews, reminders, and progress tracking all pull the codebase in different directions. Without enough structure, each new feature becomes a local patch. The app still ships, but it gets slower to change and harder to trust.

I wanted to avoid that early. The architecture work in Orymu was there to protect shipping speed, clarity, and product momentum.

---

What Orymu Does

Orymu is built around a connected reading loop rather than one isolated feature.

Users can get into the app through onboarding and auth, discover books, build a personal library, start focused reading sessions, create and review flashcards, write reviews, and track progress through goals, achievements, and profile history.

A few parts mattered especially much:

• Auth and onboarding, because the product needed to feel trustworthy from the first session
• Library and focus mode, because they turn the app from a passive tracker into an active reading tool
• Flashcards, because they push Orymu toward its real identity: helping readers retain what they read
• Goals, reviews, and achievements, because progress should feel visible instead of disappearing after each session

What mattered most was not the number of features. It was making them feel like parts of the same product instead of disconnected screens.

---

Key Decisions

A few decisions shaped the project.

First, I organized the app around product slices instead of technical buckets. That made it easier for features like discovery, focus sessions, flashcards, and reviews to evolve without constantly stepping on each other.

Second, I treated session and routing as system concerns, not page-level concerns. That kept the app flow more predictable and avoided the usual spread of auth logic across random screens.

Third, I moved validation into the domain instead of leaving it inside UI logic. That made the rules easier to reuse, easier to trust, and less likely to drift over time.

I wrote a separate deep dive on that part here: Designing Validation Architecture with Value Objects in Orymu

Most importantly, I aimed for enough structure to support future features without overbuilding for a future that did not exist yet. That balance mattered more than any specific library choice.

---

Challenges

The hardest part of Orymu was not one screen or one API. It was keeping the product coherent while working across product decisions, mobile architecture, backend contracts, and day-to-day implementation at the same time.

That meant constantly making tradeoffs. Every shortcut saves time today, but some of them make the next feature slower, riskier, and harder to reason about. Orymu pushed me to be more deliberate about where structure was worth the cost and where speed mattered more.

It made me think less like a feature implementer and more like a system owner.

---

Impact

Orymu crossed the line from concept to product.

It is a real app with connected flows: users can sign in, discover books, build a library, run reading sessions, create flashcards, review them, write reviews, and track progress over time. It is publicly available on the Play Store, and the system underneath it was built to support iteration rather than collapse under it.

The internal impact mattered too. Clear boundaries gave the team a more repeatable way to ship. New features did not need a new pattern every time. Problems were easier to localize. Product and engineering conversations got better because mobile and backend were being shaped together instead of negotiated after the fact.

---

What I Learned

Orymu strengthened a belief I already had: good product engineering is not about making architecture look impressive. It is about protecting clarity so a team can keep shipping.

I learned to treat things like session handling, validation, and reading progress as product and domain concerns, not just implementation details. I learned that owning both mobile and backend changes the quality of judgment, because you stop thinking in isolated layers and start thinking in complete product loops.

Most of all, I learned that founding engineering is often invisible work. It is not just building features. It is creating enough order that the product can keep becoming itself.