Enterprise · Operations · Case study
Solas: A funeral management SaaS that replaced spreadsheets and paper forms
Funeral management software case study: multi-tenant SaaS with lifecycle tracking, invoicing, PDF estimates and scheduling on Next.js and NestJS.
- Client
- Solas provides a cloud platform that funeral homes use to run intake, service planning, inventory, invoicing and scheduling in one place.
- Team
- 4 engineers, 1 designer, 1 project manager
- Timeline
- 6 months to first release, ongoing since
- Services
- Web development, Enterprise software, UI/UX design
- 196+
- Frontend TypeScript files
- 16+
- Application pages
- 25+
- Backend module files
- 3
- Deployable applications
In short
Solas needed to replace the spreadsheets, paper intake forms and separate invoicing tools that funeral homes were juggling. We built a multi-tenant SaaS platform covering the full service lifecycle: client records, an itemised catalogue, estimates that convert to invoices with PDF export, and a drag-and-drop event calendar. It is a Next.js 14 and NestJS 10 monorepo with a GraphQL API and MongoDB, running in production.
Where they started.
- Funeral providers relied on fragmented tools: spreadsheets for inventory, paper forms for client intake, separate invoicing software and manual calendars
- Details were being missed during sensitive situations and billing errors were common
- Each funeral home needed its own isolated data while sharing one platform
- Operators needed a system they could adopt quickly, with guided setup rather than training courses
The approach.
- Built a unified cloud platform where a funeral record is the hub linking clients, items, invoices and events
- Modelled the service lifecycle with Draft, Upcoming, In Progress and Completed statuses and captured deceased, client, item and scheduling details in one flow
- Created a categorised item catalogue with unit pricing, suppliers, billable flags and images for flowers, urns, caskets and packages
- Implemented estimates with expiry dates, estimate-to-invoice conversion, discounts, tax and PDF export, plus email delivery to clients
- Added a FullCalendar-based scheduler with day, week and time-grid views, drag-and-drop and reminders
- Delivered a business-scoped multi-tenant design so every funeral home sees only its own records
What shipped.
- Next.js 14 client application with 16+ pages and Redux Toolkit state
- NestJS 10 GraphQL and REST backend with feature modules for auth, users, funerals, items and invoices
- MongoDB data model with business-scoped multi-tenancy
- Invoice and estimate generation with PDF export and email sharing
- Interactive event calendar with reminders and dashboard widgets
- Guided onboarding wizard, welcome flow and operational dashboard
- JWT authentication with Passport.js, HTTP-only cookies and password recovery
- Marketing site as a third deployable application
How the engagement ran.
Context
Funeral homes run on trust and timing. The families they serve are grieving, the service has a fixed date, and the details are numerous: the arrangement, the flowers, the casket, the vehicles, the invoice. Solas set out to give these businesses one system instead of a pile of spreadsheets, paper forms and a separate invoicing product, and asked us to build it.
The brief was a SaaS platform that any funeral home could sign up for, configure in a guided flow and run daily operations from, with complete separation between tenants.
We treated the funeral record as the centre of the system. Every client, catalogue item, estimate, invoice and calendar event links back to it, so a director opening one record sees the whole service, and a change in one place, such as an added floral arrangement, flows through to the estimate, the invoice and the schedule without re-entry. That single decision removed most of the missed-detail and billing-error problems the client described.
What we built
- Funeral service lifecycle management with status tracking from draft to completed
- A searchable client and family directory with contact details, billing addresses, history and email reminders
- An item and inventory catalogue with categories, sub-categories, pricing, suppliers and images
- Estimates and invoices with multi-item lines, discounts, tax, PDF generation and email sharing
- An interactive calendar for funeral, service and custom events with drag-and-drop scheduling
- A dashboard with key metrics, status cards, quick actions and an upcoming-events widget
- Sign-up, business registration, guided onboarding and multi-tenant authentication
Architecture and stack
| Layer | Technology | Why |
|---|---|---|
| Frontend | Next.js 14 App Router, React 18, TypeScript, Ant Design, Tailwind CSS | Server rendering for fast first loads; Ant Design gives operators dense, familiar business screens |
| State and data | Redux Toolkit, Apollo Client with GraphQL | Nested funeral, client and invoice data fetched in one typed query per screen |
| Forms | React Hook Form with Yup validation | Long intake forms with clear validation for sensitive data |
| Backend | NestJS 10 with GraphQL resolvers and REST endpoints | Feature modules keep auth, users, funerals, items and invoices independent |
| Database | MongoDB with Mongoose schemas and business-scoped isolation | Flexible documents for varied service items; tenant scope on every model |
| Auth | Passport.js, JWT, bcrypt, HTTP-only cookies | Standard, auditable session handling |
| Documents | Apollo Upload Client, react-to-pdf | Image and document uploads; PDF invoices and estimates |
| Quality and delivery | TypeScript across the stack, ESLint, Prettier, Jest unit and e2e, Bitbucket feature branches | Fewer runtime errors and reviewable, testable changes |
How we worked
We organised the codebase as a monorepo with three independently deployable applications: the API, the client app and the marketing site. Work moved through feature branches named for the flow being built, such as the funeral flow and dashboard integrations, with pull-request review before merging to develop and main. Environment-based configuration through NestJS ConfigModule kept development, staging and production separate.
The GraphQL schema was designed alongside the screens, so each page's data needs shaped the resolvers. Type safety ran end to end, from Mongoose schemas through resolvers to the React components.
Onboarding received particular attention because a funeral home's first hour on the platform decides whether it stays. The sign-up flow registers the business, a step-by-step wizard walks through catalogue, calendar and billing setup, and a welcome modal with an upcoming-events widget gives the operator something useful on the first screen. Error boundaries and custom hooks keep the client application resilient when a single widget fails.
Scale and complexity
| Measure | Figure from the documentation |
|---|---|
| Frontend source files | 196+ TypeScript and TSX files |
| Backend module files | 25+ across auth, users and business modules |
| Application pages and routes | 16+ |
| Production dependencies | 24 frontend, 14 backend |
| Deployable applications | 3: frontend, backend API, marketing site |
What this means for your project
If your business runs on a workflow that spans intake, inventory, scheduling and billing, the value is in the joins: one record that links everything so nothing is missed and nothing is entered twice. This is the pattern we apply to operations software in any sector.
It also shows that a multi-tenant SaaS product does not need a large team or a long runway to reach production when the data model, tenant isolation and deployment pipeline are settled early.
What changed.
- The platform is in production and consolidates every part of funeral service management into a single application
- Operators gain real-time visibility across all operations with automated billing workflows
- The client describes the outcome as an innovative and scalable solution that transformed how they manage operations
Questions about this project.
How do you keep each customer's data separate in a shared SaaS platform?
Every record is scoped to the business that owns it, and the API enforces that scope on every query. A funeral home cannot see, search or report on another home's clients, items or invoices, even though all of them run on the same deployment.
Can the invoicing handle estimates, discounts and tax?
Yes. Estimates carry expiry dates and can be shared with the client, then converted to invoices in one step. Line items support quantities, discounts and tax configuration, and both documents export to PDF and can be emailed directly.
Is GraphQL a good fit for a business application like this?
It was here. The frontend needs deeply nested data, such as a funeral with its client, items, invoices and events, and GraphQL lets each screen ask for exactly that in one typed query. REST endpoints remain for uploads and PDF generation.