Loading
Preparing your experience
Please wait while we fetch the latest data and prepare the page for you.
Navigation
Loading
Please wait while we fetch the latest data and prepare the page for you.
Why VeriWorkly is split into separate apps for the builder, docs, blog, and backend, and how that helps us ship reliably.
VeriWorkly is organized as a multi-app repository with a clear split of concerns:
apps/site)apps/studio)apps/docs-platform)apps/blog-platform)apps/server)We also maintain one internal shared package, @veriworkly/ui (packages/ui), for reusable UI primitives and theme tokens.
This is not about sounding big. It is about keeping each surface focused and easier to maintain.
The resume editor remains focused on editing workflows, while docs/blog focus on content delivery and discovery. The API server handles persistence, sharing, and export workloads.
Each service can be deployed independently. If export traffic spikes, we can tune backend resources without touching blog/docs deployments.
@veriworkly/ui gives us a single place for base components and theme variables, while each app still controls its own page composition and behavior.
apps/site)apps/studio)apps/server)apps/docs-platform)apps/blog-platform)For local development, services run via the repository scripts and compose.yaml where appropriate. In production, frontend and backend workloads are hosted separately so each can evolve on its own release cycle.
This structure has made the codebase easier to reason about and safer to ship. The most important part is not the buzzword; it is that each app has one job and clear boundaries.
If you want to explore implementation details next, start with the docs at https://docs.veriworkly.com/docs/architecture/monorepo.