Overview
Monarrk is an independently developed service-operations SaaS product built by byNitrone. It is designed around the work that happens after a lead comes in, connecting quotes, approvals, jobs, invoices, billing and team access in one operational system.
The product grew from a recurring service-business problem: the work was rarely failing because there were no tools. It was failing because context was split between too many places. A quote might live in one system, job details somewhere else, an invoice handled separately, and customer approval buried in email or messages.
Monarrk applies the same process-first principle used across byNitrone: fix the workflow, then build the system around how the work actually needs to move.
Project snapshot
- Role: Product strategy / Full-stack engineering / UX / QA & release systems
- Timeline: March 2026 to present
- Stack: Next.js, Supabase/PostgreSQL, Stripe, Vitest, Playwright, GitHub Actions and Notion
- Focus: Multi-tenant service operations, connected workflow state, auth and permissions, billing foundations, testing and release control
The problem
Service businesses need more than a dashboard. The operational context has to survive as work moves from quote to approval, job and invoice, while the product still handles team permissions, customer-facing actions and billing state safely.
That made the harder parts of Monarrk less about isolated screens and more about keeping state consistent across the system.
- Customer approvals needed a durable history rather than disappearing into scattered communication.
- Quote, invoice and job data needed to remain connected instead of being repeatedly re-entered.
- Team access needed role-based rules and tenant-scoped handling.
- Billing needed explicit subscription states and entitlement behaviour rather than a single checkout action.
The approach
Development was organised around complete operational flows rather than a long list of disconnected features. The early product work concentrated on the workflows a service team would need to trust before broader expansion.
- Create and manage invoices
- Create quotes, generate PDFs and carry approved work forward
- Connect invoices and jobs without discarding existing customer and work context
- Track customer approval and feedback history
- Manage team access, membership and role-gated actions
- Build subscription-state foundations and release gates around higher-risk workflows
What was built
Connected quote, invoice and job workflows
The product carries operational context forward between commercial and delivery stages. Invoice validation was hardened, pricing behaviour was made more consistent across views, quote PDF actions were added, and invoice-to-job workflows were built so existing customer and work context could be reused.
Customer approval history
Quote responses and feedback were given an audit history so customer decisions could be stored reliably and read within the correct tenant context instead of being lost in separate messages.
Auth, roles and onboarding
Authentication and membership handling were hardened around invites, missing memberships, post-login routing and role-gated actions so the application could handle real account states rather than only an ideal demo path.
Stripe billing foundation
Billing was treated as product state, not just a payment button. The implementation established subscription states such as trial, active, past due and cancelled, with foundations for checkout, customer portal behaviour, webhooks, entitlement checks and blocked-state UI.
The system behind the product
A Delivery OS was built around the product to track epics, work items, sprints, bugs, pull requests, releases, execution runs, schema changes, QA notes and browser-testing queues. Work lanes carried explicit scope, branch, test plan and review evidence, supporting controlled AI-assisted development without treating generated code as automatically complete.
Quality and release control
Because the product touches billing, authentication, permissions and customer approvals, QA was treated as part of delivery rather than a final pass.
- Recorded pilot-hardening evidence included 692 passing Vitest tests during billing-state validation.
- 38 targeted billing tests were recorded passing during the same validation work.
- The invoice-to-job flow had targeted Playwright coverage, with 2/2 recorded passing at that stage.
- Core workflows were supported by CI-backed review, schema tracking and release validation.
The outcome
Monarrk developed from an early SaaS concept into a working, release-managed service-operations product foundation. The important result is not a single dashboard. It is the connected operational state underneath it: quotes, approvals, jobs, invoices, billing and team access are treated as parts of one workflow.
The project also established the engineering and release discipline needed to keep extending the product without losing control of permissions, database changes, verification or deployment evidence.
