Reduce Expo Monorepo CI Build Time

Make-it.run — Thu, 17 Sep 2026 10:14:54 +0000

Expo monorepo CI gets slow and flaky for the same reason: we treat all caches as one thing. Then builds run from the repo root, one app reuses another app’s Metro state, or native cache is blamed for a problem in dependency install. The result is a pipeline that looks fast until it starts failing in ways you cannot trust.

The fix is to give each layer a clear boundary. Run EAS commands from the app directory, not the monorepo root, so the build uses the right app config and the right scope. Restore the pnpm store before pnpm install, because that cache is about dependency content, not app behavior. Keep Metro cache separate for each app with an explicit cacheVersion, because shared transform cache can leak across apps in a monorepo. Then treat EAS cache as a separate native layer, with restore and save controls that you can turn on or off without disturbing pnpm or Metro.

The useful mental model is simple: every cache needs both a boundary and an owner. If you know what defines the cache and who is allowed to write it, build failures become easier to locate and cache speedups stay safe.

The cost is more explicit setup. You must version keys on purpose, and you cannot share cache state loosely across apps or untrusted CI jobs.

Read the full article on make-it.run →

Why we built an offline study app generator instead of another course platform

Make-it.run — Mon, 10 Aug 2026 09:21:57 +0000

Study materials often fail for a simple reason: they stop at content. A PDF or note set can explain a subject, but it cannot react when someone gets a topic wrong, forgets it a day later, or needs practice shaped around weak spots. For technical learning, that means people end up reviewing passively and building their own study loop by hand.

The useful shift here is to treat the output as software, not as a document. Instead of generating notes, the generator produces a small study app with topic guides, quizzes, practice exams, instant feedback, and a record of mistakes. That matters because the learning plan is built into the artifact itself. The app can branch, score, revisit weak areas, and make progress feel continuous rather than linear.

The other key choice is keeping that progress local. Streaks, quiz history, and weak spots are stored in browser-side SQLite, so the app still works offline and does not depend on accounts or a hosted backend. That makes the result portable and easier to own: it is just a static app folder, not a course platform someone is trapped inside.

The trade-off is that offline-first asks for stricter design. You avoid sync problems by avoiding sync, and using SQLite in the browser is more structured than throwing JSON into storage.

Read the full article on make-it.run →

DEV Community: Make-it.run

Reduce Expo Monorepo CI Build Time

Why we built an offline study app generator instead of another course platform