Working on a big project alone can make you feel like a whole team working from one chair. One minute you’re fixing a page on the customer website. The next, you’re checking an admin form, changing an API response, or testing something in the mobile app. Each part has its own concerns, but they all belong to the same product.
That’s why I keep MySawit in a monorepo: one repository that holds the related apps and the code they share. It’s a practical choice for me as a solo developer. I can see how a change travels through the project without spending half my day coordinating separate repositories.
One product, several moving parts
MySawit includes a consumer website, an admin dashboard, a marketing app, a server, and a completed mobile app. They serve different needs, but they rely on many of the same product concepts. Keeping them together helps me see where those concepts are used.
The repository also has shared packages for TypeScript types, configuration, and common code. The common package includes things like validation schemas and client queries. These are pieces that more than one app may need to agree on.
Imagine having the same product data described separately in several projects. A field changes, and suddenly I have to remember every copy of that definition. With shared types and schemas, I have a clearer place to start. Genuinely shared concepts have one home.
The payoff shows up in ordinary changes
Say I need to change how a product detail is represented. I can search one repository to find the server logic, the shared product type or validation schema, and the web and mobile screens that use it. I can update the relevant parts together and review the whole change in one place.
That’s especially helpful when I’m the person wearing every hat. If an API contract changes, I want to see which screens consume it while the decision is still fresh in my mind. If a shared type breaks an affected app, a type check can point me toward the places that need attention. I still have to test the behavior, but I spend less effort reconstructing the context of my own work.
MySawit uses pnpm workspaces to connect its apps and packages. Turborepo helps organize tasks and their dependencies across those workspaces. I can run focused commands while working on a particular area, then run wider checks when a shared contract changes. That lets me focus on one area while still checking its effect on the wider project. It doesn’t guarantee that every build will be faster.
There’s a smaller benefit too: the repository documents its conventions in one place. When I return to an area after weeks away, I can follow the same structure for types, schemas, and services instead of guessing how an older project was set up. For a solo developer, that consistency is a form of memory.
One repo still needs boundaries
A monorepo can become messy if everything is treated as reusable. I try to keep app-specific pages and screens in their own apps and move code into a shared package when it really has multiple consumers. The server also needs its own boundaries; browser code doesn’t belong in a server startup path just because both live in the same repository.
Shared code increases the reach of a change. Updating a common schema can affect a web form, a server resolver, and a mobile screen. That’s useful when the change is intentional, but it also means I need to check the affected workspaces rather than assuming a passing check in one app covers everything.
The setup itself takes some care as well. Workspace dependencies, build order, and scripts should be understandable. A monorepo works best when its structure helps me find things quickly.
Why it works for me
For MySawit, the biggest benefit is keeping the product together. I can follow a feature from the data model to the API to the web and mobile interfaces, make a coordinated change, and keep shared concepts consistent. That saves mental energy, which is often the scarcest resource when you’re building solo.
A monorepo is an organizational choice that fits the way I work: one product, several apps, and one developer who needs to move between them. If you’re in a similar position, think about where your apps truly share concepts. Giving those concepts a clear home might make the next big change feel much more manageable.
